| Age | Commit message (Collapse) | Author |
|---|
|
Make videobuf2-v4l2 as a wrapper of videobuf2-core for v4l2-use.
And replace videobuf2-core.h with videobuf2-v4l2.h.
This renaming change should be accompanied by the modifications
of all device drivers that include videobuf2-core.h.
It can be done with just running this shell script.
replace()
{
str1=$1
str2=$2
dir=$3
for file in $(find $dir -name *.h -o -name *.c -o -name Makefile)
do
echo $file
sed "s/$str1/$str2/g" $file > $file.out
mv $file.out $file
done
}
replace "videobuf2-core" "videobuf2-v4l2" "include/media/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/media/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/usb/gadget/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/staging/media/"
Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
This patch adds a compatible string to support for R-Car H3.
Since the HS-USB controller of R-Car H3 is almost the same specification
with R-Car Gen2 (these have 16 pipes and usb-dmac), this patch
sets the "type" of renesas_usbhs_driver_param to USBHS_TYPE_RCAR_GEN2.
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This patch fixes the following warning if 64-bit architecture environment:
./drivers/usb/renesas_usbhs/common.c:496:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
dparam->type = of_id ? (u32)of_id->data : 0;
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If dma_pool_alloc() fails we are jumping to fail and releasing all the
bd_tables which have been added to the chain but we missed freeing this
bd_table which was just allocated and still not added to the chain of
bd_table.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
We want the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We *know* our threads executes with our IRQs
disabled. We really don't need to use the _irqsave()
variant of spin_lock().
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Instead of limiting __dwc3_gadget_kick_transfer() to
Xfer Complete, we can try to issue Update Transfer
command from Xfer In Progress too.
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If we get a Xfer Not Ready event with reason
"Transfer Active" it means endpoint is still
transferring data and we can use that to issue
update transfer for this particular endpoint
in case we have pending requests in our queue.
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
if by the time we get to XFER_COMPLETE we have
pending requests to be processed, instead of waiting
for a following XFER_NOT_READY, let's start the request
right away and, maybe, save the time of a few NAKs
due to lack of started transfers.
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
gadget methods should be called without
spinlocks held.
Reported-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Sharing the ACPI companion with dwc3 core so it has access
to the properties defined for DWC3 in ACPI tables.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
No functional affect on existing platforms, but the driver
is now ready to extract the properties also from ACPI tables
as well as from DT.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
of_usb_get_dr_mode will be converted into more generic
usb_get_dr_mode function that will take struct device
instead of struct device_node as its parameter.
To make the conversion possible later, waiting for the
platform device for dwc3 to be populated before calling
of_usb_get_dr_mode.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
CC: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of tcm, ep->driver_data was used only for endpoint claiming so
we can simplify code by reducing it. We also remove give_back_ep()
function which is not needed after all - when error code is returned
from bind() function, composite will release all endpoints anyway.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of dbgp, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of u_serial ep->driver_data stores pointer to struct gs_port,
which is referenced in many places in code. Code using ep->driver_data
to mark endpoint as enabled/disabled has been removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of u_ether we only need to store in ep->driver_data pointer to
struct eth_dev, as it's used in rx_complete() and tx_complete() callbacks.
All other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uvc, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uac2, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uac1, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_subset, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_sourcesink we only need to store in ep->driver_data pointer
to struct f_sourcesink, as it's used in source_sink_complete() callback.
All other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_serial, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_rndis, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_printer we only need to store in ep->driver_data pointer to
struct printer_dev, as it's used in rx_complete() and tx_complete()
callbacks. All other uses of ep->driver_data are now meaningless and can
be safely removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_phonet we only need to store in ep->driver_data pointer to
struct f_phonet, as it's used in pn_tx_complete() and pn_rx_complete()
callbacks. All other uses of ep->driver_data are now meaningless and can
be safely removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_obex, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ncm, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_midi we only need to store in ep->driver_data pointer to
struct f_midi, as it's used in f_midi_complete() callback and related
functions. All other uses of ep->driver_data are now meaningless and
can be safely removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_mass_storage we only need to store in ep->driver_data
pointer to struct fsg_common, which is used in bulk_in_complete() and
bulk_out_complete() callbacks. All other uses of ep->driver_data are now
meaningless and can be safely removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_hid we only need to store in ep->driver_data pointer to
struct f_loopback, as it's used in loopback_complete() callback. All
other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_hid we only need to store in ep->driver_data pointer to
struct f_hidg, as it's used in f_hidg_req_complete() callback. All
other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ecm, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_acm we only need to store in ep->driver_data pointer to
struct f_acm, as it's used in acm_complete_set_line_coding() callback.
All other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ecm, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This patch introduces usb_ep_autoconfig_release() function which allows
to release endpoint previously obtained from usb_ep_autoconfig() during
USB function bind.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The 'driver_data' field in ep0 is never set to pointer to cdev, so we
have to obtain it from another source as in this context ep->driver_data
contains invalid data.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Fix comments in code to make them up to date.
composite: claiming endpoint is now done by setting ep->claimed flag,
not ep->driver_data.
epautoconf: usb_ep_autoconfig() and usb_ep_autoconfig_ss() return
claimed endpoint with ep->claimed flag already set.
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The millisecond of the last second will be normal if tv_sec is
overflowed. But for y2038 consistency and demonstration purpose,
and avoiding further risks, we need to remove 'timeval' in this
driver, to avoid similair problems.
Signed-off-by: Pingbo Wen <pingbo.wen@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Add support for USB DRVVBUS pinctrl state change during
suspend/resume. This helps is conserving power during
system sleep.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Since the host and gadget can't agree with transfer length before
each transfer, but they agree with max packet size for each
endpoint, we use max packet size to format data pattern.
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
With this change, the host and gadget doesn't need to agree with transfer
length for comparing the data, since they doesn't know each other's
transfer size, but know max packet size.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
(Fixed the 'line over 80 characters warning' by Peter Chen)
Tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Using the same data format "buf[j] = (u8)(i + j)" among
write, compare buf, and console output stage.
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The element of urbs array will be initialized at below code
at once.
for (i = 0; i < param->sglen; i++) {
urbs[i] = iso_alloc_urb(udev, pipe, desc,
param->length, offset);
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Allocate the size of urb pointer array according to testusb's
parameter sglen, and limits the length of sglen as MAX_SGLEN
(128 currently).
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This patch switches calls to readl/writel to their
dwc2_readl/dwc2_writel equivalents which preserve platform endianness.
This patch is necessary to access dwc2 registers correctly on big-endian
systems such as the mips based SoCs made by Lantiq. Then dwc2 can be
used to replace ifx-hcd driver for Lantiq platforms found e.g. in
OpenWrt.
The patch was autogenerated with the following commands:
$EDITOR core.h
sed -i "s/\<readl\>/dwc2_readl/g" *.c hcd.h hw.h
sed -i "s/\<writel\>/dwc2_writel/g" *.c hcd.h hw.h
Some files were then hand-edited to fix checkpatch.pl warnings about
too long lines.
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
USB network adapters support Jumbo frames. The only thing blocking
that feature is the code in the gadget driver that disposes of
packets larger than 1518 bytes, and the limit on the ioctl to set
the mtu.
This patch relaxes these limits, and allows up to 15k frames sizes.
The 15k value was chosen because 16k does not work on all platforms,
and usingclose to 16k will result in allocating 5 or 8 4k pages to
store the skb, wasting pages at no measurable performance gain.
On a topic-miami board (Zynq-7000), iperf3 performance reports:
MTU= 1500, PC-to-gadget: 139 Mbps, Gadget-to-PC: 116 Mbps
MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps
On boards with slower CPUs the performance improvement will be
relatively much larger, e.g. an OMAP-L138 increased from 40 to
220 Mbps using a similar patch on an 2.6.37 kernel.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
struct at91_udc_data is now only used inside the driver, move it to its
include.
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
