Re: [PATCH 00/21] On-demand device registration
Am 03.06.2015 um 23:12 schrieb Rob Clark: On Mon, May 25, 2015 at 10:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by registering devices as they are referenced by other devices. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. Something I'm not completely happy with is that I have had to move the call to of_platform_populate after all platform drivers have been registered. Otherwise I don't see how I could register drivers on demand as we don't have yet each driver's compatible strings. For machs that don't move of_platform_populate() to a later point, these patches shouldn't cause any problems but it's not guaranteed that we'll avoid all the deferred probes as some drivers may not be registered yet. I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these patches were enough to eliminate all the deferred probes. With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. So, complete drive-by comment (and I won't claim to be a DT expert, etc, etc, so take this with a few grains of salt), but why not push the problem to the DT compiler (or a pre-process step that could be run on existing DT blobs), which generates an optional DT node that is the recommended probe order? That seems like it avoids adding complexity into the early boot code (which seems like a good thing).. I've played with that approach too (as my patches for dtc do contain the same code I've put into the kernel, but decided that it doesn't make much sense. The sort algorithm is really small (some dozen lines), very fast (around 3-5ms on a omap) and might be later used to sort necessary module loading too. So there would be no advantage to put a sorted list into the DT. And having the sort algorithm in the kernel, would make it possible to use it for acpi or something else too, if they manage it to provide the necessary dependencies. Regards, Alexander Holler -- 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
Re: [PATCH 2/3] usb: chipidea: usbmisc_imx: delete clock information
Hi Peter, All imx usb controller's non core registers uses the same clock gate with core registers, the usbmisc_imx is the library for imx glue driver, the glue keeps clock on when it calls usbmisc_imx API to change non-core register. Besides, we will support runtime pm in the future, it also needs to close this clock when the usb is not in use. Philipp Zabel also verifies it at imx6q platform, see http://www.spinics.net/lists/linux-usb/msg118491.html Cc: Philipp Zabel p.za...@pengutronix.de Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/chipidea/usbmisc_imx.c | 19 --- 1 file changed, 19 deletions(-) This commit causes hard lockup when loading ci_hdrc_imx module on my iMX6DL (UDOO Dual) board. Specifically, on current git the lockup happens on read from USBNC register in usbmisc_imx6q_set_wakeup() in usbmisc_imx. This looks like the point where there is a first read from a register during attachment to device. Best regards, Maciej Szmigiero -- 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
[PATCH] phy: ulpi_phy: Add const qualifier to ops
The ops is never changed in ulpi_phy_create(), so make it const.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/phy/ulpi_phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/ulpi_phy.h b/drivers/phy/ulpi_phy.h
index ac49fb6..f2ebe49 100644
--- a/drivers/phy/ulpi_phy.h
+++ b/drivers/phy/ulpi_phy.h
@@ -5,7 +5,7 @@
* and it's controller, which is always the parent.
*/
static inline struct phy
-*ulpi_phy_create(struct ulpi *ulpi, struct phy_ops *ops)
+*ulpi_phy_create(struct ulpi *ulpi, const struct phy_ops *ops)
{
struct phy *phy;
int ret;
--
2.1.0
--
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
Re: [PATCH] usb: gadget: f_fs: do not set cancel function on synchronous {read,write}
On Wed, May 27, 2015 at 11:41:31AM +0100, Rui Miguel Silva wrote:
do not try to set cancel function in synchronous operations in
ffs_epfile_{read,write}_iter.
With, 70e60d917 gadget/function/f_fs.c: switch to -{read,write}_iter()
if CONFIG_AIO is disable there is no problem as kiocb_set_cancel_fn
is a nop, with this option enabled it will try to use ctx that is not
allocated for synchronous operations. And for that will dereference a
null at the set cancel function in any synchronous read/write.
ACK. And it's -stable fodder for 4.0
--
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
Re: [PATCH] usb: gadget: f_mass_storage: stop thread in bind failure case
On 6/4/2015 5:15 PM, Michal Nazarewicz wrote: On Thu, Jun 04 2015, Sanjay Singh Rawat wrote: After the worker thread is launched, bind function is doing further configuration. Stop the thread in case of failure. Also use kthread_run to encapsulate thread creation and launch. Sounds like two separate patches to me. Or perhaps better thing to do would be to create the thread and postpone it being run till the end of fsg_bind? ack, thanks for the review Michal. -- 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
Re: Support for OTG 2.0 in dwc3
Hi Joao, On Thu, 4 Jun 2015 15:46:04 -0500 Felipe Balbi ba...@ti.com wrote: On Thu, Jun 04, 2015 at 08:17:03PM +0100, Joao Pinto wrote: Hi Filipe! ^ e Hope you are doing well! sure am. At Synopsys we are developing a system using our DesignWare USB 3.0 Controller, configured to operate as an USB 2.0 (featuring OTG 2.0). yeah, there are quite a few devices in the market with that. I talked to Jonh Youn about this and he said that something was being done to make dwc3 driver support OTG 2.0. right, Roger Quadros has been working on that. I would like to know if you have any experimental code that we can use. If you agree we could help you in this task (involved in the development and beta testing) since we have the controller. sure, any help's welcome. Roger, have you got any comments ? This was my last public patchset http://thread.gmane.org/gmane.linux.kernel/1930830 Although it adds only dual-role capability, it does provide ground work to add full OTG support. I will be working on it in next couple of weeks. But I do not plan on implementing full OTG support. Only dual-role. Maybe you can chip in with OTG adaptation. cheers, -roger -- 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
Re: [PATCH 2/3] usb: chipidea: usbmisc_imx: delete clock information
On Fri, Jun 05, 2015 at 12:12:19AM +0200, Maciej S. Szmigiero wrote: Hi Peter, All imx usb controller's non core registers uses the same clock gate with core registers, the usbmisc_imx is the library for imx glue driver, the glue keeps clock on when it calls usbmisc_imx API to change non-core register. Besides, we will support runtime pm in the future, it also needs to close this clock when the usb is not in use. Philipp Zabel also verifies it at imx6q platform, see http://www.spinics.net/lists/linux-usb/msg118491.html Cc: Philipp Zabel p.za...@pengutronix.de Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/chipidea/usbmisc_imx.c | 19 --- 1 file changed, 19 deletions(-) This commit causes hard lockup when loading ci_hdrc_imx module on my iMX6DL (UDOO Dual) board. Specifically, on current git the lockup happens on read from USBNC register in usbmisc_imx6q_set_wakeup() in usbmisc_imx. The core and NC use the same clock (ahb clock), and the ci_hdrc_imx.c should already enable the clock before calling usbmisc_imx6q_set_wakeup, would you help dump stack to see what happens? Besides, have you added clock property at your usbotg node? This looks like the point where there is a first read from a register during attachment to device. Best regards, Maciej Szmigiero -- Best Regards, Peter Chen -- 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
Patch Request of option.c module to support Olicard-300 (2020:4000)
Hi all!
I'm a simple linux user, not a developer, but I just
added a new record to source of option usb serial
module (option.c) to add support for a usb internet
dongle: Olivetti Olicard-300.
Hope this is the right place to submit my changes so
that kernel developers can apply to next versions of
option driver.
Here we have usb-devices output:
# usb-devices |grep -B2 -A11 2020.*4000
T: Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2020 ProdID=4000 Rev=03.00
S: Manufacturer=Network Connect
S: Product=MT6225
C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
-
As you can see it has 7 interfaces...
Ifs: 2,3,4,5 are related to HSPA modem functions. We
can obtain this info also by looking to Windows verbose
description of the interfaces and is taken from the
windows driver pack for the dongle:
--
MI_00 Network Connect Mobile Broadband Device
MI_01 Network Connect Mobile Broadband Device
MI_02 Network Connect HSPA Plus Modem
MI_03 Network Connect HSPA Plus Application Interface
MI_04 Network Connect HSPA Plus Speech Port
MI_05 Network Connect HSPA Plus Debug Port
MI_06 USB Mass Storage Device
--
After talking about this dongle with usb_modeswitch
developers seems all these interfaces having Class
ff (vendor defined) has to be proper bound exactly
by option module. So I edited opition.c source as
follow:
--
$ grep OLICARD300 drivers/usb/serial/option.c
{ USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) }, /* OLICARD300 -
MT6225 */
Hope the last line will not be cutted by your mail
client due to its leinght...
Anyway I tested this new version of option module
and seems to work properly: when I plug the dongle
in usb_modeswitch changes product id from 0002 to
4000.
Then option module binds right interfaces only, letting
cdc_mbim and usb-storage manage theirs properly.
I've also created a patch as follows:
-
$ diff -up linux/drivers/usb/serial/option.c{.orig,} \
olivetti-olicard300-2020_4000.patch
$ cat olivetti-olicard300-2020_4000.patch
--- linux/drivers/usb/serial/option.c.orig 2015-06-05 00:27:28.0
+0200
+++ linux/drivers/usb/serial/option.c 2015-06-05 00:37:08.522933592 +0200
@@ -1678,6 +1678,7 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)net_intf6_blacklist },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) }, /* OLICARD300 -
MT6225 */
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung GT-
B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
---
I'll attach it to this message, hope it is a good
choice..
Any comments are greatly appreciated, it's my first
patch request! :)
Bye.
--- linux/drivers/usb/serial/option.c.orig 2015-06-05 00:27:28.0 +0200
+++ linux/drivers/usb/serial/option.c 2015-06-05 00:37:08.522933592 +0200
@@ -1678,6 +1678,7 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)net_intf6_blacklist },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
.driver_info = (kernel_ulong_t)net_intf4_blacklist },
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) }, /* OLICARD300 - MT6225 */
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
Re: [PATCH 00/21] On-demand device registration
Am 03.06.2015 um 21:57 schrieb grygorii.stras...@linaro.org: ... So few comments from above: - registering devices later during the System boot may improve boot time. But resolving of all deferred probes may NOT improve boot time ;) Have you seen smth like this? If someone is out for boot time reduction, I think one of the best ways would by making driver initialization parallel. Keep in mind that all linked in drivers currently are initialized in series. As it seems to have been forgotten or overread, I've mentioned in my series of patches last year that, with a few changes, it's possible to let the algorithm I've used (dfs) to spit out all drivers which can be initialized in parallel. But as I'm not paid for the work I've done and just did it out of curiosity, interest or how ever you want name it, I haven't spend any more time into that topic, especially as I'm missing the necessary connections to get patches into the kernel. ;) But, as said, it's easy (at least if aren't getting panic when it comes to a bit of algorithm theory) to get a list drivers you can start in parallel if you have such a complete list of dependencies as DT already offers. Just look at the pictures generate by dtc (using my patches), you will see, they already show which drivers can be initialized in parallel. So it would be easy to use e.g. all cores already very early at boot to initialize drivers, not just after init got started. Besides that the würgaround of defered init (which, btw. leads devs to supress error messages, which is especially bad if you are searching a problem) isn't needed anymore if you have a list of dependecies (however you get it, I've used DT because the dependencies already are all there). Regards, Alexander Holler -- 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
Re: Support for OTG 2.0 in dwc3
On Thu, Jun 04, 2015 at 08:17:03PM +0100, Joao Pinto wrote: Hi Filipe! ^ e Hope you are doing well! sure am. At Synopsys we are developing a system using our DesignWare USB 3.0 Controller, configured to operate as an USB 2.0 (featuring OTG 2.0). yeah, there are quite a few devices in the market with that. I talked to Jonh Youn about this and he said that something was being done to make dwc3 driver support OTG 2.0. right, Roger Quadros has been working on that. I would like to know if you have any experimental code that we can use. If you agree we could help you in this task (involved in the development and beta testing) since we have the controller. sure, any help's welcome. Roger, have you got any comments ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/1] USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle
On Thu, Jun 04, 2015 at 01:18:19PM -0700, John D. Blair wrote: From: John D. Blair jo...@candicontrols.com Added the USB serial device ID for the HubZ dual ZigBee and Z-Wave radio dongle. Signed-off-by: John D. Blair jo...@candicontrols.com Applied, thanks. Johan -- 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
Re: [PATCH 00/21] On-demand device registration
On 06/04/2015 11:39 AM, Tomeu Vizoso wrote:
On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
On 05/28/2015 07:33 AM, Rob Herring wrote:
On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com
wrote:
I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing
with
initcall levels.
While reading the thread [1] that Alexander Holler started with his series
to
make probing order deterministic, it occurred to me that it should be
possible
to achieve the same by registering devices as they are referenced by other
devices.
I like the concept and novel approach.
This basically reuses the information that is already implicit in the
probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.
Something I'm not completely happy with is that I have had to move the
call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't
have
yet each driver's compatible strings.
Yeah, this is the opposite of what we'd really like. Ideally, we would
have a solution that works for modules too. However, we're no worse
off. We pretty much build-in dependencies to avoid module ordering
problems.
Perhaps we need to make the probing on-demand rather than simply on
device-driver match occurring.
For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll
avoid
all the deferred probes as some drivers may not be registered yet.
Ideally, of_platform_populate is not explicitly called by each
platform. So I think we need to make this work for the default case.
I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.
With this series I get the kernel to output to the panel in 0.5s, instead
of 2.8s.
That's certainly compelling.
I've found your idea about moving device registration later during System
boot
very interesting so I've decided to try it on dra7-evem (TI) :).
It's good to know time during Kernel boot when we can assume that all
drivers are
ready for probing, so there are more ways to control probing order.
Thanks, though right now I'm following Rob's suggestion and only delay
probing, not registration. The patch is really simple (applies on
linux-next, with async probing):
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8da8e07..7e6b1e1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -407,6 +407,11 @@ int driver_probe_device(struct device_driver
*drv, struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;
+ if (!driver_deferred_probe_enable) {
+ driver_deferred_probe_add(dev);
+ return 0;
+ }
+
pr_debug(bus: '%s': %s: matched device %s with driver %s\n,
drv-bus-name, __func__, dev_name(dev), drv-name);
@@ -585,7 +590,7 @@ EXPORT_SYMBOL_GPL(device_attach);
void device_initial_probe(struct device *dev)
{
- __device_attach(dev, true);
+ __device_attach(dev, driver_deferred_probe_enable);
}
static int __driver_attach(struct device *dev, void *data)
Can't boot my 3.14 kernel with this change :( Most probably,
the problem is related to platform_driver_probe() usage :(
Have no time to play with it now :(, but recommend you to check also
earlyprintk, last log message I can see:
[1.435522] bootconsole [earlycon0] disabled
But, nice try ;) Seems -EPROBE_DEFER is reality of life which
has to be accepted as is.
Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of
DT and not DT devices/drivers.
Ok. So What was done...
LKML Linux 4.1-rc3 (a simple case)
1) use your patches 3/4 as reference (only these two patches :)
2) move of_platform_populate later at device_initcall_sync time
Boot time reduction ~0.4 sec
I'm a bit surprised at such a big improvement. May I ask how you are
measuring it?
Ah. My measurements are not precise. I've just tracking time of message
[4.110756] Freeing unused kernel memory: 344K (c0994000 - c09ea000)
TI Android Kernel 3.14 (NOT a simple case)
1) use your patches 3/4 as reference (only these two patches :)
2) move of_platform_populate later at device_initcall_sync time
3) make it to boot (not sure I've fixed all issues, but those which
break the System boot):
- split non-DT and DT devices registration in platform code;
- keep non-DT devices registration from .init_machine() [arch_initcall]
- move DT-devices registration at
[PATCH] usb: gadget: f_mass_storage: stop thread in bind failure case
After the worker thread is launched, bind function is doing further
configuration. Stop the thread in case of failure. Also use
kthread_run to encapsulate thread creation and launch.
Signed-off-by: Sanjay Singh Rawat snjs...@gmail.com
---
drivers/usb/gadget/function/f_mass_storage.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 3cc109f..835764a 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3005,7 +3005,7 @@ int fsg_common_run_thread(struct fsg_common *common)
common-state = FSG_STATE_IDLE;
/* Tell the thread to start working */
common-thread_task =
- kthread_create(fsg_main_thread, common, file-storage);
+ kthread_run(fsg_main_thread, common, file-storage);
if (IS_ERR(common-thread_task)) {
common-state = FSG_STATE_TERMINATED;
return PTR_ERR(common-thread_task);
@@ -3013,8 +3013,6 @@ int fsg_common_run_thread(struct fsg_common *common)
DBG(common, I/O thread pid: %d\n, task_pid_nr(common-thread_task));
- wake_up_process(common-thread_task);
-
return 0;
}
EXPORT_SYMBOL_GPL(fsg_common_run_thread);
@@ -3082,7 +3080,7 @@ static int fsg_bind(struct usb_configuration *c, struct
usb_function *f)
/* New interface */
i = usb_interface_id(c, f);
if (i 0)
- return i;
+ goto fail;
fsg_intf_desc.bInterfaceNumber = i;
fsg-interface_number = i;
@@ -3125,7 +3123,10 @@ static int fsg_bind(struct usb_configuration *c, struct
usb_function *f)
autoconf_fail:
ERROR(fsg, unable to autoconfigure all endpoints\n);
- return -ENOTSUPP;
+ i = -ENOTSUPP;
+fail:
+ kthread_stop(fsg-common-thread_task);
+ return i;
}
/** ALLOCATE FUNCTION */
--
1.8.3.2
--
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
Support for OTG 2.0 in dwc3
Hi Filipe! Hope you are doing well! At Synopsys we are developing a system using our DesignWare USB 3.0 Controller, configured to operate as an USB 2.0 (featuring OTG 2.0). I talked to Jonh Youn about this and he said that something was being done to make dwc3 driver support OTG 2.0. I would like to know if you have any experimental code that we can use. If you agree we could help you in this task (involved in the development and beta testing) since we have the controller. Hope hearing from you soon! Regards, Joao -- 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
Re: [PATCH 00/21] On-demand device registration
On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
Hi Tomeu,
On 05/28/2015 07:33 AM, Rob Herring wrote:
On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com
wrote:
I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing
with
initcall levels.
While reading the thread [1] that Alexander Holler started with his series
to
make probing order deterministic, it occurred to me that it should be
possible
to achieve the same by registering devices as they are referenced by other
devices.
I like the concept and novel approach.
This basically reuses the information that is already implicit in the
probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.
Something I'm not completely happy with is that I have had to move the call
to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't
have
yet each driver's compatible strings.
Yeah, this is the opposite of what we'd really like. Ideally, we would
have a solution that works for modules too. However, we're no worse
off. We pretty much build-in dependencies to avoid module ordering
problems.
Perhaps we need to make the probing on-demand rather than simply on
device-driver match occurring.
For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll
avoid
all the deferred probes as some drivers may not be registered yet.
Ideally, of_platform_populate is not explicitly called by each
platform. So I think we need to make this work for the default case.
I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.
With this series I get the kernel to output to the panel in 0.5s, instead
of 2.8s.
That's certainly compelling.
I've found your idea about moving device registration later during System boot
very interesting so I've decided to try it on dra7-evem (TI) :).
It's good to know time during Kernel boot when we can assume that all drivers
are
ready for probing, so there are more ways to control probing order.
Thanks, though right now I'm following Rob's suggestion and only delay
probing, not registration. The patch is really simple (applies on
linux-next, with async probing):
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8da8e07..7e6b1e1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -407,6 +407,11 @@ int driver_probe_device(struct device_driver
*drv, struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;
+ if (!driver_deferred_probe_enable) {
+ driver_deferred_probe_add(dev);
+ return 0;
+ }
+
pr_debug(bus: '%s': %s: matched device %s with driver %s\n,
drv-bus-name, __func__, dev_name(dev), drv-name);
@@ -585,7 +590,7 @@ EXPORT_SYMBOL_GPL(device_attach);
void device_initial_probe(struct device *dev)
{
- __device_attach(dev, true);
+ __device_attach(dev, driver_deferred_probe_enable);
}
static int __driver_attach(struct device *dev, void *data)
Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of
DT and not DT devices/drivers.
Ok. So What was done...
LKML Linux 4.1-rc3 (a simple case)
1) use your patches 3/4 as reference (only these two patches :)
2) move of_platform_populate later at device_initcall_sync time
Boot time reduction ~0.4 sec
I'm a bit surprised at such a big improvement. May I ask how you are
measuring it?
TI Android Kernel 3.14 (NOT a simple case)
1) use your patches 3/4 as reference (only these two patches :)
2) move of_platform_populate later at device_initcall_sync time
3) make it to boot (not sure I've fixed all issues, but those which
break the System boot):
- split non-DT and DT devices registration in platform code;
- keep non-DT devices registration from .init_machine() [arch_initcall]
- move DT-devices registration at device_initcall_sync time
- fix drivers which use platform_driver_probe().
Note. Now there are at about ~190 occurrences of this macro in Kernel.
- re-order few devices in DT (4 devices)
- fix one driver which uses of_find_device_by_node() wrongly
Note. This API is used some times with assumption that
requested dev has been probed already.
Boot time reduction ~0.3 sec. Probing of some devices are still deferred.
I got no deferred probes on a pandaboard with just these changes:
https://git.collabora.com/cgit/user/tomeu/linux.git/commit/?id=1586c6f50b3d3c65dc219a3cdc3327d798cabca6
Re: [PATCH] usb: gadget: f_mass_storage: stop thread in bind failure case
On Thu, Jun 04 2015, Sanjay Singh Rawat wrote:
After the worker thread is launched, bind function is doing further
configuration. Stop the thread in case of failure. Also use
kthread_run to encapsulate thread creation and launch.
Sounds like two separate patches to me. Or perhaps better thing to do
would be to create the thread and postpone it being run till the end of
fsg_bind?
Signed-off-by: Sanjay Singh Rawat snjs...@gmail.com
---
drivers/usb/gadget/function/f_mass_storage.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 3cc109f..835764a 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3005,7 +3005,7 @@ int fsg_common_run_thread(struct fsg_common *common)
common-state = FSG_STATE_IDLE;
/* Tell the thread to start working */
common-thread_task =
- kthread_create(fsg_main_thread, common, file-storage);
+ kthread_run(fsg_main_thread, common, file-storage);
if (IS_ERR(common-thread_task)) {
common-state = FSG_STATE_TERMINATED;
return PTR_ERR(common-thread_task);
@@ -3013,8 +3013,6 @@ int fsg_common_run_thread(struct fsg_common *common)
DBG(common, I/O thread pid: %d\n, task_pid_nr(common-thread_task));
- wake_up_process(common-thread_task);
-
return 0;
}
EXPORT_SYMBOL_GPL(fsg_common_run_thread);
@@ -3082,7 +3080,7 @@ static int fsg_bind(struct usb_configuration *c, struct
usb_function *f)
/* New interface */
i = usb_interface_id(c, f);
if (i 0)
- return i;
+ goto fail;
fsg_intf_desc.bInterfaceNumber = i;
fsg-interface_number = i;
@@ -3125,7 +3123,10 @@ static int fsg_bind(struct usb_configuration *c,
struct usb_function *f)
autoconf_fail:
ERROR(fsg, unable to autoconfigure all endpoints\n);
- return -ENOTSUPP;
+ i = -ENOTSUPP;
+fail:
+ kthread_stop(fsg-common-thread_task);
+ return i;
}
/** ALLOCATE FUNCTION */
--
1.8.3.2
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
--
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
Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
Hi Baolu, On Thu, May 28, 2015 at 08:50:12AM +0800, Lu, Baolu wrote: On 05/28/2015 12:53 AM, David Cohen wrote: Hi, On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote: On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote: Phy drivers and the ulpi interface providers depend on the registration of the ulpi bus. Ulpi registers the bus in module_init(). This could cause unnecessary probe delays. What do you mean by probe delays? I believe he meant the bus users' probe delays. i.e. unnecessary -EPROBE_DEFER happening on ulpi_drivers in case they're registered before ulpi bus itself. Is that correct, Baolu? Yes. Could you prepare one more version of this patche with the change log included. Thanks, -- heikki -- 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
Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
On 06/04/2015 08:17 PM, Heikki Krogerus wrote: Hi Baolu, On Thu, May 28, 2015 at 08:50:12AM +0800, Lu, Baolu wrote: On 05/28/2015 12:53 AM, David Cohen wrote: Hi, On Tue, May 26, 2015 at 07:37:02PM -0700, Greg Kroah-Hartman wrote: On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote: Phy drivers and the ulpi interface providers depend on the registration of the ulpi bus. Ulpi registers the bus in module_init(). This could cause unnecessary probe delays. What do you mean by probe delays? I believe he meant the bus users' probe delays. i.e. unnecessary -EPROBE_DEFER happening on ulpi_drivers in case they're registered before ulpi bus itself. Is that correct, Baolu? Yes. Could you prepare one more version of this patche with the change log included. Sure. I will resent it soon. Thanks, -- 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
[PATCH v5 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall
Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus. Ulpi registers the bus in
module_init(). This could cause unnecessary bus users'
probe delays. i.e. unnecessary -EPROBE_DEFER happening on
ulpi_drivers in case they're registered before ulpi bus
itself.
Reported-by: Zhuo Qiuxu qiuxu.z...@intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Acked-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v0-v5 change log:
Various changes in the commit description.
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
{
return bus_register(ulpi_bus);
}
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
static void __exit ulpi_exit(void)
{
--
2.1.4
--
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
RE: [PATCH v5 00/22] usb: third series of updates for dwc2 driver
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Monday, June 1, 2015 8:34 PM To: John Youn Cc: ba...@ti.com; Kaukab, Yousaf; Heiko Stuebner; linux-usb@vger.kernel.org; Herrero, Gregory; r.bald...@samsung.com; dingu...@opensource.altera.com; zhangfei@linaro.org; jwer...@chromium.org; sergei.shtyl...@cogentembedded.com Subject: Re: [PATCH v5 00/22] usb: third series of updates for dwc2 driver On Mon, Jun 01, 2015 at 06:16:03PM +, John Youn wrote: On 5/26/2015 8:21 AM, Felipe Balbi wrote: On Tue, May 26, 2015 at 03:18:32PM +, Kaukab, Yousaf wrote: -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, May 26, 2015 11:12 PM To: Heiko Stuebner Cc: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com; john.y...@synopsys.com; Herrero, Gregory; r.bald...@samsung.com; dingu...@opensource.altera.com; zhangfei@linaro.org; jwer...@chromium.org; sergei.shtyl...@cogentembedded.com Subject: Re: [PATCH v5 00/22] usb: third series of updates for dwc2 driver On Sun, May 24, 2015 at 12:33:39AM +0200, Heiko Stuebner wrote: Hi, Am Mittwoch, 29. April 2015, 22:08:58 schrieb Mian Yousaf Kaukab: Hi, This patchset consists of some bug fixes and feature enhancements for the dwc2 driver. All the patches are verified on dwc2 v3.0a with dedicated fifos. Main focus of testing was with dma enabled. Although basic testing without dma was also done. This is based on testing/next branch in Felipe's git. Thank you, Best regards, Yousaf History: v5: - Fixed comments from Felipe Balbi v4: - Fixed comment from Julius Werner v3: - Fixed comments from Julius Werner and Sergei Shtylyov - Dropped usb: dwc2: allow dwc2_pci to be a module even when dwc2 is statically linked due to http://marc.info/?l=linux-usbm=142661773703793w=2 - usb: dwc2: host: ensure qtb exists before dereferencing it is added to fix a NULL pointer dereferencing bug v2: - Fixed comments from John Youn and Julius Werner - Fixed regression, found by John, when switching to gadget mode after running host mode - Added patch to add core parameter for enabling/disabling hibernation - Added patch to build dwc2_pci.ko independent from dwc2.ko v1: - Fixed comments from John Youn and Robert Baldyga - Dropped all changes to pci.c due to http://permalink.gmane.org/gmane.linux.usb.general/123411 - Added patch to remove unnecessary EXPORT_SYMBOL_GPL calls With this series applied I get the warning below about a sleeping function, that is not present without it. This happens quite often (on boot, when going to suspend, etc). Other than that, usb still works and the dwc2 now also finally suspends :-D, so on a rk3288 Tested-by: Heiko Stuebner he...@sntech.de -- 8 -- [ 19.799200] BUG: sleeping function called from invalid context at mm/slab.c:2863 Will I see a patch for fixing this ? I am currently on a business trip and can't look into this for at least a couple of weeks. John, since this is your driver, could you fix it up ? Hi Felipe, I've been out of the office for the past 2 weeks and am catching up on stuff now. I'll take a look at it later this week if I don't hear anything from Yousaf. I have patches to fix this issue (and another one). I will send them out hopefully tomorrow. Cool, thanks a lot :-) -- balbi BR, Yousaf -- 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
