E_CACHE_WB;
+ else
return _PAGE_CACHE_UC_MINUS;
-
- return _PAGE_CACHE_WB;
+
}
return req_type;
Best regards.
Gesendet: Montag, 12. August 2013 um 19:53 Uhr
Von: "Andy Lutomirski"
An: "Andreas Werner"
Cc: linux-kernel@vger.kernel.org
Betreff: Re: question about
return _PAGE_CACHE_UC_MINUS;
-
- return _PAGE_CACHE_WB;
+
}
return req_type;
Best regards.
Gesendet: Montag, 12. August 2013 um 19:53 Uhr
Von: Andy Lutomirski l...@amacapital.net
An: Andreas Werner wernera...@gmx.de
Cc: linux-kernel@vger.kernel.org
Betreff: Re: question about
Hi,
why are you curious?
I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.
I think i will commit the patch to the kernel and see what happens :-)
Best regards.
On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner wernera...@gmx.de
wrote:
Hi
Hi,
why are you curious?
I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.
I think i will commit the patch to the kernel and see what happens :-)
Best regards.
On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner wernera...@gmx.de
wrote:
Hi
On Fri, Aug 23, 2013 at 11:18 AM, Andreas Werner wernera...@gmx.de
wrote:
Hi,
why are you curious?
I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.
I've never tried it, but in theory it should be comparably fast as
compared to WT
With compiling and using this, have too much problems
/ In wil6210 some problem with call arguments ; that
messes the whole compilation of the kernel because gives
an error condition
/ ibmphpd :something run-time-wrong
/ in the second compilation stage, plenty modules or
> You need the USB 2.0 spec errata from 2011-11 that describes the changes
> made for BESL as well. It's in the USB2-LPM-Errata-final.pdf and
> USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
>
> http://www.usb.org/developers/docs/usb_20_070113.zip
>
> I agree though, it's all a
> Thanks for the patch! Did you test with a USB analyzer to see if the
> device was actually going into USB 2.0 Link PM? I'd like to confirm we
> really aren't breaking anything for DW3 hosts by enabling this.
Yes, I did. The LPM transfers on the analyzer look good and the device
works as
Thanks for the patch! Did you test with a USB analyzer to see if the
device was actually going into USB 2.0 Link PM? I'd like to confirm we
really aren't breaking anything for DW3 hosts by enabling this.
Yes, I did. The LPM transfers on the analyzer look good and the device
works as
You need the USB 2.0 spec errata from 2011-11 that describes the changes
made for BESL as well. It's in the USB2-LPM-Errata-final.pdf and
USB2_LinkPowerMangement_ECN[final].pdf files in this zip file:
http://www.usb.org/developers/docs/usb_20_070113.zip
I agree though, it's all a confusing
of an Exynos5420.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-plat.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 51e22bf..7f46b5d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -80,6
Hi Sarah,
I know you are probably swamped with patches, but this
(https://patchwork.kernel.org/patch/2612831/) has been hanging a few
months and I just wanted to double-check if it slipped through
somewhere. I still think this is necessary (regardless of any command
queue reengineering in the
Hi Sarah,
I know you are probably swamped with patches, but this
(https://patchwork.kernel.org/patch/2612831/) has been hanging a few
months and I just wanted to double-check if it slipped through
somewhere. I still think this is necessary (regardless of any command
queue reengineering in the
of an Exynos5420.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-plat.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 51e22bf..7f46b5d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host
>> I liked the ones where we had IS_ERR_OR_NULL() here (and in all the
>> ones below)... you sometimes have to handle PHYs in
>> platform-independent code where you don't want to worry about if this
>> platform actually has a PHY driver there or not. Any reason you
>> changed that?
>
> The
I liked the ones where we had IS_ERR_OR_NULL() here (and in all the
ones below)... you sometimes have to handle PHYs in
platform-independent code where you don't want to worry about if this
platform actually has a PHY driver there or not. Any reason you
changed that?
The **get_phy_*() APIs
Hi i have a question about ioremap_cache and the resulting PAT attribute on X86
system. If I configure the mtrr to Write-Through for an adress range, and call
ioremap_cache to map the mmio, the resulting PAT attribute is set to UC.
If I check the Intel document IA-32 SDM vol 3a, the resulting
Fixed a coding style issue of 80 character per line.
Signed-off-by: Andreas Werner
---
drivers/staging/imx-drm/imx-tve.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index a56797d
Fixed a coding style issue of 80 character per line.
Signed-off-by: Andreas Werner wernera...@gmx.de
---
drivers/staging/imx-drm/imx-tve.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
Hi i have a question about ioremap_cache and the resulting PAT attribute on X86
system. If I configure the mtrr to Write-Through for an adress range, and call
ioremap_cache to map the mmio, the resulting PAT attribute is set to UC.
If I check the Intel document IA-32 SDM vol 3a, the resulting
> Sorry, I don't understand what is not implemented. Without your patch, the
> PHY driver handles both PMU registers of Exynos4.
I don't have an Exynos4 to actually test this, so please let me know
if I'm missing something here... but in order to hit the right HOST
PHY register in the current
> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems
I'm not sure I understand. The old documentation referred to the
USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
your new version only refers to (usb device) PHY_CONTROL. Regardless of
multiple phys, you're suggesting that we describe less of each phy.
That seems like
Sorry, I don't understand what is not implemented. Without your patch, the
PHY driver handles both PMU registers of Exynos4.
I don't have an Exynos4 to actually test this, so please let me know
if I'm missing something here... but in order to hit the right HOST
PHY register in the current
> @@ -94,11 +94,11 @@ static int devm_usb_phy_match(struct device *dev, void
> *res, void *match_data)
> */
> struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
> {
> - struct usb_phy **ptr, *phy;
> + struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
This
> This breaks compatibility, both for an old kernel and a new dt and a new
> kernel with an old dt. Is anyone using these bindings?
They only affect Samsung SoCs and have only been upstream for half a
year, so I doubt it's heavily used.
> Why are we describing fewer registers now? Are they
This breaks compatibility, both for an old kernel and a new dt and a new
kernel with an old dt. Is anyone using these bindings?
They only affect Samsung SoCs and have only been upstream for half a
year, so I doubt it's heavily used.
Why are we describing fewer registers now? Are they
@@ -94,11 +94,11 @@ static int devm_usb_phy_match(struct device *dev, void
*res, void *match_data)
*/
struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
{
- struct usb_phy **ptr, *phy;
+ struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
This looks a
the same register.
Signed-off-by: Julius Werner
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 26 +-
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 ---
drivers/usb/phy/phy-samsung-usb.h
On Fri, Aug 2, 2013 at 12:51 AM, Felipe Balbi wrote:
> Hi,
>
> I need an Acked-by for the dtsi part. Ideally from Exynos 5 maintainer
> and at least one of the DT maintainers.
>
> --
> balbi
Okay, I think I forgot to update the DT bindings documentation
anyway... so I will resubmit this and
On Fri, Aug 2, 2013 at 12:51 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
I need an Acked-by for the dtsi part. Ideally from Exynos 5 maintainer
and at least one of the DT maintainers.
--
balbi
Okay, I think I forgot to update the DT bindings documentation
anyway... so I will resubmit this and
the same register.
Signed-off-by: Julius Werner jwer...@chromium.org
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 26 +-
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 ---
drivers/usb/phy
the same register.
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 --
drivers/usb/phy/phy-samsung-usb.h | 23 +--
drivers/usb/phy/phy-samsung-usb2.c | 11 ---
drivers/usb/phy/phy-samsung
Now that the sphy->pmuregs variable always points to only a single
register, let's rename it to make that more clear.
Signed-off-by: Julius Werner
---
drivers/usb/phy/phy-samsung-usb.c | 14 +++---
drivers/usb/phy/phy-samsung-usb.h | 4 ++--
drivers/usb/phy/phy-samsung-usb2.c |
-by: Julius Werner
---
drivers/usb/phy/phy-samsung-usb.c | 23 +++
drivers/usb/phy/phy-samsung-usb.h | 7 +--
drivers/usb/phy/phy-samsung-usb2.c | 19 +++
drivers/usb/phy/phy-samsung-usb3.c | 7 ---
4 files changed, 7 insertions(+), 49 deletions
distinction which was only needed for those removed parts.
Julius Werner (3):
usb: phy-samsung-usb: Simplify PMU register handling
usb: phy-samsung-usb: trivial: rename pmuregs variable
usb: phy-samsung-usb: Remove USB_PHY_TYPE from Samsung PHY driver
arch/arm/boot/dts/exynos5250.dtsi | 4
distinction which was only needed for those removed parts.
Julius Werner (3):
usb: phy-samsung-usb: Simplify PMU register handling
usb: phy-samsung-usb: trivial: rename pmuregs variable
usb: phy-samsung-usb: Remove USB_PHY_TYPE from Samsung PHY driver
arch/arm/boot/dts/exynos5250.dtsi | 4
Now that the sphy-pmuregs variable always points to only a single
register, let's rename it to make that more clear.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/phy/phy-samsung-usb.c | 14 +++---
drivers/usb/phy/phy-samsung-usb.h | 4 ++--
drivers/usb/phy/phy
the same register.
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung-usb.c | 18 --
drivers/usb/phy/phy-samsung-usb.h | 23 +--
drivers/usb/phy/phy-samsung-usb2.c | 11 ---
drivers
-by: Julius Werner jwer...@chromium.org
---
drivers/usb/phy/phy-samsung-usb.c | 23 +++
drivers/usb/phy/phy-samsung-usb.h | 7 +--
drivers/usb/phy/phy-samsung-usb2.c | 19 +++
drivers/usb/phy/phy-samsung-usb3.c | 7 ---
4 files changed, 7 insertions
> An odd sort of bug. You'd think that not getting a response back would
> be one of the first types of error the hardware designers would check
> for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
An odd sort of bug. You'd think that not getting a response back would
be one of the first types of error the hardware designers would check
for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
-by: Julius Werner
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4a8a1d6..558313d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4798,7 +4798,8 @@ static void hub_events
> Wait a moment. Why does each of these attempts lead to a 5-second
> timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected address because
it's internal bookkeeping is not yet updated, but
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
This patch makes the choice of reset dependent on the port status that
has just been read from the hub, as opposed to any previous in-kernel
state, thus working around this problem.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
.
This patch makes the choice of reset dependent on the port status that
has just been read from the hub, as opposed to any previous in-kernel
state, thus working around this problem.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Wait a moment. Why does each of these attempts lead to a 5-second
timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected address because
it's internal bookkeeping is not yet updated, but I
-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4a8a1d6..558313d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4798,7 +4798,8 @@ static
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung-usb.c | 51
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung
>> - if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
>> - reg = sphy->pmuregs + sphy->drv_data->devphy_reg_offset;
>> - en_mask = sphy->drv_data->devphy_en_mask;
>> - } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
>> - reg = sphy->pmuregs +
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers/usb/phy/phy-samsung
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
drivers
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy-pmuregs + sphy-drv_data-devphy_reg_offset;
- en_mask = sphy-drv_data-devphy_en_mask;
- } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy-pmuregs +
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb
the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung-usb.c | 51
Hi Jingoo,
Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).
The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control
Hi Jingoo,
Yeah, I followed that discussion back then, but it seems to have
stalled a little (at least the HSIC patches haven't been picked up in
any kernel.org repo yet to my knowledge).
The problem is that I think these approaches cannot work reliably. I
agree that it would be nice to control
Hi Felipe,
This is intended to pull down a reset signal line, not to switch power
to the device. I could implement that with the regulator framework
too, but I think that would just be confusing and harder to understand
without providing any benefit. It's really just a plain old GPIO.
--
To
Hi Felipe,
This is intended to pull down a reset signal line, not to switch power
to the device. I could implement that with the regulator framework
too, but I think that would just be confusing and harder to understand
without providing any benefit. It's really just a plain old GPIO.
--
To
to allow sleeping in the
critical section.
Change-Id: Ieecac52c27daa7a17a7ed3b2863ddba3aeb8d16f
Signed-off-by: Julius Werner
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 10 ++
drivers/usb/phy/phy-samsung-usb.c | 17 ++
drivers/usb/phy/phy-samsung-usb.h
to allow sleeping in the
critical section.
Change-Id: Ieecac52c27daa7a17a7ed3b2863ddba3aeb8d16f
Signed-off-by: Julius Werner jwer...@chromium.org
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 10 ++
drivers/usb/phy/phy-samsung-usb.c | 17 ++
drivers/usb/phy/phy
for that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner
---
drivers/base/power/wakeup.c | 5 +++--
include/linux/suspend.h | 1 +
kernel/power/main.c | 2 ++
3
for that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/base/power/wakeup.c | 5 +++--
include/linux/suspend.h | 1 +
kernel/power/main.c
Resending as plain text... sorry for the spam, Gmail just likes to
silently mess up my settings every once in a while.
On Tue, Jun 11, 2013 at 4:17 PM, Julius Werner wrote:
>
>> This is going to be done in the autosleep case too, which I'm slightly
>> concerned about.
>
Resending as plain text... sorry for the spam, Gmail just likes to
silently mess up my settings every once in a while.
On Tue, Jun 11, 2013 at 4:17 PM, Julius Werner jwer...@chromium.org wrote:
This is going to be done in the autosleep case too, which I'm slightly
concerned about.
If you
Remove an erroneous tab that should be a space.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index d3a1cce..73aeb87 100644
--- a/drivers/usb/misc/usb3503.c
actually requires (as per its data sheet). If certain boards
require more time to set up the reference clock, they should change this
through local patches or add a proper, configurable synchronization
mechanism.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 6 ++
1 file changed, 2
or a configurable mechanism (such as a device tree property).
Until then, let's keep all ports enabled.
Signed-off-by: Julius Werner
---
drivers/usb/misc/usb3503.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 73aeb87
that contain this chip.
Julius Werner (3):
usb: misc: usb3503: Fix up whitespace
usb: misc: usb3503: Remove hardcoded disabling of ports 2 and 3
usb: misc: usb3503: Remove 100ms sleep on reset, conform to data
sheet
drivers/usb/misc/usb3503.c | 16 +++-
1 file changed, 3 insertions
that contain this chip.
Julius Werner (3):
usb: misc: usb3503: Fix up whitespace
usb: misc: usb3503: Remove hardcoded disabling of ports 2 and 3
usb: misc: usb3503: Remove 100ms sleep on reset, conform to data
sheet
drivers/usb/misc/usb3503.c | 16 +++-
1 file changed, 3 insertions
or a configurable mechanism (such as a device tree property).
Until then, let's keep all ports enabled.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/misc/usb3503.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
Remove an erroneous tab that should be a space.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/misc/usb3503.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index d3a1cce..73aeb87 100644
--- a/drivers
actually requires (as per its data sheet). If certain boards
require more time to set up the reference clock, they should change this
through local patches or add a proper, configurable synchronization
mechanism.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/misc/usb3503.c | 6
for that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner
---
drivers/base/power/wakeup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/wakeup.c b
for that node to also print said log message if that write fails, so
that we can figure out the offending wakeup source for both kinds of
suspend aborts.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/base/power/wakeup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers
") and kill -9 the
process. However, you will have to pull in my other patch first ("usb:
xhci: Fix Command Ring Stopped Event handling"), or you may run into a
follow-up problem with cancelled commands that kills your whole HCD.
> On Fri, May 24, 2013 at 06:39:37PM -0700, Julius Werner
); dev.read()) and kill -9 the
process. However, you will have to pull in my other patch first (usb:
xhci: Fix Command Ring Stopped Event handling), or you may run into a
follow-up problem with cancelled commands that kills your whole HCD.
On Fri, May 24, 2013 at 06:39:37PM -0700, Julius Werner wrote
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic
3ffbba9511b4148cbe1f6b6238686adaeaca8feb "USB: xhci: Allocate
and address USB devices".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-hub.c | 7 +++
drivers/usb/host/xhci.c | 26 +++---
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/xh
to kernels as far as 3.0 that contain
the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI: handle
command after aborting the command ring".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 85 +---
1 file changed, 33 insertions(+), 52
to kernels as far as 3.0 that contain
the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d xHCI: handle
command after aborting the command ring.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-ring.c | 85 +---
1 file changed, 33
3ffbba9511b4148cbe1f6b6238686adaeaca8feb USB: xhci: Allocate
and address USB devices.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-hub.c | 7 +++
drivers/usb/host/xhci.c | 26 +++---
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner
Acked-by: Alan Stern
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c | 16
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner jwer...@chromium.org
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/usb.c | 33 +
drivers
> Does this patch fix the control transfer data stage issue? Please break
> this into a bug fix for that, with your refactoring on top of that. We
> need to backport the bug fix to the stable kernels, and queue the
> refactoring for 3.11.
I don't think there is really any practial adverse
Does this patch fix the control transfer data stage issue? Please break
this into a bug fix for that, with your refactoring on top of that. We
need to backport the bug fix to the stable kernels, and queue the
refactoring for 3.11.
I don't think there is really any practial adverse effect
in the callers.
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 111 +++
1 file changed, 29 insertions(+), 82 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..32629b2 100644
--- a/drivers/usb
in the callers.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-ring.c | 111 +++
1 file changed, 29 insertions(+), 82 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1969c00..32629b2
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner
Acked-by: Alan Stern
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c | 17
On Thu, Apr 25, 2013 at 7:38 AM, Alan Stern wrote:
> On Wed, 24 Apr 2013, Julius Werner wrote:
>
>> The current EHCI code sleeps a flat 110ms in the resume path if there
>> was a USB 1.1 device connected to its companion controller during
>> suspend, waiting for the devi
On Thu, Apr 25, 2013 at 7:38 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 24 Apr 2013, Julius Werner wrote:
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner jwer...@chromium.org
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/core/usb.c | 33 +
drivers
devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host/ehci-hub.c | 17
devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/usb.c | 33 +
drivers/usb/host
devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner
---
drivers/usb/host/ehci-hub.c | 21 +
1 file changed, 21 insertions(+)
diff --git
devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/ehci-hub.c | 21 +
1 file changed, 21 insertions
601 - 700 of 1003 matches
Mail list logo
