On 11/26/2012 10:02 PM, Felipe Balbi wrote:
Hi,
On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
Felipe,
On 11/21/2012 03:39 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
All ports have similarly named port clocks so we can
On 11/21/2012 03:52 PM, Felipe Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
OMAPs till date can have upto 3 ports. We need to initialize
s/upto/up to/
the port mode in HOSTCONFIG register for all of them.
why *all* of them ? Isn't it enough to initialize
Hello.
On 27-11-2012 0:11, Felipe Balbi wrote:
This patch fixes the following:
WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference from
the function dma_controller_create() to the function
.init.text:cppi_controller_start()
The function __devinit
Hi Greg,
I will make a patch as instructed by Sarah and will verify the same with
our Host controller.
Thanks,
Bhavik Kothari
On Tuesday 27 November 2012 04:30 AM, Greg KH wrote:
On Mon, Nov 26, 2012 at 06:53:07PM +0530, Bhavik Kothari wrote:
Hi Greg Sarah,
Would please tell us, what
Hi Cyril,
Thank you for the patch.
On Sunday 25 November 2012 02:58:19 Cyril Roelandt wrote:
Found using the following semantic patch:
spml
@@
@@
spin_lock_irqsave(...);
... when != spin_unlock_irqrestore(...);
* GFP_KERNEL
/spml
Signed-off-by: Cyril Roelandt tipec...@gmail.com
On 11/27/2012 03:28 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
in fact, I would convert this construct into a switch which would look
like:
reg = ~(OMAP4_P1_MODE_MASK i * 2);
switch (port_mode[i]) {
case OMAP4_P1_MODE_TLL:
reg |=
On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
linus.wall...@stericsson.com wrote:
From: Haipeng YU haipeng...@stericsson.com
When a device is switched off by software, gserial_cleanup will
be called, and switch
On Tue, Nov 27 2012, Andrzej Pietrasiewicz andrze...@samsung.com wrote:
I think we _still_ need a way to programmatically create/remove configfs
directories. Without it, this: After name is written it will request
the module and special configuration related files pop up.
On Tue, Nov 27, 2012 at 03:52:54PM +0300, Dzianis Kahanovich wrote:
Please, add to option.c:
vendor=0x1ff4 product=0x600e
This is Nexpring np10t terminal (ev-do rev.a usb modem). Distributed by
BelCel
(tm: Diallog) operator - http://www.belcel.by (http://www.diallog.by).
Product:
I believe the drivers/net/usb patches should be CCed to linux-usb for
review, because they often touch USB specific things. So I added that
CC and did not strip any of the quoted text.
Steve Glendinning steve.glendinn...@shawell.net writes:
This patch splits out the logic for entering suspend
On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem with adding luns and there seems nothing
wrong with having lun3 and 4 and leaving 0 and 1
On 11/26/2012 07:46 PM, Alan Stern wrote:
On Mon, 26 Nov 2012, Michal Nazarewicz wrote:
On Mon, Nov 26 2012, Alan Stern wrote:
In your example, what files would appear under under
/functions/storage? I gather that the storage part is just a
placeholder name with no real meaning. The meaning
On Tue, 27 Nov 2012, Oliver Neukum wrote:
On Monday 26 November 2012 13:40:28 Alan Stern wrote:
Of course, there would still be a problem if the system was suspended
while this program was running and using the modem. There's no way to
tell usbfs that remote wakeup is required.
On Tuesday 27 November 2012 10:30:02 Alan Stern wrote:
I disagree. The usbfs interface is not as capable as the kernel's
internal API; that has always been true. One of its limitations is the
inability to request remote wakeups. We could add that to usbfs, but
for now it isn't there.
Yes.
On 11/27/2012 09:57 AM, Andrzej Pietrasiewicz wrote:
|mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
|mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
|mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_1
So you setup two luns without this patch. Would that work for you?
I think we _still_
On 11/27/2012 10:19 AM, Andrzej Pietrasiewicz wrote:
ALIAS() to have a string which can be referred to in adapters, which
provide the old modprobe + parameters (+ e.g. sysfs) interface and
should be able to request_module(usb_functions); The string could be
defined in some header file included
On Tue, 27 Nov 2012, Oliver Neukum wrote:
On Tuesday 27 November 2012 10:30:02 Alan Stern wrote:
I disagree. The usbfs interface is not as capable as the kernel's
internal API; that has always been true. One of its limitations is the
inability to request remote wakeups. We could add
This driver will be used for every Freescale SoC which has this misc
memory layout to control the basic usb handling. So better name this
driver, function and struct names in a more generic way.
Reported-by: Fabio Estevam feste...@gmail.com
Signed-off-by: Michael Grzeschik
From: Marc Kleine-Budde m...@pengutronix.de
This fixes a potential race condition where the ci13xxx_imx glue code
could be fast enough to call one of the usbmisc_ops before he got a
valid value on the static usbmisc pointer. To fix that we first set
usbmisc, then call usbmisc_set_ops().
From: Marc Kleine-Budde m...@pengutronix.de
The probe function checks usbmisc to be NULL in the beginning. Without
this patch the can only be loaded once.
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
Changes since v1:
*
Nearly every SoC from Freescale has this non-core usb registers. This series
adds support for more users of this driver.
This series is based on Peter Chen's work. Its needed to merge his master branch
before applying this series:
https://github.com/hzpeterchen/linux-usb.git
Changes since v3:
*
This adds a post handling routine which is called after
ci13xxx_add_device was called. The first user is the mx25, which has to
disable the external-vbus-divider after the udc has started.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde
From: Marc Kleine-Budde m...@pengutronix.de
This attaches the usbmisc_ops to the of_device_id data and
makes it possible to define special functions per soc.
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
Changes since v2:
*
This adds mx53 as the next user of the usbmisc driver and makes it
possible to disable the overcurrent-detection of the internal phy.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
Changes since v2:
* added defines for register
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller driver.
When this discussion started, Felipe argued against such an approach.
On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
On 11/20/2012 01:22 AM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Kevin,
On 11/16/2012 10:08 PM, Kevin Hilman wrote:
Roger Quadros rog...@ti.com writes:
Hi,
This patchset addresses the following
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do things there.
But the cost of that is like the tuple suggestion,
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller driver.
When
On Mon, 26 Nov 2012, Chris Holland wrote:
You don't need to take out the PCI card. Just plug the keyboard and
wheel mouse into the motherboard (or into a hub attached to the
motherboard) instead of into the PCI card. Leave the optical mouse
unplugged for the test.
Well I did any way.
On Tue, Nov 27, 2012 at 03:11:15PM +0100, Linus Walleij wrote:
On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij linus.wall...@linaro.org
wrote:
On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
linus.wall...@stericsson.com wrote:
From: Haipeng YU haipeng...@stericsson.com
When a device
On Tue, 27 Nov 2012, Daniel Mack wrote:
OK, this time I got some real results. I can still get the USB packet
stream to misbehave, and indeed the synthesized data is being lost.
The output data present on the USB bus smoothly increments during
each packet, continuing smoothly in
On Tue, Nov 27, 2012 at 10:53:57AM +0100, Sebastian Andrzej Siewior wrote:
On Wed, Nov 21, 2012 at 02:04:26PM +, Alan Cox wrote:
I don't see any problems in my testcase.
This looks fine to me as by the time we call tty_ldisc_release we have
already set TTY_CLOSING on both sides.
On Tue, Nov 27, 2012 at 11:48:41AM +0800, Ming Lei wrote:
Hi,
On Thu, Nov 22, 2012 at 10:35 AM, Ming Lei ming@canonical.com wrote:
In the fail1~fail5 failure path, pm_runtime_disable() should
be called to avoid 'Unbalanced pm_runtime_enable' error in
next probe() which may be
On Tue, Nov 27, 2012 at 09:05:02AM +0530, Sachin Kamat wrote:
ping
Really? This is that important? :)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do
On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable
Hi Bjorn,
On 27 November 2012 17:21, Steve Glendinning st...@shawell.net wrote:
Hi Bjorn,
+ smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
As mentioned in another comment to the smsc95xx driver: This is weird.
Do you really need to do that?
This is an USB interface driver. The
Steve Glendinning st...@shawell.net writes:
Hi Bjorn,
On 27 November 2012 17:21, Steve Glendinning st...@shawell.net wrote:
Hi Bjorn,
+ smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
As mentioned in another comment to the smsc95xx driver: This is weird.
Do you really need to do
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice, but there
On Tue, 27 Nov 2012, Bjørn Mork wrote:
Steve Glendinning st...@shawell.net writes:
Hi Bjorn,
On 27 November 2012 17:21, Steve Glendinning st...@shawell.net wrote:
Hi Bjorn,
+ smsc75xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);
As mentioned in another comment to the
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
struct device_asset {
char *name; /* name of regulator, clock,
On Sat, 24 Nov 2012 20:59:12 +0800
Ming Lei ming@canonical.com wrote:
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime PM and block device
error handling path. Traditionly, the problem is addressed by passing
GFP_NOIO
On Mon, Nov 26, 2012 at 01:35:46PM -0500, Alan Stern wrote:
On Mon, 26 Nov 2012, Sarah Sharp wrote:
Is port-disabling the only place where this problem occurs?
Probably not.
A more defensive approach would be to copy what ohci-hcd does. When a
port-change interrupt occurs, the
Hi Alan,
Could you take a look at this patchset since you asked Tianyu to
refactor the hub code into new files?
Thanks,
Sarah Sharp
On Sat, Nov 17, 2012 at 05:19:54PM +0800, Lan Tianyu wrote:
This patch is to create driver/usb/core/(port.c,hub.h) files and move usb
port related code into
On Saturday, November 24, 2012 08:59:14 PM Ming Lei wrote:
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable deadlock.
As explained in the comment, any GFP_KERNEL allocation
On Saturday, November 24, 2012 08:59:17 PM Ming Lei wrote:
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume/runtime_suspend callback on device with
the flag of 'memalloc_noio' set.
Cc: Alan Stern
On Tue, 27 Nov 2012, Sarah Sharp wrote:
Do I need to stop the polling when the host controller is suspended and
restart it when it's resumed? It seems like OHCI does that, but I can't
tell if it's host-specific. Or will the USB core just take care of
stopping and restarting the hub timer?
On Tuesday, November 27, 2012 10:19:29 PM Rafael J. Wysocki wrote:
On Saturday, November 24, 2012 08:59:14 PM Ming Lei wrote:
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable
On Mon, Nov 19, 2012 at 06:59:54PM +0530, Bhavik Kothari wrote:
Hi Sarah,
Please find answers as aligned,
On Fri, Nov 16, 2012 at 11:36 PM, Sarah Sharp sarah.a.sh...@linux.intel.com
wrote:
On Fri, Nov 16, 2012 at 10:19:01AM -0500, Alan Stern wrote:
On Thu, 15 Nov 2012, Greg KH
On Wed, Nov 28, 2012 at 1:55 AM, Andy Green andy.gr...@linaro.org wrote:
On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices
On Sat, Nov 17, 2012 at 05:19:50PM +0800, Lan Tianyu wrote:
This patch is to set xhci root hub's DeviceRemovable according to usb port's
connect type which currently comes from ACPI information rather than xhci
PORTSC
register due to Windows prefers to ACPI information. If ACPI information
On Wed, Nov 28, 2012 at 1:23 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Nov 27, 2012 at 11:48:41AM +0800, Ming Lei wrote:
Hi,
On Thu, Nov 22, 2012 at 10:35 AM, Ming Lei ming@canonical.com wrote:
In the fail1~fail5 failure path, pm_runtime_disable() should
be
On Wed, Nov 28, 2012 at 7:06 AM, Ming Lei tom.leim...@gmail.com wrote:
Also from my intuition, power domain should be involved in the problem,
because these hard-wired and self-powered USB devices should have
its own power domains, and the ehci-omap driver may enable/disable
these power
On Tue, Nov 27, 2012 at 10:54:32AM +0100, Michael Grzeschik wrote:
I didn't figure out why this is needed. However, we prefer to move this
hunk to be in ci_hdrc_probe just before ci_role_start gets called. So
hw_portsc_configure will be called only there in the beginning. As the
phy setup
On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
On Tue, Nov 27, 2012 at 05:16:55PM +0100, Michael Grzeschik wrote:
Nearly every SoC from Freescale has this non-core usb registers. This series
adds support for more users of this driver.
This series is based on Peter Chen's work. Its needed to merge his master
branch
before applying this
The patches are divied into 4 parts
1. bug fixes
usb: gadget: mv_udc: use udc_start and udc_stop functions
usb: gadget: mv_udc: use devm_xxx for probe
usb: gadget: mv_udc: fix the clk APIs
usb: otg: mv_otg: use devm_xxx for probe
usb: otg: mv_otg: fix the clk APIs
usb: host: ehci-mv:
This patches converts the driver into the new style start/stop
interface. As a result the driver no longer uses the static
global the_conroller variable.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/gadget/mv_udc_core.c | 81 +-
1 files
use devm_xxx for udc driver probe. So we do need care about
the resources release in driver remove or failure handling
in driver probe.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/gadget/mv_udc_core.c | 156 ++
1 files changed, 56
the clock common driver changes, and arch-mmp will make use of
the common clock driver instead of its own.
So for enable clock.
first prepare the clock
then enable the clock.
for disable clock
first disable the clock
then unprepare the clock
Signed-off-by: Chao Xie chao@marvell.com
---
use devm_xxx for otg driver probe. So we do need care about
the resources release in driver remove or failure handling
in driver probe.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/otg/mv_otg.c | 82 -
1 files changed, 22
Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-mv.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 6c56297..3065809 100644
---
usally we will use udc-tranceiver == NULL or
udc-tranceiver != NULL.
So when failed to get the udc-tranceiver by usb_get_phy(), we
directly set udc-tranceiver to be NULL.
Then the source code will not need macro IS_ERR_OR_NULL() for
udc-tranceiver judgement. It can reduce the line size and make
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of
add the udc/otg/ehci devices for mmp2
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/include/mach/mmp2.h |4
arch/arm/mach-mmp/mmp2.c |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/include/mach/mmp2.h
for brownstone board, add the udc/otg/ehci support
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/brownstone.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c
Originaly, otg driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of
phy setting are formatted into a phy driver at drivers/usb/phy,
we do not need do the setting in SOC files.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/devices.c | 278 -
arch/arm/mach-mmp/include/mach/regs-usb.h | 253
for ttc_dkb board, add udc/otg/ehci support
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/ttc_dkb.c | 30 +++---
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index
For the vbus and idpin detection. It may be completed by some
external chip, for example the pmic chip 88pm860x in driver/mfd
can do it.
Although the usb controller can detect the vbus and id pin, but
it need clock on and PHY enabled to detect the
vbus/idpin. It will increase the power.
Using the
Because arch-mmp will make use of irq domain for irq
allocation, the irqs allocated for PMIC is dynamical.
The vbus/idpin irqs from PMIC can not be passed by platform data.
Using the extern chip APIs provides by PHY driver can solve this
problem.
Marvell usb PHY driver provides a middle layer.
The
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-mv.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ehci-mv.c
It does the similar things as what we do for udc driver.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/otg/mv_otg.c | 63 -
drivers/usb/otg/mv_otg.h |3 ++
2 files changed, 31 insertions(+), 35 deletions(-)
diff --git
In original driver, we have callbacks in platform data, and some
dynamically allocations variables in platform data.
Now, these blocks are removed, the device tree support is easier
now.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/gadget/mv_udc.h |5 +-
Change the board support for usb as extern chip is supported
in marvell usb PHY driver
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/brownstone.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c
All blocks are removed. Add the device tree support for otg.
Signed-off-by: Chao Xie chao@marvell.com
---
drivers/usb/otg/mv_otg.c | 127 +
drivers/usb/otg/mv_otg.h |6 +-
2 files changed, 107 insertions(+), 26 deletions(-)
diff --git
All blocks are removed. Add the device tree support for ehci.
Signed-off-by: Chao Xie chao@marvell.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-mv.c | 104 +---
1 files changed, 79 insertions(+), 25 deletions(-)
diff
the clock common driver changes, and arch-mmp will make use of
the common clock driver instead of its own.
So for enable clock.
first prepare the clock
then enable the clock.
for disable clock
first disable the clock
then unprepare the clock
Signed-off-by: Chao Xie chao@marvell.com
---
On Wed, Nov 28, 2012 at 5:24 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Please don't duplicate code this way.
You can move that whole thing to rpm_callback(). Yes, you'll probably need to
check dev-power.memalloc_noio twice in there, but that's OK.
Good idea, I will update it in v7.
Thanks,
because phy is seperated from the usb controller driver,
we can use the common pxa_device_desc for device register.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/include/mach/pxa910.h |7 ---
arch/arm/mach-mmp/pxa910.c |4
2 files changed, 8
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/pxa168.c | 42 --
1 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c
index b7f074f..dd3a68b 100644
---
Change the board support for usb as extern chip is supported
in marvell usb PHY driver.
Signed-off-by: Chao Xie chao@marvell.com
---
arch/arm/mach-mmp/ttc_dkb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
Originaly, ehci driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform data, and at same time it removes one block in the
way of
The PHY is seperated from usb controller.
The usb controller used in marvell pxa168/pxa910/mmp2 are same,
but PHY initialization may be different.
the usb controller can support udc/otg/ehci, and for each of
the mode, it need PHY to initialized before use the controller.
Directly writing the phy
the clock common driver changes, and arch-mmp will make use of
the common clock driver instead of its own.
So for enable clock.
first prepare the clock
then enable the clock.
for disable clock
first disable the clock
then unprepare the clock
Signed-off-by: Chao Xie chao@marvell.com
Acked-by:
On Wed, Nov 28, 2012 at 5:19 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, November 24, 2012 08:59:14 PM Ming Lei wrote:
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable
On Wed, Nov 28, 2012 at 5:19 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Please use counters instead of walking the whole path every time. Ie. in
addition to the flag add a counter to store the number of the device's
children having that flag set.
Even though counter is added, walking the
Hi Sebastian Co,
On Tue, 2012-11-27 at 16:20 +0100, Sebastian Andrzej Siewior wrote:
On 11/26/2012 06:54 PM, Michal Nazarewicz wrote:
On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem
88 matches
Mail list logo
