On 07/06/2013 11:39 PM, Ezequiel Garcia wrote:
Hi Sebastian,
Hello Ezequiel,
On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
This enables the two musb instances on am335x to work.
I like a lot the idea of splitting the DT representation of the two
On 07/08/2013 12:43 PM, George Cherian wrote:
This patch series adds phy support for AM335X platform.
This patch series is based on Generic PHY framework [1].
This series has
- adds dual musb instances support for am335x platform (just for
testing)
- adds phy-am-usb
On 07/08/2013 10:34 PM, Ezequiel Garcia wrote:
Hi,
Hi,
On Mon, Jul 08, 2013 at 09:44:33PM +0200, Sebastian Andrzej Siewior wrote:
We need two nodes each one with a glue layer and a musb child node. The
instances crap in kernel has to vanish. Also that means your phy nodes
are wrong
Hi Paul,
I'm slowly losing my mind with hwmod.
arch/arm/boot/dts/am33xx.dtsi has the ti,musb-am33xx node.
That one has usb_otg_hs as hwmod property.
The entry for it arch/arm/mach-omap2/omap_hwmod_33xx_data.c uses
AM33XX_CM_PER_USB0_CLKCTRL_OFFSET (0x1c) as the clk. The TRM only
mentions this
On 07/09/2013 08:08 PM, Mugunthan V N wrote:
Yes, you need hwmod entry for each of the above device. Since USB has only
only
clock ctrl register, have one as parrent and make other devices as child
node.
you can take CPSW as an example.
So there is not some kind of ref counting if I use
* Ezequiel Garcia | 2013-07-06 18:39:50 [-0300]:
Hi Sebastian,
Hi Ezequiel,
After some minor DT tweaking on the current patchset,
I've managed to detect an USB mass storage device in the
second instance (host / usb1) using a Beaglebone black board.
Beaglebone black, that one has a different
On 07/19/2013 03:56 PM, Sergei Shtylyov wrote:
On 19-07-2013 16:34, George Cherian wrote:
diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..e3890c4 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -326,21 +326,59 @@
...@ti.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/bus/omap-ocp2scp.c | 13 ++---
drivers/iio/adc/exynos_adc.c | 15 ++-
drivers/mfd/omap-usb-host.c| 9 +
drivers/of/platform.c | 22
On 07/19/2013 08:33 PM, Sergei Shtylyov wrote:
Hello.
Hello,
usb: usb@4740 {
compatible = ti,am33xx-usb;
usb0_phy: phy@47401300 {
compatible = ti,am335x-usb-phy;
}
usb0: usb@47401000 {
musb0: usb@47401400 {
compatible = mg,musbmhdrc;
On 07/21/2013 04:42 PM, Rob Herring wrote:
Wouldn't the correct fix be to call insert_resource somehow?
Yes unless there was a reason this wasn't done in the first place.
The problem
I have is that while of_platform_populate is all about parsing the DT
and creating devices, the removal side
On 07/20/2013 07:42 AM, NAVEEN KRISHNA CHATRADHI wrote:
Hello Sebastian,
Hello Naveen,
I just did one more testing.
In case of iio/adc/exynos_adc.c there is a bug in the remove path.
If I fix the bug in the driver, with below patch
--- a/drivers/iio/adc/exynos_adc.c
+++
* George Cherian | 2013-07-19 18:04:34 [+0530]:
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 1419ced..4f2502c 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -46,6 +46,73 @@ struct device
* George Cherian | 2013-07-19 18:04:35 [+0530]:
Adds phy driver support for am33xx platform, the host/device
peripheral controller shall get this phy object to control the phy
operations.
If you rebase this on-top of the two instances patches I've sent earlier
then you can bury patch 3 and 4,
On 07/30/2013 09:08 AM, Tony Lindgren wrote:
Looking at this patch there's a pretty high probability of introducing
pointless merge conflicts.
How about do the platform data related changes as a separate follow-up
series? You can typically do this by keeping the old features around,
then
On 07/30/2013 06:53 AM, George Cherian wrote:
Control module have 2 separate registers for phy on/off per instance
(offset 0x620 and 0x628), where as
wkup_ctrl is a shared control module register (offset 0x648). Currently
the control module driver maps
memory from 0x620 till beyond 0x648
On 07/30/2013 07:19 AM, George Cherian wrote:
So from what I see now, it is most likely the easiest thing to just add
that wakeup to the phy driver I posted. Do you agree?
The whole idea of writing a seperate phy driver was to use the generic
phy framework
and most of the am devices
On 07/30/2013 09:56 AM, Tony Lindgren wrote:
A separate minimal branch against -rc3 sounds good to me.
Great. Felipe, can you please put this change in a separate -rc3 based
branch which you and Tony will pull in?
Regards,
Tony
Sebastian
--
To unsubscribe from this list: send the line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/30/2013 04:33 PM, Felipe Balbi wrote:
let's try not to add any new TI-specific DT bindings, can you
figure that out by reading some revision register ? Or perhaps by
using different compatible strings ?
I would suggest to use a different
* Grant Likely | 2013-07-24 15:19:58 [+0100]:
Was there more breakage than imx6 and amba devices? Your first version
had a fallback case for powerpc. Couldn't we do just allow that for more
than just powerpc? I'd much rather see some work-around within the core
DT code with a warning to
On 08/01/2013 01:30 PM, Sebastian Andrzej Siewior wrote:
On 08/01/2013 12:52 PM, Sebastian Andrzej Siewior wrote:
On 08/01/2013 07:24 AM, George Cherian wrote:
b/arch/arm/boot/dts/am33xx.dtsi
index 38b446b..0f756ca 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts
On 08/10/2013 01:59 PM, Ezequiel Garcia wrote:
Is there any reason why there's no DT binding patch to this
series? (aka Documentation/devicetree/... + sent to devicetree list)
(sorry if this has been already explained somewhere...)
Completely forgot. There are existent documents which need
* Roger Quadros | 2013-08-15 16:15:05 [+0300]:
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..3b9ee83 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,13 @@ static int
* Roger Quadros | 2013-08-15 16:15:10 [+0300]:
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 078c46f..d144c14 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -187,11 +167,19 @@ void
On 08/16/2013 11:00 AM, Roger Quadros wrote:
I don't like that part where you can call this function even before the
driver probed the device. This shouldn't happen since you have hard module
dependency and the proper compatible string in your device. But this
kind of thing won't happen in the
Hi,
I activated:
[*] Kernel low-level debugging functions
Kernel low-level debugging port (Kernel low-level debugging
messages via OMAP2PLUS UART)
Low-level debug console UART (AM33XX UART1)
[*] Early printk
and booted my am335x-evm.
I haven't seen any early output in the
On 08/19/2013 02:27 PM, Jean Pihet wrote:
Hi!
Hi Jean,
You need to add 'earlyprintk' in the kernel command line, given (I
suppose) by U-Boot.
Ah, good hint.
I hope this helps!
Yes. I do not see the decompress messages but I have an early console
later on. Unfortunately it stops now
On 06/20/2013 11:06 PM, Joel A Fernandes wrote:
From: Matt Porter m...@ti.com
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed
in [1]
[1]
Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
Could someone please pick this up?
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
Porter mpor...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
Could someone please pick this up?
v1..v2:
- s/edma@/dma-controller@/
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions
On 08/26/2013 10:36 AM, Benoit Cousson wrote:
I've just sent my previous email too soon...
np.
Now the patch is different :-) I'll take that one.
Good, thanks.
Thanks,
Benoit
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On 09/23/2013 06:17 AM, Vinod Koul wrote:
Looks fine, Sebastian cna you test it pls
Just noticed that you already applied some of them. I just got back
after a few weeks of. Will review test as soon as I get to it.
~Vinod
Sebastian
--
To unsubscribe from this list: send the line
On 09/20/2013 05:45 PM, Felipe Balbi wrote:
Acked-by: Felipe Balbi ba...@ti.com
Those four patches went already in, for instance:
commit 781f17983015dae33324e34d1bb831e715fa04d4
Author: Sebastian Andrzej Siewior bige...@linutronix.de
AuthorDate: Tue Aug 20 18:35:49 2013 +0200
Commit
* Daniel Mack | 2013-09-22 16:50:03 [+0200]:
cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
init_descs() and freed as often from purge_descs(). This leads to both
memory leaks and double-frees.
Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
loops.
While
Sricharan r.sricha...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fa74a06
On 10/01/2013 03:09 PM, Daniel Mack wrote:
Hi Sebastian,
Hi Daniel,
sorry for the long delay, I got distracted by other things.
No problem.
Well, I didn't merge the descriptors. Look again at my changes please.
A simplified version of the code as it stands is:
for (i = 0; i
On 10/01/2013 06:57 PM, Daniel Mack wrote:
That sound's like a good idea. Everything that make the driver smaller
and easier to understand is certainly a good thing :)
So we can drop this patch favor of your cleanup. However, I appreciate
if you did it on top of the second round of patches I
* Daniel Mack | 2013-10-01 15:31:11 [+0200]:
In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
instead of popping another descriptor when td_desc_seen is also unset.
My system ran into WARN() condition multiple times when
cppi41_tear_down_chan() was called for channels that
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #3, however, gives me headaches. I can't fully explain what's
going on, but I can tell for sure that if fixes a problem that I stared
on for many hours.
The problem is that on resume, the musb core will detect that some of
the suspended USB
On 10/02/2013 11:19 AM, Daniel Mack wrote:
Hi Sebastian,
Hi Daniel,
On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-10-01 15:31:11 [+0200]:
Thanks a lot for having a look! As I'm going to be off for a couple of
days now, and only be able to read my mails
* Daniel Mack | 2013-10-01 15:39:53 [+0200]:
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.
I guess you are hit by the msleep(1) here.
Fix
* Daniel Mack | 2013-10-01 15:39:54 [+0200]:
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Sorry for asking this stupid question but what is usally happening when
the host goes to
On 10/02/2013 01:14 PM, Daniel Mack wrote:
On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-10-01 15:39:54 [+0200]:
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device
On 10/02/2013 01:07 PM, Daniel Mack wrote:
No, as stated, the line numbers in the kernel message are somewhat off
due to added debugging code. What kicks in here is this one:
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
if
On 10/07/2013 03:28 PM, 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]
Would it be much pain (and do we
is
that the device is already suspended (the clocks are off) and the timer
tries to access register which fails.
Since there is no need to keep this timer aroud while the device is
going to suspend I suggest to remove the timer in suspend and queue it
in the resume path.
Signed-off-by: Sebastian Andrzej
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #1 restores more registers on resume time.
Patch #2 is a cosmetic cleanup that emerged while digging through the
driver and gaining a basic idea of how it's implemented. Nothing fancy.
I'm fine with those two.
Patch #3, however, gives me
On 10/09/2013 09:23 AM, Daniel Mack wrote:
Ok, thank you very much for the update :) I can of course test
alternative patches if you have any.
Could you actually reproduce the issue I described by sending your board
to suspend?
No, I don't have mem, just freeze. I try to test if this is a
On 10/18/2013 11:39 AM, Daniel Mack wrote:
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index da21a4e..ce5bbc6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[]
On 10/18/2013 11:39 AM, Daniel Mack wrote:
v3 of my musb_dsps suspend patches.
With these patches applied, I can successfully bring an AM335x board
to suspend with a USB media connected, and access it again after
resume.
This works for both PIO mode and CPPI41 enabled configurations,
On 10/18/2013 12:02 PM, Daniel Mack wrote:
As mentioned, that doesn't hit me anymore with the current patch stack.
That doesn't mean we should ignore that issue, of course, we're still
sleeping while atomic. But I removed the patch from the series for now,
so we can address that separately.
On 10/21/2013 10:13 PM, Felipe Balbi wrote:
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index e1c5300..b61df9d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -348,9 +348,16 @@
cppi41_pop_desc() where possible
Sebastian Andrzej Siewior (2):
dma: cppi41: redo descriptor collection in abort case
dma: cppi41: return code 0 of pm_runtime_get_sync() is not an error
drivers/dma/cppi41.c | 82 +++-
1 file changed, 43
. This seems not to be true
because I manage to trigger
| WARN_ON(c-desc_phys != desc_phys);
and the other few were fine means the tear-down descriptor was valid but
on different queue.
This patch changes the logic here to look on both queues for the
descriptor.
Signed-off-by: Sebastian Andrzej Siewior
Andrzej Siewior bige...@linutronix.de
---
drivers/dma/cppi41.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index e53292d..42d1c58 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -266,6 +266,15
From: Daniel Mack zon...@gmail.com
With active users over suspend/resume cycles, it turns out that
more registers, in particular DMA_TDFDQ and RXHPCRA0, have to be
restored on resume.
Signed-off-by: Daniel Mack zon...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Return code of pm_runtime_get_sync() 0 is not an error and may happen.
Noticed during rmmod modprobe testing.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/cppi41.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/cppi41.c b
On 11/20/2013 11:02 PM, Ezequiel Garcia wrote:
(Forgot to Cc OMAP people)
Felipe posted a redo of this area to fix this problem a while back. See
http://www.spinics.net/lists/linux-usb/msg97286.html
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
On 11/21/2013 12:30 PM, Ezequiel Garcia wrote:
Ah, good to know. That patch should be picked ASAP, without it the USB
in AM335x is broken. Is it already too late to -rc1?
Yes.
Who is supposed to merge that? Greg?
Felipe will start collecting fixes once -rc1 is out [0] so it should be
part of
On 11/22/2013 04:55 PM, Mark Jackson wrote:
The IDDIG input pin is normally used to determine the USB mode
(i.e. HOST or DEVICE).
On some systems (e.g. AM335x) leaving this pin floating allows
the USB mode to be set via software.
So you have a board where musb is used only as host or only
On 11/22/2013 05:49 PM, Mark Jackson wrote:
and the ID pin not on ground or 3.3V?
What are the side effects? I remember correctly Bin wanted to avoid
settings this if it could be avoided.
Yes ... we have a host only USB port and an unconnected ID pin.
Is it too late to connect that pin?
On 11/22/2013 06:07 PM, Mark Jackson wrote:
Do you insists on having this change merged upstream?
No ... I didn't think it would be such an issue, so I'm happy to keep this
as a local patch if that's any better.
Felipe, Bin: Second opinion on that?
Mark J.
Sebastian
--
To unsubscribe
- sta...@vger.kernel.org since they probably don't care about this
unless the patch is merged.
On 12/02/2013 10:41 AM, Roger Quadros wrote:
Michael,
On 11/29/2013 05:32 PM, Michael Trimarchi wrote:
Hi Roger
On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
With u-boot
On 12/02/2013 01:12 PM, Roger Quadros wrote:
You are right. The musb hwmod data doesn't have the HWMOD_INIT_NO_RESET
flag, so hwmod should reset it during boot.
Maybe I too should just remove HWMOD_INIT_NO_RESET flag from the USB Host
hwmod data, then we don't need to change this driver at
On 12/02/2013 02:35 PM, Roger Quadros wrote:
It refers to Errata Id:i660 why it is required. Once you figured what
why it has been added you could have an idea if it is okay to remove it
and if the reset you do here might lead to it (I dunno).
Keshava no longer works @TI. I have no other
On 12/02/2013 02:44 PM, Roger Quadros wrote:
Errata id: i660
DESCRIPTION
In the following configuration :
• USBHOST module is set to smart-idle mode
• PRCM asserts idle_req to the USBHOST module. (This typically happens when
the system is going to
a low power mode : all ports have been
Rowand frank.row...@sonymobile.com
Signed-off-by: Frank Rowand frank.row...@am.sony.com
Link: http://lkml.kernel.org/r/4e77b952.3010...@am.sony.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/mach-omap2/omap-smp.c | 10
On 03/06/2014 01:31 PM, Mugunthan V N wrote:
DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.
Cc: Sebastian Andrzej Siewior bige
On 04/29/2014 09:58 AM, George Cherian wrote:
This is easily fixed by moving the node at the beggining of the child
list,
so it's probed first.
This will give issues on module removal.
Since we use device_for_each_child in remove patch, it will try to
remove cppi dma controller, while the
On 04/29/2014 10:27 AM, George Cherian wrote:
Hi Sebastian,
Hi George,
On 4/29/2014 1:36 PM, Sebastian Andrzej Siewior wrote:
On 04/29/2014 09:58 AM, George Cherian wrote:
This is easily fixed by moving the node at the beggining of the child
list,
so it's probed first.
This will give
On 05/09/2014 08:22 AM, George Cherian wrote:
Just by remodelling the dt the whole problem can be solved.
I am still not convinced why we should not be doing it?
Because neither ways its not the exact representation of the H/W.
Ha. Now I am confused. First I assumed that the musb_am335x module
based on the line argument.
For runtime suspend I need access to this struct not only to make
serial_out() work but also to properly restore up-ier and up-mcr.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250
as
pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
device.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 101 +++-
1 file changed, 88 insertions(+), 13 deletions(-)
diff --git a/drivers/tty
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wakeup irq which should to be
requested enabled at -startup() time.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 11
serial_omap_get_context_loss_count() enable_wakeup() are
NULL pointer (in the omap-serial driver). So I am not sure how
this supposed to work :)
- added omap_8250_set_termios()
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 8
On 07/03/2014 09:34 AM, Tony Lindgren wrote:
Heh. Just to summarize the reason ttyO needs to be a separate name
and device entry from ttyS is because we also have external 8250
devices on GPMC and hotplug busses.
So the GPMC devices will first get a higher minor/device number. The
internal
The core complains that the number 343 is too large. The older code has
here 124. This avoids the warning, the driver hasn't been tested.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
for CPSW and MDIO by removing the
macro definitons to match the 3.8 implementation.]
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/dra7-evm.dts | 61 ++
arch/arm/boot/dts/dra7.dtsi
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 96
On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote:
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
I reverted my patch, applied this one and after boot I got:
|platform 48485000.mdio: Cannot lookup hwmod 'davinci_mdio'
|cpsw 48484000.ethernet: _od_fail_runtime_resume:
On 2014-07-09 11:55:52 [+0200], Sebastian Andrzej Siewior wrote:
On 2014-07-08 18:46:39 [+0530], Mugunthan V N wrote:
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
I reverted my patch, applied this one and after boot I got:
Oh me dum dum. I had --dry-run…
Acked
On 07/09/2014 12:07 PM, sourav wrote:
Hi,
Hello, Sourav,
The number is correct and is complaining just because the crossbar stuff
is not
put in. I had already posted a patch[1] to remove interrupt binding as
of now.
Hence, NAK for this patch.
Thank you for explanation. What is the
On 07/09/2014 01:17 PM, Tony Lindgren wrote:
* One Thousand Gnomes gno...@lxorguk.ukuu.org.uk [140707 06:22]:
On Fri, 4 Jul 2014 18:34:10 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
While comparing the OMAP-serial and the 8250 part of this I noticed that
the the latter does
On 07/09/2014 01:48 PM, Tony Lindgren wrote:
So we can certainly enable this in a generic way, however, this
can only be done under the following conditions:
Sorry forgot to mention why I think this can now be done in a
generic way, that's because we have now runtime PM in Linux.
I have a
On 07/09/2014 05:12 PM, Tony Lindgren wrote:
And also please note that for runtime PM the wake-up events need
to be always enabled, so the device_may_wakeup() checks should
be only implemented for suspend and resume. I think I got that
corrected for most part in omap-serial.c recently, but
On 07/07/2014 03:09 PM, One Thousand Gnomes wrote:
Please update the patch to clearly describe the locking
assumptions/requirements for the caller (and not to use it unless you
have no other choice)
done.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
On 07/07/2014 03:09 PM, One Thousand Gnomes wrote:
On Fri, 4 Jul 2014 18:34:09 +0200
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wakeup irq which should to be
requested
based on the line argument.
For runtime suspend I need access to this struct not only to make
serial_out() work but also to properly restore up-ier and up-mcr.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250.h | 2 ++
drivers/tty/serial/8250
as
pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
device.
Cc: mika.westerb...@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 101 +++-
1 file changed, 88 insertions(+), 13
omap_8250_set_termios()
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 8 +
drivers/tty/serial/8250/8250_omap.c | 881
drivers/tty/serial/8250/Kconfig | 9 +
drivers/tty/serial/8250/Makefile| 1
This is version three of the patch set. Unless something serious comes up
I would drop the RFC on the next post.
So far I should have everything covered up comparing to the omap-serial
driver except for the throttle callbacks. And now I would slowly start
looking into DMA support…
Sebastian
--
With the upcomming rs485 support it is required that
serial8250_stop_rx() is called from serial8250_start_tx(). With this
reordering there is no need for a forward declaration of the former
function.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250
taken from omap-serial driver and
received limited tested due to -ENODEV (the compiler said it works).
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_core.c | 171
include/linux/serial_8250.h | 6 ++
2
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wakeup irq which should to be
requested enabled at -startup() time and disabled at -shutdown() time.
v1…v2: add shutdown callback
Signed-off-by: Sebastian Andrzej Siewior bige
+Subject
On 2014-07-09 19:49:31 [+0200], Sebastian Andrzej Siewior wrote:
This is version three of the patch set. Unless something serious comes up
I would drop the RFC on the next post.
So far I should have everything covered up comparing to the omap-serial
driver except for the throttle
On 07/09/2014 07:49 PM, Sebastian Andrzej Siewior wrote:
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wakeup irq which should to be
requested enabled at -startup() time and disabled at -shutdown() time.
v1…v2: add shutdown
On 07/10/2014 09:09 AM, Tony Lindgren wrote:
You can test this pretty easily on beagleboard xm for example
using v3.16-r4:
I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and
am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even
want to show MLO/U-boot) with
On 07/09/2014 09:01 PM, Lennart Sorensen wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index c7c3bf7..bf06a4c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1281,10 +1283,34 @@ static void
On 2014-07-15 20:21:21 [+], Paul Walmsley wrote:
Hi Sebastian,
Hi Paul,
Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
This is basically what Tony hasked me to do: No IRQ numbers iomem.
Sorry - I'm a bit confused - Sebastian, did you test this one? If so
On 07/10/2014 04:30 PM, Olivier Galibert wrote:
On Wed, Jul 9, 2014 at 7:49 PM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
+ * The lock assumption made here is none because runtime-pm suspend/resume
+ * callbacks should not be invoked there is any operation performed on the
port
On 07/10/2014 08:28 AM, Tony Lindgren wrote:
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -571,7 +573,17 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
serial_out(p, UART_EFR, 0);
101 - 200 of 434 matches
Mail list logo
