Re: [PATCH v2 00/27] Revised full patchset for PCM in-kernel copy support
On Jul 02 2017 05:58, Takashi Iwai wrote:
Hi,
this is a full patchset of what I sent previously, containing the all
changes instead of the snippet. The main purpose of this patchset is
to eliminate the remaining usages of set_fs(). They are basically
used for in-kernel PCM data transfer, and this patch provides the new
API functions and replaces the hackish set_fs() calls with them.
Unlike the first patchset with the unified copy_silence ops, this adds
a new copy_kernel ops instead. At the same time, copy/silence are
changed to receive the position and size in bytes instead of frames.
This allows us to simplify the PCM core code. As a result, a good
amount of code could be removed from pcm_lib.c.
The difference from the previous patchset is that this is a full
patchset, i.e. all relevant drivers have been covered, and also some
small issues have been addressed, in addition, the documentation
update is provided, too.
I'm Cc'ing the media and the USB people since it touches solo6x10 and
usb-gadget drivers.
The previous ACK was dropped as each patch was rewritten again. Sorry
for the doubly patch-review labours.
thanks,
Takashi
===
Takashi Iwai (26):
ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops
Below commits look good to me.
ALSA: dummy: Convert to new PCM copy ops
ALSA: es1938: Convert to the new PCM copy ops
ALSA: nm256: Convert to new PCM copy ops
ALSA: korg1212: Convert to the new PCM ops
ALSA: rme32: Convert to the new PCM copy ops
ALSA: rme96: Convert to the new PCM ops
ALSA: rme9652: Convert to the new PCM ops
ALSA: hdsp: Convert to the new PCM ops
ALSA: gus: Convert to the new PCM ops
ALSA: sb: Convert to the new PCM ops
ALSA: sh: Convert to the new PCM ops
ASoC: blackfin: Convert to the new PCM ops
[media] solo6x10: Convert to the new PCM ops
ALSA: pcm: Drop the old copy and silence ops
ALSA: pcm: Check PCM state by a common helper function
ALSA: pcm: Shuffle codes
ALSA: pcm: Call directly the common read/write helpers
ALSA: pcm: More unification of PCM transfer codes
ALSA: pcm: Unify read/write loop
ALSA: pcm: Simplify snd_pcm_playback_silence()
ALSA: pcm: Direct in-kernel read/write support
usb: gadget: u_uac1: Kill set_fs() usage
ALSA: pcm: Kill set_fs() in PCM OSS layer
ALSA: pcm: Build OSS writev/readv helpers conditionally
ALSA: doc: Update copy_user, copy_kernel and fill_silence PCM ops
Reviewed-by: Takashi Sakamoto
I did easy test with snd-hda-intel/snd-fireworks in below conditions.
Things work well:
1. ALSA application (aplay/arecord) for '__user *' <-> '__kernel *' copying.
2. loaded snd-oss-pcm and an Open Sound System application
(ossplay/ossrecord), for '__kernel *' <-> '__kernel *' copying.
I have no devices for which drivers have the .copy_user, .copy_kernel
and .fill_silence, and all of my attemps to work with OTG chip for v4.12
fails (sigh...). My test is not comprehensive at all, however the
patchset is programmed with handler-oriented ways and in this point I
think snd-pcm works as expected.
I note that patch 19 brings merge conflict to current HEAD
ee6f4cde4f74("Merge branch 'for-linus'"), due to my patch,
2c4842d3b6b3("ALSA: pcm: add local header file for snd-pcm module"). I
should have postponed it.. For the above test, I handy modifies the
history with little affections for my reviewing.
.../sound/kernel-api/writing-an-alsa-driver.rst| 111 ++--
drivers/media/pci/solo6x10/solo6x10-g723.c | 32 +-
drivers/usb/gadget/function/u_uac1.c | 7 +-
include/sound/pcm.h| 80 ++-
sound/core/oss/io.c| 4 +-
sound/core/oss/pcm_oss.c | 81 +--
sound/core/oss/pcm_plugin.h| 6 +-
sound/core/pcm_lib.c | 564 -
sound/drivers/dummy.c | 20 +-
sound/isa/gus/gus_pcm.c| 97 ++--
sound/isa/sb/emu8000_pcm.c | 190 ---
sound/pci/es1938.c | 33 +-
sound/pci/korg1212/korg1212.c | 112 ++--
sound/pci/nm256/nm256.c| 57 ++-
sound/pci/rme32.c | 65 ++-
sound/pci/rme96.c | 70 ++-
sound/pci/rme9652/hdsp.c | 67 ++-
sound/pci/rme9652/rme9652.c| 71 ++-
sound/sh/sh_dac_audio.c| 54 +-
sound/soc/blackfin/bf5xx-ac97-pcm.c| 27 +-
sound/soc/blackfin/bf5xx-i2s-pcm.c | 36 +-
sound/soc/soc-pcm.c| 5 +-
22 files changed, 977 insertions(+), 812 deletions(-)
Regards
Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a messag
Re: Feature proposal: Report connection speed through usbdevfs API
Am 01.06.2017 um 16:39 schrieb Alan Stern:
On Thu, 1 Jun 2017, Reinhard Huck wrote:
Hi,
Currently, in an usbdevfs-based application it is not possible to know
the speed the device is operating at. But this information is sometime
required, for example to interpret the bInterval and wMaxPacketSize
fields of interrupt/isochronous endpoint descriptors. Specifically, it
is a problem to differentiate between full and high speed because this
is not indicated in descriptors.
We suggest to add a new IOCTL (e.g. USBDEVFS_GET_SPEED) which reports
the speed as an int value as one of the following constants:
#define USBDEVFS_SPEED_UNKNOWN 0
#define USBDEVFS_SPEED_LOW 1
#define USBDEVFS_SPEED_FULL 2
#define USBDEVFS_SPEED_HIGH 3
#define USBDEVFS_SPEED_WIRELESS 4
#define USBDEVFS_SPEED_SUPER5
#define USBDEVFS_SPEED_SUPER_PLUS 6
Alternatively you could introduce IOCTL USBDEVFS_CONNECTINFO_2 and
struct usbdevfs_connectinfo_2.
That's a good idea. The connection speed is available in sysfs but not
in usbfs (at least, not since the days of USB-1.1).
How does this patch look?
Alan Stern
Index: usb-4.x/drivers/usb/core/devio.c
===
--- usb-4.x.orig/drivers/usb/core/devio.c
+++ usb-4.x/drivers/usb/core/devio.c
@@ -1322,6 +1322,27 @@ static int proc_connectinfo(struct usb_d
return 0;
}
+static int proc_get_speed(struct usb_dev_state *ps)
+{
+ switch (ps->dev->speed) {
+ case USB_SPEED_UNKNOWN:
+ return USBDEVFS_SPEED_UNKNOWN;
+ case USB_SPEED_LOW:
+ return USBDEVFS_SPEED_LOW;
+ case USB_SPEED_FULL:
+ return USBDEVFS_SPEED_FULL;
+ case USB_SPEED_HIGH:
+ return USBDEVFS_SPEED_HIGH;
+ case USB_SPEED_WIRELESS:
+ return USBDEVFS_SPEED_WIRELESS;
+ case USB_SPEED_SUPER:
+ return USBDEVFS_SPEED_SUPER;
+ case USB_SPEED_SUPER_PLUS:
+ return USBDEVFS_SPEED_SUPER_PLUS;
+ }
+ return -ERANGE;
+}
+
static int proc_resetdevice(struct usb_dev_state *ps)
{
struct usb_host_config *actconfig = ps->dev->actconfig;
@@ -2537,6 +2558,9 @@ static long usbdev_do_ioctl(struct file
case USBDEVFS_DROP_PRIVILEGES:
ret = proc_drop_privileges(ps, p);
break;
+ case USBDEVFS_GET_SPEED:
+ ret = proc_get_speed(ps);
+ break;
}
done:
Index: usb-4.x/include/uapi/linux/usbdevice_fs.h
===
--- usb-4.x.orig/include/uapi/linux/usbdevice_fs.h
+++ usb-4.x/include/uapi/linux/usbdevice_fs.h
@@ -156,6 +156,16 @@ struct usbdevfs_streams {
unsigned char eps[0];
};
+/* connection speed values used by USBDEVFS_GET_SPEED */
+#define USBDEVFS_SPEED_UNKNOWN 0
+#define USBDEVFS_SPEED_LOW 1
+#define USBDEVFS_SPEED_FULL2
+#define USBDEVFS_SPEED_HIGH3
+#define USBDEVFS_SPEED_WIRELESS4
+#define USBDEVFS_SPEED_SUPER 5
+#define USBDEVFS_SPEED_SUPER_PLUS 6
+
+
#define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer)
#define USBDEVFS_CONTROL32 _IOWR('U', 0, struct
usbdevfs_ctrltransfer32)
#define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer)
@@ -190,5 +200,6 @@ struct usbdevfs_streams {
#define USBDEVFS_ALLOC_STREAMS _IOR('U', 28, struct usbdevfs_streams)
#define USBDEVFS_FREE_STREAMS _IOR('U', 29, struct usbdevfs_streams)
#define USBDEVFS_DROP_PRIVILEGES _IOW('U', 30, __u32)
+#define USBDEVFS_GET_SPEED _IO('U', 31)
#endif /* _UAPI_LINUX_USBDEVICE_FS_H */
Thanks for the patch. That's exactly what we want. Could you please make
sure that the patch gets released?
Best Regards,
Reinhard
--
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 9/9] [HSLPM] usb: dwc2: Enable LPM
Greg Kroah-Hartman writes: > On Fri, Apr 28, 2017 at 12:56:42PM +0400, Sevak Arakelyan wrote: >> From: John Youn >> >> Set 'lpm_capable' flag in the gadget structure so >> indicating that LPM is supported. >> >> Signed-off-by: Sevak Arakelyan > > No signed-off-by from John? right, I only took two patches from this series. Without John's acked-by, I can't take any dwc2 patches. -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt
Hi,
Thinh Nguyen writes:
> this could be, I don't remember if I checked this or not :-)
>
> Really, the best way here, IMHO, would be to re-verify what's going on
> with macOS and revert my orignal patch since it's, rather clearly,
> wrong.
>
Sure. Are you going to make a revert patch or I am?
>>>
>>> Well, after we really know what's going on with macOS and have a better
>>> fix, then who makes the revert is less important as long as problems get
>>> sorted out :-) Either way is fine for me.
>>>
>>
>> Do you have any update on this issue?
>>
>
> The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when
> invalid") still causes a regression for us. As there hasn't any update
> for the macOS issue, can I submit a revert patch for this?
I just came back from vacations ;-) I'll get back to this. Reverting
that commit won't do any good as we'd be exchanging one regression for
another. We really need to understand what's going on.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric
Hi,
Stefan Agner writes:
> Hi Felipe,
>
> On 2017-04-19 01:53, Krzysztof Opasiak wrote:
>> On 04/15/2017 03:35 AM, Stefan Agner wrote:
>>> Currently qw_sign requires UTF-8 character to set, but returns UTF-16
>>> when read. This isn't obvious when simply using cat since the null
>>> characters are not visible, but hexdump unveils the true string:
>>>
>>> # echo MSFT100 > os_desc/qw_sign
>>> # hexdump -C os_desc/qw_sign
>>> 4d 00 53 00 46 00 54 00 31 00 30 00 30 00
>>> |M.S.F.T.1.0.0.|
>>>
>>> Make qw_sign symmetric by returning an UTF-8 string too. Also follow
>>> common convention and add a new line at the end.
>>>
>>> Signed-off-by: Stefan Agner
>>> ---
>>> Resend as discussed here:
>>> https://patchwork.kernel.org/patch/9548869/
>>>
>>> Sorry, a bit later than we discussed... Hope still not too late?
>>>
>>> --
>>> Stefan
>>>
>>> drivers/usb/gadget/configfs.c | 8 ++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>>> index cbff3b02840d..863ca4ded1be 100644
>>> --- a/drivers/usb/gadget/configfs.c
>>> +++ b/drivers/usb/gadget/configfs.c
>>> @@ -787,9 +787,13 @@ static ssize_t os_desc_b_vendor_code_store(struct
>>> config_item *item,
>>> static ssize_t os_desc_qw_sign_show(struct config_item *item, char *page)
>>> {
>>> struct gadget_info *gi = os_desc_item_to_gadget_info(item);
>>> + int res;
>>>
>>> - memcpy(page, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
>>> - return OS_STRING_QW_SIGN_LEN;
>>> + res = utf16s_to_utf8s((wchar_t *) gi->qw_sign, OS_STRING_QW_SIGN_LEN,
>>> + UTF16_LITTLE_ENDIAN, page, PAGE_SIZE - 1);
>>> + page[res++] = '\n';
>>> +
>>> + return res;
>>> }
>>>
>>> static ssize_t os_desc_qw_sign_store(struct config_item *item, const char
>>> *page,
>>>
>>
>> Code itself looks good to me and from libusbgx perspective it's also
>> fine to add this new line as we can just drop it like we do with other
>> newlines in case of gadget/config strings.
>>
>> Reviewed-by: Krzysztof Opasiak
>>
>
> Any chance we get this in this merge window?
>
> This still applies fine on v4.12-rc2.
I wouldn't consider this a fix. I'll get this into v4.13 merge window.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] ALSA: hda - Fix applying MSI dual-codec mobo quirk
Hello!
On 6/1/2017 11:58 PM, Takashi Iwai wrote:
The previous commit [63691587f7b0: ALSA: hda - Apply dual-codec quirk
for MSI Z270-Gaming mobo] attempted to apply the existing dual-codec
The standard way of citing a commit is: commit 63691587f7b0 ("ALSA: hda -
Apply dual-codec quirk for MSI Z270-Gaming mobo"), just like in the Fixes: tag.
quirk for a MSI mobo. But it turned out that this isn't applied
properly due to the MSI-vendor quirk before this entry. I overlooked
such two MSI entries just because they were put in the wrong position,
although we have a list ordered by PCI SSID numbers.
This patch fixes it by rearranging the unordered entries.
Fixes: 63691587f7b0 ("ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming
mobo")
Reported-by: Rudolf Schmidt
Signed-off-by: Takashi Iwai
[...]
MBR, Sergei
--
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 2/3] usb: gadget: f_uac2: split out audio core
Hi, Ruslan Bilovol writes: > Abstract the peripheral side ALSA sound card code from > the f_uac2 function into a component that can be called > by various functions, so the various flavors can be split > apart and selectively reused. > > Visible changes: > - add uac_params structure to pass audio paramteres for >g_audio_setup > - make ALSA sound card's name configurable > - add [in/out]_ep_maxpsize > - allocate snd_uac_chip structure during g_audio_setup > - add u_audio_[start/stop]_[capture/playback] functions > > Signed-off-by: Ruslan Bilovol this doesn't apply on testing/next, care to rebase? -- balbi signature.asc Description: PGP signature
Re: [PATCH v4 0/3] USB Audio Gadget refactoring
Hi, Ruslan Bilovol writes: > I came to this patch series when wanted to do two things: > - use UAC1 as virtual ALSA sound card on gadget side, >just like UAC2 is used so it's possible to do rate >resampling > - have both playback/capture support in UAC1 > > Since I wanted to have same behavior for both UAC1/UAC2, > obviously I've got an utility part (u_audio.c) for > virtual ALSA sound card handling like we have > for ethernet(u_ether) or serial(u_serial) functions. > Function-specific parts (f_uac1/f_uac2) became almost > as storage for class-specific USB descriptors, some > boilerplate for configfs, binding and few USB > config request handling. > > Originally in RFC [1] I've posted before, there was > major change to f_uac1 after that it couldn't do > direct play to existing ALSA sound card anymore, > representing audio on gadget side as virtual > ALSA sound card where audio streams are simply > sinked to and sourced from it, so it may break > current usecase for some people (and that's why > it was RFC). > > During RFC discussion, it was agreed to not touch > existing f_uac1 implementation and create new one > instead. This patchset (v4) introduced new function > named f_uac1_acard and doesn't touch current f_uac1 > implementation, so people still can use old behavior Do you have a pointer to the original RFC discussion where this was discussed? If we really *must* keep the old implementation, I would rather rename that to f_uac1_legacy. Still, I find it unlikely that anybody will care about the old implementation. > Now, it's possible to use existing user-space > applications for audio routing between Audio Gadget > and real sound card. I personally use alsaloop tool > from alsautils and have ability to create PCM > loopback between two different ALSA cards using > rate resampling, which was not possible with previous > "direct play to ALSA card" approach in f_uac1. this is really good result and will actually make it a lot easier for testing things out. > While here, also dropped redundant platform > driver/device creation in f_uac2 driver (as well as > didn't add "never implemented" volume/mute functionality > in f_uac1 to f_uac1_acard) that made this work even > easier to do. > > This series is tested with both legacy g_audio.ko and > modern configfs approaches under Ubuntu 14.04 (UAC1 and > UAC2) and under Windows7 x64 (UAC1 only) having > perfect results in all cases. > > Comments, testing are welcome. > > v4 changes: > - renamed f_uac1_newapi to f_uac1_acard that is >more meaningful I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why do we need to maintain the old uac1 implementation? Why two separate files? -- balbi signature.asc Description: PGP signature
RE: [PATCH 0/5] usb: gadget: udc: renesas_usb3: add DMAC support
Hi, Yoshihiro Shimoda writes: > Hi Felipe, > >> -Original Message- >> From: Yoshihiro Shimoda >> Sent: Wednesday, April 26, 2017 8:50 PM >> >> This patch set is based on the latest Feribe's usb.git / testing/next branch >> (the commit id = 28ea6be01e2cf244c461a40c8e9593816f894412.) > > I'm afraid but, would you review this patch set? > This patch set can be applied on the today's testing/next branch. I was thinking that we need the fixes during the -rc cycle. No? In that case, we need to get rid of the dependencies between 1-4 and patch 5. patches 1-4 are in my testing/fixes now. -- balbi signature.asc Description: PGP signature
[GIT PULL] Fixes for v4.12-rc4
Hi Greg, here's another set of fixes for current -rc cycle. Let me know if you want anything to be changed. Patches have been on the mailing list for quite some time. At least the mass storage patch (the only one I could test) has been tested on some intel boards I have around for a few days. cheers The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b: Linux 4.12-rc3 (2017-05-28 17:20:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git fixes-for-v4.12-rc4 for you to fetch changes up to afbbc7913a288c29616bd31ae612548f6475151a: usb: gadget: udc: renesas_usb3: Fix PN_INT_ENA disabling timing (2017-06-02 12:45:02 +0300) usb: fixes for v4.12-rc4 A fix to a really old synchronization bug on mass storage gadget. Support for Meson8 SoCs on dwc2 Synchronization fixes on renesas USB driver. Martin Blumenstingl (1): usb: dwc2: add support for the DWC2 controller on Meson8 SoCs Thinh Nguyen (1): usb: gadget: f_mass_storage: Serialize wake and sleep execution Yoshihiro Shimoda (4): usb: gadget: udc: renesas_usb3: fix pm_runtime functions calling usb: gadget: udc: renesas_usb3: fix deadlock by spinlock usb: gadget: udc: renesas_usb3: lock for PN_ registers access usb: gadget: udc: renesas_usb3: Fix PN_INT_ENA disabling timing Documentation/devicetree/bindings/usb/dwc2.txt | 1 + drivers/usb/dwc2/params.c | 2 ++ drivers/usb/gadget/function/f_mass_storage.c | 13 ++-- drivers/usb/gadget/udc/renesas_usb3.c | 45 ++ 4 files changed, 46 insertions(+), 15 deletions(-) -- balbi signature.asc Description: PGP signature
RE: [PATCH v4 3/3] USB3/DWC3: Enable undefined length INCR burst type
Hi, Jerry Huang writes: >> Jerry Huang writes: >> >> >> -- >> >> >> 1.7.9.5 >> >> > Hi, Balbi and all guys, >> >> > Any comment for these patches? Can they be accepted? >> >> >> >> Rob had comments which you didn't reply yet. I cannot take this >> >> patchset yet ;-) >> >> >> > Balbi, >> > >> > I look into his mail again, which was based v3, and I replied it. >> > >> > He had different understanding for undefined length burst mode. >> > >> > It seems he think for this mode, just setting bit[0] (INCRBrstEna) and >> > don't need to set other field. >> > >> > However, according to the DWC USB3.0 controller databook, when it is >> > undefined length INCR burst mode, we still need to set one max burst >> > type, such as INCR8, which means controller will use any length less >> > than or equal to this INCR8. >> >> Rob, do you agree with the patch now? >> >> -- >> balbi > > Hi, Balbi, > Any comment for these patches? Or any chance to merge them? I'm not sure you understand how development is carried out here. I *can't* apply patches touching Device Tree properties without an Acked-by from any of the Device Tree maintainers. Until then, there's nothing I can say/do. -- balbi signature.asc Description: PGP signature
[PATCH] xhci: remove endpoint ring cache
Having a properly working ring cache could ease a bit the memory
reallocation, but this current implemetation isn't the correct way.
It's faulty and hogs a lot of memory.
A pool of cached rings that any device could use would be more useful,
but xhci driver isn't there yet, just keeping the basic functionality
working is already a handful.
How about your case, does removing the cache work instead with your setup?
8<---
Anurag Kumar Vulisha reported several issues with xhci endpoint
ring caching.
31 Rings are cached per device before a ring is freed.
These cached rings are not used as default if a new ring is needed.
They are only used if the drive fails to allocate memory for a ring.
The current ring cache is more a reason to why we run out memry than a
help when we actually do so.
Anurag Kumar Vulisha tried to use cached rings as a first option and
found new issues with cached ring initialization.
Cached rings were first zeroed and then manually reinitialized with link
rbs etc, but forgetting to set some important bits like cycle toggle bit.
Remove the ring cache completely as it's a faulty premature optimization
eating memory
Reported-by: Anurag Kumar Vulisha
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-mem.c | 81 -
drivers/usb/host/xhci.c | 17 +-
drivers/usb/host/xhci.h | 6 +---
3 files changed, 15 insertions(+), 89 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1f1687e..7c2501a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -407,64 +407,17 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd
*xhci,
return NULL;
}
-void xhci_free_or_cache_endpoint_ring(struct xhci_hcd *xhci,
+void xhci_free_endpoint_ring(struct xhci_hcd *xhci,
struct xhci_virt_device *virt_dev,
unsigned int ep_index)
{
- int rings_cached;
-
- rings_cached = virt_dev->num_rings_cached;
- if (rings_cached < XHCI_MAX_RINGS_CACHED) {
- virt_dev->ring_cache[rings_cached] =
- virt_dev->eps[ep_index].ring;
- virt_dev->num_rings_cached++;
- xhci_dbg(xhci, "Cached old ring, "
- "%d ring%s cached\n",
- virt_dev->num_rings_cached,
- (virt_dev->num_rings_cached > 1) ? "s" : "");
- } else {
- xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
- xhci_dbg(xhci, "Ring cache full (%d rings), "
- "freeing ring\n",
- virt_dev->num_rings_cached);
- }
+ xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
virt_dev->eps[ep_index].ring = NULL;
}
-/* Zero an endpoint ring (except for link TRBs) and move the enqueue and
dequeue
- * pointers to the beginning of the ring.
- */
-static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
- struct xhci_ring *ring, unsigned int cycle_state,
- enum xhci_ring_type type)
-{
- struct xhci_segment *seg = ring->first_seg;
- int i;
-
- do {
- memset(seg->trbs, 0,
- sizeof(union xhci_trb)*TRBS_PER_SEGMENT);
- if (cycle_state == 0) {
- for (i = 0; i < TRBS_PER_SEGMENT; i++)
- seg->trbs[i].link.control |=
- cpu_to_le32(TRB_CYCLE);
- }
- /* All endpoint rings have link TRBs */
- xhci_link_segments(xhci, seg, seg->next, type);
- seg = seg->next;
- } while (seg != ring->first_seg);
- ring->type = type;
- xhci_initialize_ring_info(ring, cycle_state);
- /* td list should be empty since all URBs have been cancelled,
-* but just in case...
-*/
- INIT_LIST_HEAD(&ring->td_list);
-}
-
/*
* Expand an existing ring.
- * Look for a cached ring or allocate a new ring which has same segment numbers
- * and link the two rings.
+ * Allocate a new ring which has same segment numbers and link the two rings.
*/
int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring,
unsigned int num_trbs, gfp_t flags)
@@ -968,12 +921,6 @@ void xhci_free_virt_device(struct xhci_hcd *xhci, int
slot_id)
/* If necessary, update the number of active TTs on this root port */
xhci_update_tt_active_eps(xhci, dev, old_active_eps);
- if (dev->ring_cache) {
- for (i = 0; i < dev->num_rings_cached; i++)
- xhci_ring_free(xhci, dev->ring_cache[i]);
- kfree(dev->ring_cache);
- }
-
if (dev->in_ctx)
xhci_free_container_ctx(xhci, dev->in_ctx);
if (dev->out_ctx)
@@ -1062,14 +1009,6 @@ int xhci_alloc_virt_device(
Re: [PATCH v4 2/3] usb: gadget: f_uac2: split out audio core
On Tue, May 30, 2017 at 5:13 AM, Ruslan Bilovol
wrote:
> On Mon, May 22, 2017 at 6:58 PM, Jassi Brar wrote:
>> On Thu, May 18, 2017 at 4:07 AM, Ruslan Bilovol
>> wrote:
>>> Abstract the peripheral side ALSA sound card code from
>>> the f_uac2 function into a component that can be called
>>> by various functions, so the various flavors can be split
>>> apart and selectively reused.
>>>
>>> Visible changes:
>>> - add uac_params structure to pass audio paramteres for
>>>g_audio_setup
>>> - make ALSA sound card's name configurable
>>> - add [in/out]_ep_maxpsize
>>> - allocate snd_uac_chip structure during g_audio_setup
>>> - add u_audio_[start/stop]_[capture/playback] functions
>>>
>>> Signed-off-by: Ruslan Bilovol
>>> ---
>>> drivers/usb/gadget/Kconfig| 4 +
>>> drivers/usb/gadget/function/Makefile | 1 +
>>> drivers/usb/gadget/function/f_uac2.c | 721
>>> --
>>> drivers/usb/gadget/function/u_audio.c | 661 +++
>>> drivers/usb/gadget/function/u_audio.h | 95 +
>>> drivers/usb/gadget/legacy/Kconfig | 1 +
>>> 6 files changed, 846 insertions(+), 637 deletions(-)
>>> create mode 100644 drivers/usb/gadget/function/u_audio.c
>>> create mode 100644 drivers/usb/gadget/function/u_audio.h
>>>
>>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>>> index c164d6b..2ba0ace 100644
>>> --- a/drivers/usb/gadget/Kconfig
>>> +++ b/drivers/usb/gadget/Kconfig
>>> @@ -158,6 +158,9 @@ config USB_U_SERIAL
>>> config USB_U_ETHER
>>> tristate
>>>
>>> +config USB_U_AUDIO
>>> + tristate
>>> +
>>> config USB_F_SERIAL
>>> tristate
>>>
>>> @@ -381,6 +384,7 @@ config USB_CONFIGFS_F_UAC2
>>> depends on SND
>>> select USB_LIBCOMPOSITE
>>> select SND_PCM
>>> + select USB_U_AUDIO
>>> select USB_F_UAC2
>>> help
>>> This Audio function is compatible with USB Audio Class
>>> diff --git a/drivers/usb/gadget/function/Makefile
>>> b/drivers/usb/gadget/function/Makefile
>>> index cb8c225..b29f2ae 100644
>>> --- a/drivers/usb/gadget/function/Makefile
>>> +++ b/drivers/usb/gadget/function/Makefile
>>> @@ -32,6 +32,7 @@ usb_f_mass_storage-y := f_mass_storage.o
>>> storage_common.o
>>> obj-$(CONFIG_USB_F_MASS_STORAGE)+= usb_f_mass_storage.o
>>> usb_f_fs-y := f_fs.o
>>> obj-$(CONFIG_USB_F_FS) += usb_f_fs.o
>>> +obj-$(CONFIG_USB_U_AUDIO) += u_audio.o
>>> usb_f_uac1-y := f_uac1.o u_uac1.o
>>> obj-$(CONFIG_USB_F_UAC1) += usb_f_uac1.o
>>> usb_f_uac2-y := f_uac2.o
>>> diff --git a/drivers/usb/gadget/function/f_uac2.c
>>> b/drivers/usb/gadget/function/f_uac2.c
>>> index d4565b5..059a14a 100644
>>> --- a/drivers/usb/gadget/function/f_uac2.c
>>> +++ b/drivers/usb/gadget/function/f_uac2.c
>>> @@ -15,10 +15,7 @@
>>> #include
>>> #include
>>>
>>> -#include
>>> -#include
>>> -#include
>>> -
>>> +#include "u_audio.h"
>>> #include "u_uac2.h"
>>>
>>> /*
>>> @@ -50,455 +47,23 @@
>>> #define UNFLW_CTRL 8
>>> #define OVFLW_CTRL 10
>>>
>>> -struct uac2_req {
>>> - struct uac2_rtd_params *pp; /* parent param */
>>> - struct usb_request *req;
>>> -};
>>> -
>>> -struct uac2_rtd_params {
>>> - struct snd_uac2_chip *uac2; /* parent chip */
>>> - bool ep_enabled; /* if the ep is enabled */
>>> - /* Size of the ring buffer */
>>> - size_t dma_bytes;
>>> - unsigned char *dma_area;
>>> -
>>> - struct snd_pcm_substream *ss;
>>> -
>>> - /* Ring buffer */
>>> - ssize_t hw_ptr;
>>> -
>>> - void *rbuf;
>>> -
>>> - size_t period_size;
>>> -
>>> - unsigned max_psize;
>>> - struct uac2_req *ureq;
>>> -
>>> - spinlock_t lock;
>>> -};
>>> -
>>> -struct snd_uac2_chip {
>>> - struct uac2_rtd_params p_prm;
>>> - struct uac2_rtd_params c_prm;
>>> -
>>> - struct snd_card *card;
>>> - struct snd_pcm *pcm;
>>> -
>>> - /* timekeeping for the playback endpoint */
>>> - unsigned int p_interval;
>>> - unsigned int p_residue;
>>> -
>>> - /* pre-calculated values for playback iso completion */
>>> - unsigned int p_pktsize;
>>> - unsigned int p_pktsize_residue;
>>> - unsigned int p_framesize;
>>> +struct f_uac2 {
>>> + struct g_audio g_audio;
>>> + u8 ac_intf, as_in_intf, as_out_intf;
>>> + u8 ac_alt, as_in_alt, as_out_alt; /* needed for get_alt() */
>>> };
>>>
>>> -#define BUFF_SIZE_MAX (PAGE_SIZE * 16)
>>> -#define PRD_SIZE_MAX PAGE_SIZE
>>> -#define MIN_PERIODS4
>>> -
>>> -static struct snd_pcm_hardware uac2_pcm_hardware = {
>>> - .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER
>>> -| SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID
>>> -| SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
>>> - .rates = SNDRV_PCM_RATE_CONTINUOUS,
>>> - .perio
Re: [RFC PATCH] usb: optimize acpi companion search for usb port devices
On 01.06.2017 02:01, Rafael J. Wysocki wrote: On 5/25/2017 5:24 PM, Mathias Nyman wrote: On 24.05.2017 17:44, Greg KH wrote: On Wed, May 24, 2017 at 04:11:12PM +0300, Mathias Nyman wrote: This optimization significantly reduces xhci driver load time. In ACPI tables the acpi companion port devices are children of the hub device. The port devices are identified by their port number returned by the ACPI _ADR method. _ADR 0 is reserved for the root hub device. The current implementation to find a acpi companion port device loops through all acpi port devices under that parent hub, calling their _ADR method each time a new port device is added. for a xHC controller with 25 ports under its roothub it will end up invoking ACPI bytecode 625 times before all ports are ready, making it really slow. The _ADR values are already read and cached earler. So instead of running the bytecode again we can check the cached _ADR value first, and then fall back to the old way. As one of the more significant changes, the xhci load time on Intel kabylake reduced by 70%, (28ms) from initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs to initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs Signed-off-by: Mathias Nyman --- drivers/usb/core/usb-acpi.c | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) Why is this RFC? What's wrong with it as-is? Last minute doubt, nothing should be wrong, but I started to wonder if there is any particular reason the ACPI part was done the way it was. Or if maybe other drivers could benefit from checking cached _ADR value first as well, and this whole thing should be a part of drivers/acpi/glue.c instead? That or we should just evaluate _ADR if present during the very initialization and store the value in a filed under struct acpi_device. Yes, that is pretty much done, acpi_init_device_object() will end up evaluating _ADR and store it in acpi_device.pnp.bus_address Just considering if there should be something like acpi_get_adr(acpi_device *adev) that would first check if adev->pnp.bus_address exists, if not, then it would evaluate _ADR. But really just a thought, I think I'll send this forward as is. Thanks Mathias -- 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 0/5] xhci and usb-acpi features for usb-next
Hi Greg This series contain the RFC-PATCH for usb-acpi, improving xhci and ehci driver load times. It didn't stir up any discussion or objections. Series also includes a change to make URB cancel more reliable in xhci. More features for usb-next are still cooking, not sure if they will make 4.13, so I'd like to get these ones out of the way Thanks Mathias Mathias Nyman (5): xhci: Add helper to get hardware dequeue pointer for stopped rings. xhci: Add stream id to xhci_dequeue_state structure xhci: Find out where an endpoint or stream stopped from its context. xhci: remove unused stopped_td pointer usb: optimize acpi companion search for usb port devices drivers/usb/core/usb-acpi.c | 26 +++-- drivers/usb/host/xhci-ring.c | 67 +++- drivers/usb/host/xhci.c | 2 +- drivers/usb/host/xhci.h | 3 +- 4 files changed, 67 insertions(+), 31 deletions(-) -- 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
[PATCH 1/5] xhci: Add helper to get hardware dequeue pointer for stopped rings.
Add xhci_get_hw_deq() helper to retrieve the hardware dequeue pointer an
endpoint or stream stopped on.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 03f63f5..1ca3dc3 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -480,6 +480,30 @@ struct xhci_ring *xhci_triad_to_transfer_ring(struct
xhci_hcd *xhci,
return NULL;
}
+
+/*
+ * Get the hw dequeue pointer xHC stopped on, either directly from the
+ * endpoint context, or if streams are in use from the stream context.
+ * The returned hw_dequeue contains the lowest four bits with cycle state
+ * and possbile stream context type.
+ */
+static u64 xhci_get_hw_deq(struct xhci_hcd *xhci, struct xhci_virt_device
*vdev,
+ unsigned int ep_index, unsigned int stream_id)
+{
+ struct xhci_ep_ctx *ep_ctx;
+ struct xhci_stream_ctx *st_ctx;
+ struct xhci_virt_ep *ep;
+
+ ep = &vdev->eps[ep_index];
+
+ if (ep->ep_state & EP_HAS_STREAMS) {
+ st_ctx = &ep->stream_info->stream_ctx_array[stream_id];
+ return le64_to_cpu(st_ctx->stream_ring);
+ }
+ ep_ctx = xhci_get_ep_ctx(xhci, vdev->out_ctx, ep_index);
+ return le64_to_cpu(ep_ctx->deq);
+}
+
/*
* Move the xHC's endpoint ring dequeue pointer past cur_td.
* Record the new state of the xHC's endpoint ring dequeue segment,
@@ -521,21 +545,11 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
stream_id);
return;
}
-
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Finding endpoint context");
- /* 4.6.9 the css flag is written to the stream context for streams */
- if (ep->ep_state & EP_HAS_STREAMS) {
- struct xhci_stream_ctx *ctx =
- &ep->stream_info->stream_ctx_array[stream_id];
- hw_dequeue = le64_to_cpu(ctx->stream_ring);
- } else {
- struct xhci_ep_ctx *ep_ctx
- = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
- hw_dequeue = le64_to_cpu(ep_ctx->deq);
- }
+ hw_dequeue = xhci_get_hw_deq(xhci, dev, ep_index, stream_id);
new_seg = ep_ring->deq_seg;
new_deq = ep_ring->dequeue;
state->new_cycle_state = hw_dequeue & 0x1;
--
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
[PATCH 3/5] xhci: Find out where an endpoint or stream stopped from its context.
When xHC is asked to stop an endpoint it will save the position it
stopped on in the endpoint or stream context.
xhci driver needs to know if the controller stopped on the exact same
TRB that the driver was asked to cancel as it then needs to move past
the TD instead of turning the TD to no-op TRBs.
xhci driver used to get the stopped position from a "stopped" transfer
event before the stop endpoint command completed, but if the ring
is already stopped, or in a halted or error state this event is missing.
Get the stopped position from the endpoint or stream context instead
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 32b31df..ee2453e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -706,7 +706,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
struct xhci_td *last_unlinked_td;
struct xhci_ep_ctx *ep_ctx;
struct xhci_virt_device *vdev;
-
+ u64 hw_deq;
struct xhci_dequeue_state deq_state;
if (unlikely(TRB_TO_SUSPEND_PORT(le32_to_cpu(trb->generic.field[3] {
@@ -768,12 +768,19 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd
*xhci, int slot_id,
* If we stopped on the TD we need to cancel, then we have to
* move the xHC endpoint ring dequeue pointer past this TD.
*/
- if (cur_td == ep->stopped_td)
+ hw_deq = xhci_get_hw_deq(xhci, vdev, ep_index,
+cur_td->urb->stream_id);
+ hw_deq &= ~0xf;
+
+ if (trb_in_td(xhci, cur_td->start_seg, cur_td->first_trb,
+ cur_td->last_trb, hw_deq, false)) {
xhci_find_new_dequeue_state(xhci, slot_id, ep_index,
- cur_td->urb->stream_id,
- cur_td, &deq_state);
- else
+ cur_td->urb->stream_id,
+ cur_td, &deq_state);
+ } else {
td_to_noop(xhci, ep_ring, cur_td, false);
+ }
+
remove_finished_td:
/*
* The event handler won't see a completion for this TD anymore,
--
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
[PATCH 5/5] usb: optimize acpi companion search for usb port devices
This optimization significantly reduces xhci driver load time.
In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.
The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, evaluating
their _ADR method each time a new port device is added.
for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.
The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.
As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs
Signed-off-by: Mathias Nyman
---
drivers/usb/core/usb-acpi.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 2776cfe..ef9cf4a 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -127,6 +127,22 @@ static enum usb_port_connect_type
usb_acpi_get_connect_type(acpi_handle handle,
*/
#define USB_ACPI_LOCATION_VALID (1 << 31)
+static struct acpi_device *usb_acpi_find_port(struct acpi_device *parent,
+ int raw)
+{
+ struct acpi_device *adev;
+
+ if (!parent)
+ return NULL;
+
+ list_for_each_entry(adev, &parent->children, node) {
+ if (acpi_device_adr(adev) == raw)
+ return adev;
+ }
+
+ return acpi_find_child_device(parent, raw, false);
+}
+
static struct acpi_device *usb_acpi_find_companion(struct device *dev)
{
struct usb_device *udev;
@@ -174,8 +190,10 @@ static struct acpi_device *usb_acpi_find_companion(struct
device *dev)
int raw;
raw = usb_hcd_find_raw_port_number(hcd, port1);
- adev =
acpi_find_child_device(ACPI_COMPANION(&udev->dev),
- raw, false);
+
+ adev = usb_acpi_find_port(ACPI_COMPANION(&udev->dev),
+ raw);
+
if (!adev)
return NULL;
} else {
@@ -186,7 +204,9 @@ static struct acpi_device *usb_acpi_find_companion(struct
device *dev)
return NULL;
acpi_bus_get_device(parent_handle, &adev);
- adev = acpi_find_child_device(adev, port1, false);
+
+ adev = usb_acpi_find_port(adev, port1);
+
if (!adev)
return NULL;
}
--
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
[PATCH 4/5] xhci: remove unused stopped_td pointer
We no longer keep track of where we stopped in a stopped_td pointer.
We get the ring dequeue pointer from the endpoint or stream context
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 4
drivers/usb/host/xhci.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ee2453e..3e27754 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -730,7 +730,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
if (list_empty(&ep->cancelled_td_list)) {
xhci_stop_watchdog_timer_in_irq(xhci, ep);
- ep->stopped_td = NULL;
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
return;
}
@@ -802,8 +801,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
- ep->stopped_td = NULL;
-
/*
* Drop the lock and complete the URBs in the cancelled TD list.
* New TDs to be cancelled might be added to the end of the list before
@@ -1957,7 +1954,6 @@ static int finish_td(struct xhci_hcd *xhci, struct
xhci_td *td,
* stopped TDs. A stopped TD may be restarted, so don't update
* the ring dequeue pointer or take this TD off any lists yet.
*/
- ep->stopped_td = td;
return 0;
}
if (trb_comp_code == COMP_STALL_ERROR ||
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 5c6b8458..886f150ba 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -924,7 +924,6 @@ struct xhci_virt_ep {
#define EP_GETTING_NO_STREAMS (1 << 5)
/* Related to URB cancellation */
struct list_headcancelled_td_list;
- struct xhci_td *stopped_td;
unsigned intstopped_stream;
/* Watchdog timer for stop endpoint command to cancel URBs */
struct timer_list stop_cmd_timer;
--
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
[PATCH 2/5] xhci: Add stream id to xhci_dequeue_state structure
The values for the new dequeue segment, new dequeue pointer and new cycle
state are needed for manually moving the xHC ring dequeue pointer.
These are conveniently stored in a xhci_dequeue_state structure.
stream support was added later and stream_id was carried
as a function parameter.
Move the stream_id to the xhci_dequeue_state structure instead.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 10 +-
drivers/usb/host/xhci.c | 2 +-
drivers/usb/host/xhci.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1ca3dc3..32b31df 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -507,7 +507,7 @@ static u64 xhci_get_hw_deq(struct xhci_hcd *xhci, struct
xhci_virt_device *vdev,
/*
* Move the xHC's endpoint ring dequeue pointer past cur_td.
* Record the new state of the xHC's endpoint ring dequeue segment,
- * dequeue pointer, and new consumer cycle state in state.
+ * dequeue pointer, stream id, and new consumer cycle state in state.
* Update our internal representation of the ring's dequeue pointer.
*
* We do this in three jumps:
@@ -553,6 +553,7 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
new_seg = ep_ring->deq_seg;
new_deq = ep_ring->dequeue;
state->new_cycle_state = hw_dequeue & 0x1;
+ state->stream_id = stream_id;
/*
* We want to find the pointer, segment and cycle state of the new trb
@@ -787,7 +788,7 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci,
int slot_id,
/* If necessary, queue a Set Transfer Ring Dequeue Pointer command */
if (deq_state.new_deq_ptr && deq_state.new_deq_seg) {
xhci_queue_new_dequeue_state(xhci, slot_id, ep_index,
- ep->stopped_td->urb->stream_id, &deq_state);
+&deq_state);
xhci_ring_cmd_db(xhci);
} else {
/* Otherwise ring the doorbell(s) to restart queued transfers */
@@ -3977,13 +3978,12 @@ int xhci_queue_stop_endpoint(struct xhci_hcd *xhci,
struct xhci_command *cmd,
/* Set Transfer Ring Dequeue Pointer command */
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
- unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
{
dma_addr_t addr;
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
- u32 trb_stream_id = STREAM_ID_FOR_TRB(stream_id);
+ u32 trb_stream_id = STREAM_ID_FOR_TRB(deq_state->stream_id);
u32 trb_sct = 0;
u32 type = TRB_TYPE(TRB_SET_DEQ);
struct xhci_virt_ep *ep;
@@ -4021,7 +4021,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
ep->queued_deq_seg = deq_state->new_deq_seg;
ep->queued_deq_ptr = deq_state->new_deq_ptr;
- if (stream_id)
+ if (deq_state->stream_id)
trb_sct = SCT_FOR_TRB(SCT_PRI_TR);
ret = queue_command(xhci, cmd,
lower_32_bits(addr) | trb_sct | deq_state->new_cycle_state,
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 30f47d9..2d6a98c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2849,7 +2849,7 @@ void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
"Queueing new dequeue state");
xhci_queue_new_dequeue_state(xhci, udev->slot_id,
- ep_index, ep->stopped_stream, &deq_state);
+ ep_index, &deq_state);
} else {
/* Better hope no one uses the input context between now and the
* reset endpoint completion!
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a9..5c6b8458 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1527,6 +1527,7 @@ struct xhci_dequeue_state {
struct xhci_segment *new_deq_seg;
union xhci_trb *new_deq_ptr;
int new_cycle_state;
+ unsigned int stream_id;
};
enum xhci_ring_type {
@@ -2053,7 +2054,6 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_dequeue_state *state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
- unsigned int stream_id,
struct xhci_dequeue_state *deq_state);
void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
unsigned int ep_index, struct xhci_td *td);
--
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
Re: Gadget driver & virtual hub
On Fri, 2 Jun 2017, Benjamin Herrenschmidt wrote: > On Fri, 2017-06-02 at 15:13 +1000, Benjamin Herrenschmidt wrote: > > On Sat, 2017-05-27 at 21:58 -0400, Alan Stern wrote: > > > The interfaces required for a UDC driver are explained to some extent > > > by the kerneldoc in include/linux/usb/gadget.h. For anything you still > > > don't understand, feel free to ask on this mailing list. > > > > It's missing docs for the udc callbacks :-) Yeah, the file could use a few additions. > > One quick question: ->set_halt, when called for clearing a stall (when > > does that happen btw ? I though only the host would do that), should See the kerneldoc for usb_ep_set_wedge() in udc/core.c. The USB Mass Storage Bulk-Only Transport spec says that under certain conditions, a bulk endpoint must be halted and must remain halted even if the host issues a Clear-Feature(Halt) request. The wedge operation was introduced to fulfill this requirement. The only way to un-wedge an endpoint is for the gadget driver to tell ->set_halt to clear it. > > it also reset the data toggle like a CLEAR_FEATURE would do Yes. > Also, a SET_FEATURE setting a stall, should that nuke pending > queued request ? No, the requests should remain on the queue until the gadget driver dequeues them or until the halt feature is cleared and they complete normally (or something else causes them to be dequeued, such as the endpoint being disabled or the gadget being disconnected from the host). > What about things like setting configuration, alt settings etc... all > these things are supposed to cleanup endpoint data toggles, should > probably nuke all pending requests etc UDC drivers don't seem to > do it and the "core" doesn't seem to have any kind of tracking of > these things... Those things are handled by the gadget driver (or for modern gadgets, by the composite core), not by the UDC driver. The gadget driver disables the endpoints for the old config/altsetting and then enables the endpoints for the new one. Disabling an endpoint should clean up all the state associated with it. > It looks like if the interface driver wants to do the right thing, > it needs ->set_halt() to also reset the toggle then ... That's right. Alan Stern -- 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 v2] usb: xhci: Issue stop EP command only when the EP state is running
On Fri, 2 Jun 2017, Shyam Sundar S K wrote: > on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is > issued the controller does not respond, when the EP is not in running > state. HW completes the command execution and reports > "Context State Error" completion code. This is as per the spec. However > HW on receiving the second command additionally marks EP to Flow control > state in HW which is RTL bug. The above bug causes the HW not to respond > to any further doorbells that are rung by the driver. This causes the EP > to not functional anymore and causes gross functional failures. > > As a workaround, not to hit this problem, its better we check the EP state > and issue the stop EP command only when the EP is in running state. Isn't there an unavoidable race? Suppose you check the EP state and the controller says the endpoint is running. But then a STALL packet is received and the controller stops the endpoint before you can issue the Stop-EP command. How would you handle that? Alan Stern -- 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: Feature proposal: Report connection speed through usbdevfs API
On Fri, 2 Jun 2017, Reinhard Huck wrote: > Thanks for the patch. That's exactly what we want. Could you please make > sure that the patch gets released? I will submit the patch. If it is accepted, it will appear in the 4.13 kernel release. Alan Stern -- 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 v2 02/27] ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops
On Thu, Jun 01, 2017 at 10:58:25PM +0200, Takashi Iwai wrote: > For supporting the explicit in-kernel copy of PCM buffer data, and > also for further code refactoring, three new PCM ops, copy_user, > copy_kernel and fill_silence, are introduced. The old copy and > silence ops will be deprecated and removed later once when all callers > are converted. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH v2 14/27] ASoC: blackfin: Convert to the new PCM ops
On Thu, Jun 01, 2017 at 10:58:37PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new PCM ops. > In AC97 and I2S-TDM mode, we need to convert back to frames, but > otherwise the conversion is pretty straightforward. Acked-by: Mark Brown signature.asc Description: PGP signature
[PATCH] USB: add usbfs ioctl to retrieve the connection speed
The usbfs interface does not provide any way for the user to learn the
speed at which a device is connected. The current API includes a
USBDEVFS_CONNECTINFO ioctl, but all it provides is the device's
address and a one-bit value indicating whether the connection is low
speed. That may have sufficed in the era of USB-1.1, but it isn't
good enough today.
This patch introduces a new ioctl, USBDEVFS_GET_SPEED, which returns a
numeric value indicating the speed of the connection: unknown, low,
full, high, wireless, super, or super-plus.
Similar information (not exactly the same) is available through sysfs,
but it seems reasonable to provide the actual value in usbfs.
Signed-off-by: Alan Stern
Reported-by: Reinhard Huck
---
[as1832]
drivers/usb/core/devio.c | 24
include/uapi/linux/usbdevice_fs.h | 10 ++
2 files changed, 34 insertions(+)
Index: usb-4.x/drivers/usb/core/devio.c
===
--- usb-4.x.orig/drivers/usb/core/devio.c
+++ usb-4.x/drivers/usb/core/devio.c
@@ -1322,6 +1322,27 @@ static int proc_connectinfo(struct usb_d
return 0;
}
+static int proc_get_speed(struct usb_dev_state *ps)
+{
+ switch (ps->dev->speed) {
+ case USB_SPEED_UNKNOWN:
+ return USBDEVFS_SPEED_UNKNOWN;
+ case USB_SPEED_LOW:
+ return USBDEVFS_SPEED_LOW;
+ case USB_SPEED_FULL:
+ return USBDEVFS_SPEED_FULL;
+ case USB_SPEED_HIGH:
+ return USBDEVFS_SPEED_HIGH;
+ case USB_SPEED_WIRELESS:
+ return USBDEVFS_SPEED_WIRELESS;
+ case USB_SPEED_SUPER:
+ return USBDEVFS_SPEED_SUPER;
+ case USB_SPEED_SUPER_PLUS:
+ return USBDEVFS_SPEED_SUPER_PLUS;
+ }
+ return -ERANGE;
+}
+
static int proc_resetdevice(struct usb_dev_state *ps)
{
struct usb_host_config *actconfig = ps->dev->actconfig;
@@ -2537,6 +2558,9 @@ static long usbdev_do_ioctl(struct file
case USBDEVFS_DROP_PRIVILEGES:
ret = proc_drop_privileges(ps, p);
break;
+ case USBDEVFS_GET_SPEED:
+ ret = proc_get_speed(ps);
+ break;
}
done:
Index: usb-4.x/include/uapi/linux/usbdevice_fs.h
===
--- usb-4.x.orig/include/uapi/linux/usbdevice_fs.h
+++ usb-4.x/include/uapi/linux/usbdevice_fs.h
@@ -156,6 +156,15 @@ struct usbdevfs_streams {
unsigned char eps[0];
};
+/* connection speed values used by USBDEVFS_GET_SPEED */
+#define USBDEVFS_SPEED_UNKNOWN 0
+#define USBDEVFS_SPEED_LOW 1
+#define USBDEVFS_SPEED_FULL2
+#define USBDEVFS_SPEED_HIGH3
+#define USBDEVFS_SPEED_WIRELESS4
+#define USBDEVFS_SPEED_SUPER 5
+#define USBDEVFS_SPEED_SUPER_PLUS 6
+
#define USBDEVFS_CONTROL _IOWR('U', 0, struct usbdevfs_ctrltransfer)
#define USBDEVFS_CONTROL32 _IOWR('U', 0, struct
usbdevfs_ctrltransfer32)
#define USBDEVFS_BULK _IOWR('U', 2, struct usbdevfs_bulktransfer)
@@ -190,5 +199,6 @@ struct usbdevfs_streams {
#define USBDEVFS_ALLOC_STREAMS _IOR('U', 28, struct usbdevfs_streams)
#define USBDEVFS_FREE_STREAMS _IOR('U', 29, struct usbdevfs_streams)
#define USBDEVFS_DROP_PRIVILEGES _IOW('U', 30, __u32)
+#define USBDEVFS_GET_SPEED _IO('U', 31)
#endif /* _UAPI_LINUX_USBDEVICE_FS_H */
--
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 2/3] usb: gadget: f_uac2: split out audio core
Hi Felipe, On Fri, Jun 2, 2017 at 12:34 PM, Felipe Balbi wrote: > > Hi, > > Ruslan Bilovol writes: >> Abstract the peripheral side ALSA sound card code from >> the f_uac2 function into a component that can be called >> by various functions, so the various flavors can be split >> apart and selectively reused. >> >> Visible changes: >> - add uac_params structure to pass audio paramteres for >>g_audio_setup >> - make ALSA sound card's name configurable >> - add [in/out]_ep_maxpsize >> - allocate snd_uac_chip structure during g_audio_setup >> - add u_audio_[start/stop]_[capture/playback] functions >> >> Signed-off-by: Ruslan Bilovol > > this doesn't apply on testing/next, care to rebase? > sure, I'll rebase it and address comments from Jassi Regards, Ruslan -- 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 0/3] USB Audio Gadget refactoring
Hi, On Fri, Jun 2, 2017 at 12:42 PM, Felipe Balbi wrote: > > Hi, > > Ruslan Bilovol writes: >> I came to this patch series when wanted to do two things: >> - use UAC1 as virtual ALSA sound card on gadget side, >>just like UAC2 is used so it's possible to do rate >>resampling >> - have both playback/capture support in UAC1 >> >> Since I wanted to have same behavior for both UAC1/UAC2, >> obviously I've got an utility part (u_audio.c) for >> virtual ALSA sound card handling like we have >> for ethernet(u_ether) or serial(u_serial) functions. >> Function-specific parts (f_uac1/f_uac2) became almost >> as storage for class-specific USB descriptors, some >> boilerplate for configfs, binding and few USB >> config request handling. >> >> Originally in RFC [1] I've posted before, there was >> major change to f_uac1 after that it couldn't do >> direct play to existing ALSA sound card anymore, >> representing audio on gadget side as virtual >> ALSA sound card where audio streams are simply >> sinked to and sourced from it, so it may break >> current usecase for some people (and that's why >> it was RFC). >> >> During RFC discussion, it was agreed to not touch >> existing f_uac1 implementation and create new one >> instead. This patchset (v4) introduced new function >> named f_uac1_acard and doesn't touch current f_uac1 >> implementation, so people still can use old behavior > > Do you have a pointer to the original RFC discussion where this was > discussed? If we really *must* keep the old implementation, I would > rather rename that to f_uac1_legacy. Still, I find it unlikely that > anybody will care about the old implementation. It is on LKML (which is down for me) [1] or alternative archive [2] > >> Now, it's possible to use existing user-space >> applications for audio routing between Audio Gadget >> and real sound card. I personally use alsaloop tool >> from alsautils and have ability to create PCM >> loopback between two different ALSA cards using >> rate resampling, which was not possible with previous >> "direct play to ALSA card" approach in f_uac1. > > this is really good result and will actually make it a lot easier for > testing things out. > >> While here, also dropped redundant platform >> driver/device creation in f_uac2 driver (as well as >> didn't add "never implemented" volume/mute functionality >> in f_uac1 to f_uac1_acard) that made this work even >> easier to do. >> >> This series is tested with both legacy g_audio.ko and >> modern configfs approaches under Ubuntu 14.04 (UAC1 and >> UAC2) and under Windows7 x64 (UAC1 only) having >> perfect results in all cases. >> >> Comments, testing are welcome. >> >> v4 changes: >> - renamed f_uac1_newapi to f_uac1_acard that is >>more meaningful > > I really don't get why you wanna keep both f_uac1 and f_uac1_acard. Why > do we need to maintain the old uac1 implementation? Why two separate > files? In first RFC ([1],[2]) I did exactly what you wrote here (removed old uac1 implementation and replaced it by new one) but got feedback that it will break things for existing f_uac1 legacy users and it's better to have separate implementation. I'm OK with dropping legacy f_uac1 implementation. Another idea I was thinking about is to implement simple in-kernel driver which will do the same as existing alsaloop tool userspace tool does (so legacy users will need to load two kernel modules and get same functionality). But this seems to be a wrong way, since It known that Linux kernel community doesn't like to take drivers with same functionality as existing userspace tools already have. So bottom line: since I'm not a legacy f_uac1 user, there is no difference for me how to handle it - remove legacy f_uac1 completely, rename it to f_uac1_legacy or add separate f_uac1_acard function. So if dropping of legacy f_uac1 implementation is OK for you, I can do it quickly in next patchset. [1] https://lkml.org/lkml/2016/5/23/649 [2] https://marc.info/?t=14640475881&r=1&w=4 Regards, Ruslan -- 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: [RFC] usb-phy-generic: Add support to SMSC USB3315
On 05/26, Fabien Lahoudere wrote: > Hello > > I modify ci_hrdc_imx_probe to bypass "data->phy = > devm_usb_get_phy_by_phandle(&pdev->dev, > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = > ulpi_register_interface(ci->dev, > &ci->ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is > called which is the > original function that make our system to hang. > > Our phy is not initialised before calling ulpi_register_interface so I don't > understand how the phy > can reply if it is not out of reset state. I haven't see any problem in hw_phymode_configure(). What's the value of ci->platdata->phy_mode? USBPHY_INTERFACE_MODE_ULPI? If you phy needs to be taken out of reset to reply to the ulpi reads of the vendor/product ids, then it sounds like you have a similar situation to what I had. I needed to turn on some regulators to get those reads to work, otherwise they would fail, but knowing what needed to be turned on basically meant I needed to probe the ulpi driver so probing the ids wasn't going to be useful. So on my device the reads for the ids go through, but they get all zeroes back, which is actually ok because there aren't any bits set on my devices anyway. After the reads see 0, we fallback to DT matching, which avoids the "bring it out of reset/power it on" sorts of problems entirely. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v2 resend] omap: usb: host: remove deprecated flags and structures
From: Ruslan Bilovol
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol
---
Although this patch was acked-by Felipe Balbi and Roger Quadros back
in 2013, it was never picked up by maintainers.
Still applies to v4.12-rc3 and saves few bytes of memory
include/linux/platform_data/usb-omap.h | 20
1 file changed, 20 deletions(-)
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index fa579b4..4c7acbe 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -38,34 +38,14 @@ enum usbhs_omap_port_mode {
OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
};
-struct usbtll_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
-};
-
-struct ehci_hcd_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
- int reset_gpio_port[OMAP3_HS_USB_PORTS];
- struct regulator*regulator[OMAP3_HS_USB_PORTS];
- unsignedphy_reset:1;
-};
-
-struct ohci_hcd_omap_platform_data {
- enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
- unsignedes2_compatibility:1;
-};
-
struct usbhs_omap_platform_data {
int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
int reset_gpio_port[OMAP3_HS_USB_PORTS];
struct regulator*regulator[OMAP3_HS_USB_PORTS];
- struct ehci_hcd_omap_platform_data *ehci_data;
- struct ohci_hcd_omap_platform_data *ohci_data;
-
/* OMAP3 <= ES2.1 have a single ulpi bypass control bit */
unsigned single_ulpi_bypass:1;
- unsigned es2_compatibility:1;
unsigned phy_reset:1;
};
--
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
Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt
Forgot to CC linux-usb, doing that now
On Fri, 2 Jun 2017 16:27:56 -0700, Paul Zimmerman wrote:
> Felipe Balbi writes:
> > Thinh Nguyen writes:
> >> this could be, I don't remember if I checked this or not :-)
> >>
> >> Really, the best way here, IMHO, would be to re-verify what's going on
> >> with macOS and revert my orignal patch since it's, rather clearly,
> >> wrong.
> >>
> >
> > Sure. Are you going to make a revert patch or I am?
>
> Well, after we really know what's going on with macOS and have a better
> fix, then who makes the revert is less important as long as problems get
> sorted out :-) Either way is fine for me.
>
> >>>
> >>> Do you have any update on this issue?
> >>>
> >>
> >> The patch ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when
> >> invalid") still causes a regression for us. As there hasn't any update
> >> for the macOS issue, can I submit a revert patch for this?
> >
> > I just came back from vacations ;-) I'll get back to this. Reverting
> > that commit won't do any good as we'd be exchanging one regression for
> > another. We really need to understand what's going on.
>
> Hi Felipe,
>
> I think we worked around this same issue in the Synopsys vendor driver
> after a customer reported a problem with CLEAR_FEATURE(ENDPOINT_HALT).
> I no longer have access to either the databook or the codebase, so I
> can't be sure about what the workaround was, but if either John or Thinh
> can have a look at the Clear Stall code in the vendor driver they should
> be able to figure it out.
>
> Best Regards,
> Paul
--
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: add usbfs ioctl to retrieve the connection speed
On Fri, Jun 02, 2017 at 01:27:48PM -0400, Alan Stern wrote:
> The usbfs interface does not provide any way for the user to learn the
> speed at which a device is connected. The current API includes a
> USBDEVFS_CONNECTINFO ioctl, but all it provides is the device's
> address and a one-bit value indicating whether the connection is low
> speed. That may have sufficed in the era of USB-1.1, but it isn't
> good enough today.
>
> This patch introduces a new ioctl, USBDEVFS_GET_SPEED, which returns a
> numeric value indicating the speed of the connection: unknown, low,
> full, high, wireless, super, or super-plus.
>
> Similar information (not exactly the same) is available through sysfs,
> but it seems reasonable to provide the actual value in usbfs.
>
> Signed-off-by: Alan Stern
> Reported-by: Reinhard Huck
>
> ---
>
>
> [as1832]
>
>
> drivers/usb/core/devio.c | 24
> include/uapi/linux/usbdevice_fs.h | 10 ++
> 2 files changed, 34 insertions(+)
>
> Index: usb-4.x/drivers/usb/core/devio.c
> ===
> --- usb-4.x.orig/drivers/usb/core/devio.c
> +++ usb-4.x/drivers/usb/core/devio.c
> @@ -1322,6 +1322,27 @@ static int proc_connectinfo(struct usb_d
> return 0;
> }
>
> +static int proc_get_speed(struct usb_dev_state *ps)
> +{
> + switch (ps->dev->speed) {
> + case USB_SPEED_UNKNOWN:
> + return USBDEVFS_SPEED_UNKNOWN;
> + case USB_SPEED_LOW:
> + return USBDEVFS_SPEED_LOW;
> + case USB_SPEED_FULL:
> + return USBDEVFS_SPEED_FULL;
> + case USB_SPEED_HIGH:
> + return USBDEVFS_SPEED_HIGH;
> + case USB_SPEED_WIRELESS:
> + return USBDEVFS_SPEED_WIRELESS;
> + case USB_SPEED_SUPER:
> + return USBDEVFS_SPEED_SUPER;
> + case USB_SPEED_SUPER_PLUS:
> + return USBDEVFS_SPEED_SUPER_PLUS;
> + }
> + return -ERANGE;
We already export the USB_SPEED values to userspace, why not just use
those already, so we don't have to define yet-another-value?
That would make this function much simple :)
thanks,
greg k-h
--
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: [GIT PULL] Fixes for v4.12-rc4
On Fri, Jun 02, 2017 at 12:57:57PM +0300, Felipe Balbi wrote: > > Hi Greg, > > here's another set of fixes for current -rc cycle. Let me know if you > want anything to be changed. Patches have been on the mailing list for > quite some time. > > At least the mass storage patch (the only one I could test) has been > tested on some intel boards I have around for a few days. > > cheers > > The following changes since commit 5ed02dbb497422bf225783f46e6eadd237d23d6b: > > Linux 4.12-rc3 (2017-05-28 17:20:53 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > fixes-for-v4.12-rc4 Pulled and pushed out, you will not get the automated emails as my tree was based on 4.12-rc2, and I don't want to spam everyone who did work since them with those emails :) thanks, greg k-h -- 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-usb:testing/next 35/35] drivers/usb/gadget/udc/snps_udc_core.c:197:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next head: ad9721fbf4c4dd7e57372662b91adb8ba0c3a9fc commit: ad9721fbf4c4dd7e57372662b91adb8ba0c3a9fc [35/35] usb: gadget: udc: Add Synopsys UDC Platform driver config: m32r-allmodconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout ad9721fbf4c4dd7e57372662b91adb8ba0c3a9fc # save the attached .config to linux build tree make.cross ARCH=m32r All warnings (new ones prefixed by >>): In file included from include/linux/printk.h:329:0, from include/linux/kernel.h:13, from include/linux/list.h:8, from include/linux/module.h:9, from drivers/usb/gadget/udc/snps_udc_core.c:23: drivers/usb/gadget/udc/snps_udc_core.c: In function 'print_regs': >> drivers/usb/gadget/udc/snps_udc_core.c:197:11: warning: format '%x' expects >> argument of type 'unsigned int', but argument 4 has type 'long unsigned int' >> [-Wformat=] DBG(dev, "dev config = %08x\n", readl(&dev->regs->cfg)); ^ include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg' __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~ >> drivers/usb/gadget/udc/amd5536udc.h:658:28: note: in expansion of macro >> 'dev_dbg' #define DBG(udc , args...) dev_dbg(udc->dev, args) ^~~ >> drivers/usb/gadget/udc/snps_udc_core.c:197:2: note: in expansion of macro >> 'DBG' DBG(dev, "dev config = %08x\n", readl(&dev->regs->cfg)); ^~~ drivers/usb/gadget/udc/snps_udc_core.c:198:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] DBG(dev, "dev control= %08x\n", readl(&dev->regs->ctl)); ^ include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg' __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~ >> drivers/usb/gadget/udc/amd5536udc.h:658:28: note: in expansion of macro >> 'dev_dbg' #define DBG(udc , args...) dev_dbg(udc->dev, args) ^~~ drivers/usb/gadget/udc/snps_udc_core.c:198:2: note: in expansion of macro 'DBG' DBG(dev, "dev control= %08x\n", readl(&dev->regs->ctl)); ^~~ drivers/usb/gadget/udc/snps_udc_core.c:199:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] DBG(dev, "dev status = %08x\n", readl(&dev->regs->sts)); ^ include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg' __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~ >> drivers/usb/gadget/udc/amd5536udc.h:658:28: note: in expansion of macro >> 'dev_dbg' #define DBG(udc , args...) dev_dbg(udc->dev, args) ^~~ drivers/usb/gadget/udc/snps_udc_core.c:199:2: note: in expansion of macro 'DBG' DBG(dev, "dev status = %08x\n", readl(&dev->regs->sts)); ^~~ drivers/usb/gadget/udc/snps_udc_core.c:201:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] DBG(dev, "dev int's = %08x\n", readl(&dev->regs->irqsts)); ^ include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg' __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~ >> drivers/usb/gadget/udc/amd5536udc.h:658:28: note: in expansion of macro >> 'dev_dbg' #define DBG(udc , args...) dev_dbg(udc->dev, args) ^~~ drivers/usb/gadget/udc/snps_udc_core.c:201:2: note: in expansion of macro 'DBG' DBG(dev, "dev int's = %08x\n", readl(&dev->regs->irqsts)); ^~~ drivers/usb/gadget/udc/snps_udc_core.c:202:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=] DBG(dev, "dev intmask= %08x\n", readl(&dev->regs->irqmsk)); ^ include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg' __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~ >> drivers/usb/gadget/udc/amd5536udc.h:658:28: note: in expansion of macro >> 'dev_dbg' #define DBG(udc , args...) dev_dbg(udc->dev, args) ^~~ drivers/usb/gadget/udc/snps_udc_core.c:202:2: note: in expansion of macro 'DBG' DBG(dev, "dev intmask= %08x\n", readl(&dev->regs->irqmsk)); ^~~ drivers/usb/gadget/udc/snps_udc_core.c:204:11: warning: format '%x' exp
