nt) Highspeed Dual-Role Controller
> config USB_MUSB_HDRC
> tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
> - depends on USB && USB_GADGET
shouldn't:
depends on USB_GADGET
be left here ?
--
balbi
signature.asc
Description: Digital signature
of_dma_configure(&xhci->dev, dwc->dev->of_node);
okay, so we have a long discussion about this going on. You can catch up
with it starting here:
http://marc.info/?i=1461612094-30939-1-git-send-email-grygorii.stras...@ti.com
At least for now, this patch will be app
Hi,
chunfeng yun writes:
> On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote:
>> Hi,
>>
>> chunfeng yun writes:
>> >> chunfeng yun writes:
>> >> > On Thu, 2016-04-21 at 10:04 +0800, Chunfeng Yun wrote:
>> >> >> C
this case properly, but it works out okay because the case never
> comes up.
see testusb :-) You did mention, on another thread, that you ran
testusb. And, btw, years ago I used to run these tests on daily basis on
MUSB. It also seems that Synopsys' XHCI (part of dwc3 when configured as
dual-role) is immune to this link TRB alignment limitation because I was
running hcd-tests.sh also on a daily basis on TI's AM437x SK and IDK
boards (one as host, one as peripheral).
--
balbi
signature.asc
Description: PGP signature
t; Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Florian Westphal
> ---
for u_ether.c:
Acked-by: Felipe Balbi
> diff --git a/drivers/usb/gadget/function/u_ether.c
> b/drivers/usb/gadget/function/u_ether.c
> index 637809e..a3f7e7c 100644
> --- a/drivers/usb/gadget/fun
descriptors ? What is your setup ?
Are you using an in-kernel gadget ? which one ? Using configfs or legacy
gadgets ? gadgetfs ? f_fs ? How to trigger this ? Can you provide
instructions and (in case of gadgetfs/ffs) code to create a gadget that
hits this problem ?
--
balbi
signature.asc
Description: PGP signature
Hi,
John Youn writes:
>> John Youn writes:
>>>> "Du, Changbin" writes:
>>>>> Hi, Balbi,
>>>>>
>>>>> The step to reproduce this issue is:
>>>>> 1) connect device to a host and wait its enumeration.
Hi,
chunfeng yun writes:
>> chunfeng yun writes:
>> > On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote:
>> >> Hi,
>> >>
>> >> chunfeng yun writes:
>> >> >> chunfeng yun writes:
>> >> >> > On Thu,
Hi Jim,
Jim Lin writes:
> On 2016年05月04日 18:37, Felipe Balbi wrote:
>> * PGP Signed by an unknown key
>>
>>
>> Hi,
>>
>> Jim Lin writes:
>>
>>
>>
>>>>> In f_fs.c
>>>>> "
>>>>> static i
Hema. I don't think it has any esoteric meaning ;-)
--
balbi
signature.asc
Description: PGP signature
gt; Is there any chance to advance this patch set ? It would be instrumental
> to get a unified interface to user space.
A newer version of $subject is already in Greg's queue [1]
[1]
https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=0c1849a8c7af652c92ad0265a7ca5934fd773c69
--
balbi
signature.asc
Description: PGP signature
Hi,
Alan Stern writes:
> On Wed, 4 May 2016, Felipe Balbi wrote:
>
>> > multiple of 512 bytes and the maxpacket size is 1024. Then you either
>>
>> that's not common case for testusb. One of the test cases (see below)
>> exercises exactly small sg ent
ding drivers if UDC with
> given name has not been found.
>
> Signed-off-by: Krzysztof Opasiak
Thank you, this is great. I'll apply it as soon as -rc1 is tagged :-)
--
balbi
signature.asc
Description: PGP signature
Hi,
Peter Chen writes:
>> "Du, Changbin" writes:
>> > Hi, Balbi,
>> >
>> > The step to reproduce this issue is:
>> > 1) connect device to a host and wait its enumeration.
>> > 2) trigger software disconnect by calling
Hi,
Peter Chen writes:
>> Peter Chen writes:
>> >> "Du, Changbin" writes:
>> >> > Hi, Balbi,
>> >> >
>> >> > The step to reproduce this issue is:
>> >> > 1) connect device to a h
ONFIG_USB_XHCI_RCAR.
>
> Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 and M2
> xHCI controllers)
> Cc: # v3.17+
>
> Signed-off-by: Yoshihiro Shimoda
looks good to me, thanks :)
Reviewed-by: Felipe Balbi
> ---
> Changes from v2:
> -
x27;m
> not sure if we have those anymore in the kernel.
We still have those, yes. But it seems like your stuff should be
integrated into composite.c itself under a #ifdef USB_GADGET_TESTING or
something like that.
If it helps IP providers using a real OS (linux, of course heh) for
silicon va
about this patch, so I'll let the other
folks who have been hacking on this to decide.
--
balbi
--
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
Hi,
Alan Stern writes:
> On Fri, 6 May 2016, Felipe Balbi wrote:
>
>> >> that's not a good idea, IMO. HCD drivers should be robust enough in
>> >> these situations.
>> >
>> > Why? Just so that hcd-tests.sh can complete with no errors
nchronizes with DMA operations.
> - On architectures that require specific CPU instructions for MMIO
> access, using the __raw_ variant may turn this into a pointer
> dereference that does not have the same effect as the readl/writel.
>
> I think we can simply make this set of accessors architecture-dependent
> (MIPS vs. the rest of the world) to revert ARM and PowerPC back to
> the working version.
and patch all drivers similarly? Shouldn't arch/mips itself deal with it
and hide it from drivers ?
--
balbi
signature.asc
Description: PGP signature
O),
> dump_register(GUID),
> --
> 1.9.1
>
>
> --
> 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
--
balbi
signature.asc
Description: PGP signature
|
| | the reset value is '1'.|
| ||
|-+|
You only need this because your core was badly configured in
coreConsultant.
--
balbi
signature.asc
Description: PGP signature
Hi William,
William Wu writes:
> On 05/09/2016 08:18 PM, Felipe Balbi wrote:
>> Hi,
>>
>> William Wu writes:
>>> Add snps,phyif_utmi_16_bits devicetree property. USB2 phy
>> this needs a quirk_ prefix...
> Yes, maybe a quirk is more proper. As
William Wu writes:
> On 05/09/2016 08:10 PM, Felipe Balbi wrote:
>> William Wu writes:
> Thanks Felipe Balbi and Greg KH. I'm really sorry that I forgot to
> add changelog.
>>> Signed-off-by: William Wu
>> no changelog = no commit, sorry. Why do you
ersonally I'd prefer that
> things here be sorted alphabetically. Sorting things in a consistent
> manner tends to reduce merge conflicts as the list gets longer and
> also makes it easier to find things.
I agree, let's keep it sorted :-)
--
balbi
signature.asc
Description: PGP signature
Documentation/devicetree/bindings/usb/rockchip,dwc3.txt, to match the
> pattern of qcom and xlnx? Or can we just add to dwc3.txt, since so far,
> all bindings are documented in the common file?
dwc3.txt is for dwc3.ko. We need separate files for rockchip, xilinx and
qualcomn :-)
--
balbi
signature.asc
Description: PGP signature
Hi William,
William Wu writes:
> Dear Felipe & Doug,
> Thanks for your proposal. It's a good idea to sort the list.
> I'll fix it next patch version.
cool, thanks.
ps: top-posting is frowned upon here. Please avoid it ;-)
--
balbi
signatu
ke I mentioned at above, OTG or USB function can't work if
>> it is built as module.
>
> Isn't this a limitation?
I agree, it should work built-in or module.
> As per the current implementation dual role works fine even with both
> USB_GADGET and HCD as module.
>
> In the real world it is unlikely that GADGET and HCD will be built-in.
we can't make this assumption, however :-)
--
balbi
signature.asc
Description: PGP signature
work with OTG irq on OMAP platforms.
>
> Signed-off-by: Roger Quadros
I have a feeling this will regress OMAP5432 uEVM. Did you test with that
board ?
cheers
--
balbi
signature.asc
Description: PGP signature
US[9] POWERPRESENT at its default value (=0), and only
> to
> fill in the USB2 VBUS status fields in the same register."
>
> Signed-off-by: Roger Quadros
to make sure we avoid regressions, do you mind sharing on which
platforms you tested this patch ?
--
balbi
signature.asc
Description: PGP signature
etter to have a NULL top half and
valid bottom half.
In fact, since this will be shared, you could do a proper preparation
and on top half check if $this device generated the IRQ and
conditionally schedule the bottom half. Don't forget to mask device's
interrupts from top half so you can run without IRQF_ONESHOT.
--
balbi
signature.asc
Description: PGP signature
+ res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
> + 0);
> + if (!res) {
> + dev_err(dwc->dev, "missing peripheral IRQ\n");
> + return -ENODEV;
> + }
> + dwc->gadget_irq = res->start;
> + }
> + }
>
> dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
> &dwc->ctrl_req_addr, GFP_KERNEL);
you're regressing dwc3_gadget_stop().
--
balbi
signature.asc
Description: PGP signature
Hi,
Roger Quadros writes:
> On 10/05/16 12:54, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros writes:
>>> TRM [1] recommends that POWERPRESENT bit must not be
>>> set and left at it's default value of 0.
>>>
>>> [1] OMAP
Hi,
Roger Quadros writes:
> On 10/05/16 12:55, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros writes:
>>> Don't make any decisions regarding VBUS session based on ID
>>> status. That is best left to the OTG core.
>>>
>&g
eg & BIT0)
handle_bit_0(omap);
if (reg & BIT1)
handle_bit_1(omap);
unmask_interrupts(omap);
spin_unlock(&omap->lock);
return IRQ_HANDLED;
}
this will *always* behave well with RT and non-RT kernels. It also
allows for the user to change priorities on these interrupt handlers if
necessary.
--
balbi
signature.asc
Description: PGP signature
t;> + int gadget_irq;
>>> + int otg_irq;
>>
>> while at that, let's add host_irq too and do proper changes to dwc3/host.c
>
> Sure. So we add host_irq here, and manually create an irq resource
> in dwc3_host_init?
right :-) Then the code looks similar for otg, peripheral and host parts ;-)
--
balbi
signature.asc
Description: PGP signature
ve a feeling this will regress OMAP5432 uEVM. Did you test with that
>>>> board ?
>>>>
>>>
>>> Yes. Any specific test case you would like me to test?
>>> For now I'm just doing enumeration with g_zero.
>>
>> IIRC OMAP5 uEVM didn't have separate VBUS and ID GPIOs. How are you
>> handling that case ?
>>
> It comes from the PMIC, extcon-palmas.c.
alright, then :-)
--
balbi
signature.asc
Description: PGP signature
Hi,
Roger Quadros writes:
> On 10/05/16 13:04, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros writes:
>>> On 10/05/16 12:54, Felipe Balbi wrote:
>>>>
>>>> Hi,
>>>>
>>>> Roger Quadros writes:
>>&
t; while at that, let's add host_irq too and do proper changes to dwc3/host.c
>>>
>>> Sure. So we add host_irq here, and manually create an irq resource
>>> in dwc3_host_init?
>>
>> right :-) Then the code looks similar for otg, peripheral and host parts ;-)
>>
> Just saw that host_irq is not used anywhere other than creating the XHCI
> platform
> device. So I don't see why we need host_irq in struct dwc3.
> It is obtained in dwc3_host_init() and consumed there itself.
fair enough.
--
balbi
signature.asc
Description: PGP signature
_t dwc3_omap_threaded_interrupt(int irq, void *_omap)
>> {
>> struct dwc3_omap *omap = _omap;
>> u32 reg;
>>
>> spin_lock(&omap->lock);
>
> Do we really need a spin_lock for the dwc3-omap driver?
> Currently we won't be doing anything other than just
> clearing the irqstatus and re-enabling the interrupts.
well, if there's no possibility of races, then no. But only testing will
say for sure, I guess. I didn't really go through the entire thing just
to a write a quick little template :-p
--
balbi
signature.asc
Description: PGP signature
e
> proccess. Actually, userspace applications should negotiate
no, this violates POSIX. Care to explain what problem are you actually
facing ?
--
balbi
signature.asc
Description: PGP signature
omap_writel(omap->base, USBOTGSS_IRQSTATUS_0 -
+ dwc3_omap_writel(omap->base, USBOTGSS_IRQSTATUS_RAW_0 -
omap->irq0_offset, value);
}
static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
{
- return
dropping. Most times the error can be detected by APP itself, but
why ? app did e.g. read(5), that caused driver to queue a usb_request
with length set to 512. Host sent more data than the expected 5 bytes,
why did host do that ? And if that data was needed, why didn't userspace
read() more than 5 ?
--
balbi
--
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
the application killed? Which
application was killed?), then why are we still connected to host at
all? It's clear that this gadget can't work without its userspace
counterpart. If that userspace isn't available, we should drop data
pullup and disconnect from host.
> These all can lead host send more than device wanted bytes. For sure
> it wrong at host side, but device side don't know.
but none of this means we have a bug at device side. In fact, by
allowing these extra bytes to reach userspace, we could be creating a
possible attack vector.
Your explanation is unsatisfactory, so I won't apply your patch, sorry.
--
balbi
--
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
y care about device side.
oh, application was killed on host side. I thought it was on device
side. Yeah, then we shouldn't disconnect.
>> > These all can lead host send more than device wanted bytes. For sure
>> > it wrong at host side, but device side don't know.
>>
&
Hi again,
Felipe Balbi writes:
> @@ -811,7 +815,12 @@ static ssize_t ffs_epfile_io(struct file *file, struct
> ffs_io_data *io_data)
>*/
> ret = interrupted ? -EINTR : ep->status;
> if (io_data->read && ret >
. In fact, by
>> >> allowing these extra bytes to reach userspace, we could be creating a
>> >> possible attack vector.
>> >>
>> >> Your explanation is unsatisfactory, so I won't apply your patch, sorry.
>> >>
>> >> --
&
. In fact, by
>> >> allowing these extra bytes to reach userspace, we could be creating a
>> >> possible attack vector.
>> >>
>> >> Your explanation is unsatisfactory, so I won't apply your patch, sorry.
>> >>
>> >> --
&
e
> do not need a new field.
/me goes read iov_iter_count()
you're right, we don't need expected len at all ;-)
in any case, did you figure out if the extra data host sends is
important data at all or just garbage ?
--
balbi
--
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
);
> -#ifdef DWC2_LOG_WRITES
> - pr_info("INFO:: wrote %08x to %p\n", value, addr);
> +#ifdef dwc2_log_writes
> + pr_info("info:: wrote %08x to %p\n", value, addr);
> #endif
> }
> +#else
I still think this is something that should be handled at MIPS side, no ?
How many more drivers will we have to 'fix' like this ?
--
balbi
--
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
Hi,
(Arnd, you didn't Cc dwc2's maintainer. I'm also not part of TI anymore)
Arnd Bergmann writes:
> On Thursday 12 May 2016 14:25:49 Felipe Balbi wrote:
>> > {
>> > u32 value = __raw_readl(addr);
>> >
>> > - /* In
ntil get enough data (which is
> normal For a general read). Then sometimes the buffer size for
> sys_read may not as expected. This is why I think ioctl approach is
> more appropriate for usb transfer.
no, this won't change anything. Besides, it's a pointless discussion as
cannot break userspace ABI. GadgetFS and FunctionFS have been shipping
in kernel for many years.
--
balbi
signature.asc
Description: PGP signature
| 4 ++
> 6 files changed, 117 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
I didn't get patch 5/5 :-s
--
balbi
signature.asc
Description: PGP signature
; +
> + if (dwc->gadget_driver) {
> + dev_err(dwc->dev, "%s is already bound to %s\n",
> + dwc->gadget.name,
> + dwc->gadget_driver->driver.name);
> + ret = -EBUSY;
> +
t;> Anyway, which platform are you dealing with? Why is dwc3 off while VBUS
>> is off? How do you handle host mode?
>
> On Spreadtrum platform, for thinking about some mobile devices with
I meant the SoC ;-) It's their own SoC? Are we getting glue-layer
patches any time soon?
> strict power management. This is just for gadget mode, we don't power
> off the dwc3 when it is host mode. Thanks.
okay, thanks
--
balbi
signature.asc
Description: PGP signature
How do you think this requirement?
>>
>> Well, seems like you're missing *proper* runtime PM. I've been meaning
>> to work on it for weeks, but I still have a few other things to do
>> before I get to that. In any case, we don't need to do what you did
>> here. There are better ways.
>
> Make sense.
cool, if you wanna work on it, let me know and I can give some details
of what I have in mind.
--
balbi
signature.asc
Description: PGP signature
Hi,
Alan Stern writes:
> On Fri, 13 May 2016, Felipe Balbi wrote:
>
>> We deliver to userspace the part userspace requested, right? So that's
>> okay. The USB details WRT e.g. babble or host trying to send more data
>> than expected, needs to be handled within the
t ask for all the
>>> data that he expected. Maybe the user wanted to retrieve the full
>>> set of data using two read() system calls.
>
> On Mon, May 16 2016, Felipe Balbi wrote:
>> right, but that just means we need to buffer the data instead of bailing
>> out of
Hi
Baolin Wang writes:
> Hi Felipe,
>
> On 13 May 2016 at 20:46, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang writes:
>>>>>> why does it need restart? Why is dwc3 powered off? Who powers it off?
>>>>>
>>>>>
ry to test on my platform to see what will happen.
great, thanks. You might need to patch your glue layer with proper
runtime_* callbacks, btw.
--
balbi
signature.asc
Description: PGP signature
ing the
series as to avoid dependencies between fixes and cleanups?
Thanks
ps: if you don't mind waiting for v4.8 it's fine. I'll start queueing
again once v4.7-rc1 is tagged.
--
balbi
signature.asc
Description: PGP signature
we *know* that our dwc3 interrupt is masked because
we masked it in the hardirq handler. This means we
don't need to disable all of current cpu's
interrupts.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
di
by holding gadget's IRQ number in dwc->irq_gadget,
it'll be simpler to free_irq() and disable the IRQ
in case an IRQ fires while we are runtime suspended.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 2 ++
drivers/usb/dwc3/gadget.c | 5 ++---
2 files changed, 4 ins
If we're going to issue a Update Transfer command,
let's clear LST bit from previous TRB. This will let
us continue processing TRBs and convert previous IRQ
into XferInProgress, instead of XferComplete.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gad
ring, we check if we have space to wrap around
the ring properly.
Note that this only happens when our enqueue and
dequeue pointers are equal (which is the case for
bulk endpoints after an XferComplete event).
Signed-off-by: Felipe Balbi
---
drive
To aid code readability, we're gonna split
__dwc3_gadget_kick_transfer() into its constituent
parts: scatter gather and linear buffers.
That way, it's easier to follow the code and focus
debug effort when one or the other fails.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadg
rnation is only useful for runtime
PM, not system sleep.
While at that, also remove dwc3.dcfg which has been
rendered unnecessary.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 1 -
drivers/usb/dwc3/gadget.c | 44
2 files changed, 12
rting point.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 118
1 file changed, 60 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1f4ac355f384..cbdefbb3d302 100644
--- a/drivers/usb
as it turns out, we don't need the extra 'start_new'
argument as that can be inferred from DWC3_EP_BUSY
flag.
Because of that, we can simplify
__dwc3_gadget_kick_transfer() by quite a bit, even
allowing us to prepare more TRBs unconditionally.
Signed-off-by: Felipe Balbi
---
d
we will be re-using it for suspend/resume, so
instead of duplicating code, let's just re-factor
the functions so they can be re-used.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 90 ++-
1 file changed, 49 insertions(+), 41 dele
this patch is in preparation for some further
re-factoring in dwc3 initialization. No functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 16 +++-
drivers/usb/dwc3/core.h | 2 ++
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb
rease
maximum number of storage buffers to a ridiculous
amount (256) so that anybody wanting to test maximum
achievable throughput can do so.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Kcon
sg_is_last() and list_is_last() will encode the
required information for the driver to make
decisions WRT CHN and LST bits.
While at that, also replace '1' with 'true' for
consistency.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 10 +-
1 file changed
now that we have re-factored dwc3_core_init() and
dwc3_core_exit() we can use them for suspend/resume
operations.
This will help us avoid some common mistakes when
patching code when we have duplicated pieces of code
doing the same thing.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c
valid range for storage buffers is encoded in
Kconfig already. Instead of checking again, let's
drop fsg_num_buffers_validate() altogether.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/function/f_mass_storage.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
Instead of waiting for !BUSY, we can kick bulk
endpoints more frequently and rely on the fact that
__dwc3_gadget_kick_transfer() will use Update
Transfer if BUSY flag is set.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 47 +++
1 file
e our debugfs interface and io
accessors need to be changed accordingly.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h| 13 +++-
drivers/usb/dwc3/debugfs.c | 190 ++---
drivers/usb/dwc3/ep0.c | 4 +-
drivers/usb/dwc3/gadget.c
v4.8 and
I'll keep them soaking on linux-next for as long as
I can (I want these patches soaking for at least 5
weeks there).
cheers
Felipe Balbi (22):
usb: dwc3: gadget: re-factor ->udc_start and ->udc_stop
usb: dwc3: gadget: fix gadget suspend/resume
usb: dwc3: core: get rid of
with LPM
enabled.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index db7bbbd0cecd..eca131f0be59 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/
umber];
to just passing struct dwc3_ep *dep as argument.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 8
drivers/usb/dwc3/ep0.c| 5 ++---
drivers/usb/dwc3/gadget.c | 33 +
3 files changed, 23 insertions(+), 23 deletions(-)
diff --gi
Instead of using burst size to configure NUMP, we
should be using RxFIFO Size instead. DWC3 is smart
enough to know that it shouldn't burst in case burst
size is 0.
Reported-by: John Youn
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 12 +++
drivers/usb/dwc3/gadget.c
When we send an endpoint command, we want that to
complete as soon as possible, so let's remove the
unnecessary udelay(1) call.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gad
that macro is unnecessary and just adds pointless
obfuscation. Let's remove it.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a590cd225bb7..245f4ff
As a micro-power optimization, let's only resume the
USB2 PHY if we're working on <=HIGHSPEED. If we're
gonna work on SUPERSPEED or SUPERSPEED+, there's no
point in resuming the USB2 PHY.
Fixes: 2b0f11df84bb ("usb: dwc3: gadget: clear SUSPHY bit before ep cmds&q
call the 'usb_gadget_udc_start()' and
> 'usb_udc_connect_control()', then if the dwc3 core has entered
> suspended mode, we need to return success when starting the gadget,
> and leave the gadget starting action from gadget resume. What do you
> think about that? Thanks.
Well, if this makes it work properly. Then, yeah; looks okay to me. I'll
add this to the patch introducing runtime PM.
Thanks a lot for testing on your side :-)
--
balbi
signature.asc
Description: PGP signature
ared when endpoint is disabled, we again silently
> drop data. On the other hand, if we don’t do that, read() on the
> endpoint will may succeed even if the configuration is disabled which
> may be surprising for users.
tough decision... but seems like clearing the buffer as soon as ep is
disabled is the way to go.
--
balbi
signature.asc
Description: PGP signature
make sure it still works ?
Basically, here's what I did:
on dwc3_gadget_start:
- __dwc3_gadget_start(dwc);
+ if (pm_runtime_active(dwc->dev))
+ __dwc3_gadget_start(dwc);
+
on run_stop, I kept the same thing.
you just need to replace "usb: dwc3: implement runtime PM" with the new
version from my branch.
cheers
--
balbi
signature.asc
Description: PGP signature
dwc);
>> + if (pm_runtime_active(dwc->dev))
>> + __dwc3_gadget_start(dwc);
>> +
>
> Great.
>
>>
>> on run_stop, I kept the same thing.
>>
>> you just need to replace "usb: dwc3: implement runtime PM" with the new
>> version from my branch.
>
> Yeah, it can work well on my platform with your new patch.
cool, thanks again :-) I'll drop my "not for merging note" and add your
"Tested-by" (assuming it's okay for you that I do it).
cheers
--
balbi
signature.asc
Description: PGP signature
nal commit and
making sure that we check for isochronous endpoints.
Fixes: f3af36511e60 ("usb: dwc3: gadget: always enable IOC
on bulk/interrupt transfers")
Cc:
Signed-off-by: Konrad Leszczynski
Signed-off-by: Rafal Redzimski
Signed-off-by: Felipe Balbi
---
drivers/u
's
avoid the problem by simply returning early if we
have a NULL descriptor.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8c06b8d64144..fb053a307a8b
Hi,
Paul Zimmerman writes:
> Felipe Balbi writes:
>
>> If we're going to issue a Update Transfer command,
>> let's clear LST bit from previous TRB. This will let
>> us continue processing TRBs and convert previous IRQ
>> into XferInProgress, inste
O Size, NUMP = RxFIFOSize / 1024;
>> + */
>> +static void dwc3_gadget_setup_nump(struct dwc3 *dwc)
>> +{
>> +u32 ram2_depth;
>> +u32 mdwidth;
>> +u32 nump;
>> +u32 reg;
>> +
>> +ram2_depth = DWC3_GHWPARAMS7_RAM2_DEPTH(dwc->hwpara
t; + return index == (DWC3_TRB_NUM - 1);
> +}
> +
> static void dwc3_ep_inc_enq(struct dwc3_ep *dep)
> {
> dep->trb_enqueue++;
> - dep->trb_enqueue %= DWC3_TRB_NUM;
I would really like to keep the comment about skipping link TRB here.
--
balbi
signature.asc
Description: PGP signature
queue < dep->trb_enqueue)
> + trbs_left--;
this branch seems correct, but part of a separate patch.
> +
> + return trbs_left;
> }
>
> static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
> @@ -949,6 +969,9 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, int
> starting)
>
> trbs_left = dwc3_calc_trbs_left(dep);
>
> + if (!trbs_left)
> + return;
also a separate patch.
--
balbi
signature.asc
Description: PGP signature
pletion);
but the command never completes. I wonder if your command doorbell
completed before wait_for_completion() was called, or if it didn't
complete at all.
Can you enable XHCI debugging logs and try again? (Mathias, what was the
easy trick to enable all XHCI debugging logs?)
--
balbi
signature.asc
Description: PGP signature
gure out why that command failed?
--
balbi
signature.asc
Description: PGP signature
Hi,
Joao Pinto writes:
> Hi Felipe,
>
> On 5/19/2016 11:32 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Joao Pinto writes:
>>> Hi Felipe and Mathias,
>>>
>>> Sending kernel log with extra xhci messages in attachment!
>>> Thanks
Hi,
John Youn writes:
> On 5/19/2016 12:51 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> John Youn writes:
>>> This patch fixes up some issues related to the trb_left calculation.
>>>
>>> This calculation sometimes included the link trb slot
p RAID and use
that RAID as backing store for g_mass_storage, then connect
g_mass_storage back to same host which has the RAID of several USB
sticks (same machine has host and peripheral controllers).
--
balbi
signature.asc
Description: PGP signature
It's unlikely that we will ever know the avg so
instead of assuming it'll be something really large,
we will calculate the avg as we go as mentioned in
XHCI specification section 4.14.1.1.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-m
1 - 100 of 8015 matches
Mail list logo
