the wd_work and mei_wd_timer() function was not just for watchdog.
mei managing the AMT watchdog going to be replace by the kernel watchdog
interface.
the mei_timer() will still manage the mei driver timeouts.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
add the ability to let the watchdog core set
the AMT watchdog timeout value.
the default value will be only set in the start function.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
adding watchdog ping to send ping/heartbeat to the the AMT watchdog client.
in addition removing the heartbeat sending from the driver timers function.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
adding start and stop function.
start - check if AMT wd client is connected, which is been connected on driver
load.
stop - send stop command to AMT wd.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adding kernel watchdog interface (/dev/watchdog) to the MEI Driver to support AMT Watchdog feature.
This patch and the following one will replace MEI Driver self management of the AMT watchdog
with the standard kernel watchdog interface.
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
AMTHI need to be initialized after WD Client was initialized, moving the AMTHI outside
of the WD initialization function.
in order to remove the coupling between the initialization of those clients.
AMTHI is getting initialized (getting connected to the FW feature/client) in two ways:
1) if mei driver fails to send connect message to watchdog client (WD initialization), then
immediately the AMTHI client getting initialized right after the watchdog initialization function.
2) if Watchdog client success to send connect message to watchdog client, then only after
the driver is getting the connect response message the AMTHI client is getting initialized
Signed-off-by: Oren Weil <oren.jer.weil@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Change the static array of 'struct device''s in struct vme_bridge
to instead use an array of pointers. This is in accordance with the
requirement that all kobjects be dynamically allocated (see
Documentation/kobject.txt) and never be statically allocated.
Signed-off-by: Manohar Vanga <manohar.vanga@cern.ch>
Acked-by: Martyn Welch <martyn.welch@ge.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The check for (adap->active_fe < 0) at the top of dvb_usb_ctrl_feed is a sanity
check to ensure that adap->active_fe is valid. Improve that sanity check
by also checking for (adap->active_fe >= adap->num_frontends_initialized)
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This fixes a bug introduced by a previous changeset entitled,
[media] dvb-usb: refactor MFE code for individual streaming config per frontend
As reported by Antti Palosaari, This error is shown by VLC when channel changed:
[0x7f1bbc000cd0] dvb access error: DMXSetFilter: failed with -1 (Invalid argument)
[0x7f1bbc000cd0] dvb access error: DMXSetFilter failed
[0x7f1bbc32f910] main stream error: cannot pre fill buffer
After my own investigations, I've determined that this error case occurs when
the application stops streaming but leaves the frontend and dvr devices open.
A typical example of this usage would be a channel change operation while
watching live television. The error occurs when the application attempts to
stream after tuning to the new channel.
To prevent this error, don't set adap->active_fe to -1 unless the application
closes the device.
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4 hardware is a true multitouch capable touchpad (up to 5 fingers).
The packet format is quite complex, please see protocol document for
reference.
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
v3 hardware's packet format is almost identical to v2 (one/three finger touch),
except when sensing two finger touch, the hardware sends 12 bytes of data.
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
For v2 hardware, there is no real parity check, but we can still check
some constant bits for data integrity.
Also rename elantech_check_parity_v1 to elantech_packet_check_v1 to make
these packet checking function names consistent.
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Don't try to be too clever and remove ETP_EDGE_FUZZ_V2. X, Y ranges
should be just the raw resolution of the device. Otherwise, they can
cause underflow on the Y axis.
Suggested-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
With newer hardware, the touchpad provides range info.
Let's use it.
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
For two finger touches the coordinate of each finger gets reported
separately but with reduced resolution.
With this change, we now have the same range for ST and MT data and
scale MT data because it has lower resolution to match ST.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Acked-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Fix warning from Geert's build summary emails by changing "if" to
"ifdef". Thsi should fix the following:
drivers/input/misc/twl6040-vibra.c:231:5: warning: "CONFIG_PM_SLEEP" is not defined
Builds cleanly with CONFIG_PM_SLEEP enabled or disabled.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Take spinlock when entering ISR and timer routine to ensure that we do not
race while enabling/disabling FIFO interrupts.
Also we do not need to take teh spinlock in tegra_kbc_startremove() since
interrupt is completely disabled.
Tested-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
For wakeup to be reliable, kbc needs to be in interrupt mode before suspend.
Created common routine to control the FIFO interrupt.
Added synchronization to ensure orderly suspend.
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This patch enables DMA mode1 for the RX path when we know
there won't be any short packets. We check that by looking
into the short_no_ok flag, if it's true we enable mode1, otherwise
we use mode0 to transfer the data.
This will result in a throughput performance gain of around
40% for USB mass-storage/mtp use cases.
[ balbi@ti.com : updated commit log and code comments slightly ]
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Tested-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
On Audio class, the wLength field of the Setup
packet, contains the data payload size of the
following Data phase. Instead of harcoding values,
use wLength.
This also fixes a bug where Gadget driver had to
receive 3 bytes, but it was queueing a ZLP.
Signed-off-by: Felipe Balbi <balbi@ti.com>
While testing g_audio with HighSpeed UDC on a
FS Hub, we had no configurations to present to
the host. That's because both speeds where
mutually exclusive.
Signed-off-by: Felipe Balbi <balbi@ti.com>
FSG_NUM_BUFFERS is set to 2 as default.
Usually 2 buffers are enough to establish a good buffering pipeline.
The number may be increased in order to compensate a for bursty VFS
behaviour.
Here follows a description of system that may require more than
2 buffers.
* CPU ondemand governor active
* latency cost for wake up and/or frequency change
* DMA for IO
Use case description.
* Data transfer from MMC via VFS to USB.
* DMA shuffles data from MMC and to USB.
* The CPU wakes up every now and then to pass data in and out from VFS,
which cause the bursty VFS behaviour.
Test set up
* Running dd on the host reading from the mass storage device
* cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
* Caches are dropped on the host and on the device before each run
Measurements on a Snowball board with ondemand_governor active.
FSG_NUM_BUFFERS 2
104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s
FSG_NUM_BUFFERS 4
104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s
There may not be one optimal number for all boards. This is why
the number is added to Kconfig. If selecting USB_GADGET_DEBUG_FILES
this value may be set by a module parameter as well.
Signed-off-by: Per Forlin <per.forlin@linaro.org>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch (as1481) fixes a problem affecting g_file_storage and
g_mass_storage when running at SuperSpeed. The two drivers currently
assume that the bulk-out maxpacket size can evenly divide the SCSI
block size, which is 512 bytes. But SuperSpeed bulk endpoints have a
maxpacket size of 1024, so the assumption is no longer true.
This patch removes that assumption from the drivers, by getting rid of
a small optimization (they try to align VFS reads and writes on page
cache boundaries). If a command's starting logical block address is
512 bytes below the end of a page, it's not okay to issue a USB
command for just those 512 bytes when the maxpacket size is 1024 -- it
would result in either babble (for an OUT transfer) or a short packet
(for an IN transfer).
Also, for backward compatibility, the test for writes extending beyond
the end of the backing storage has to be changed. If the host tries
to do this, we should accept the data that fits in the backing storage
and ignore the rest. Because the storage's end may not align with a
USB packet boundary, this means we may have to accept a USB OUT
transfer that extends beyond the end of the storage and then write out
only the part of the data that fits.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Now the mass storage driver has fixed logic block size of 512 bytes.
The mass storage gadget read/write bound devices only through VFS, so the
bottom level devices actually are just RAW devices to the driver and connected
PC. As a RAW, hosts can always format, read and write it right in 512 bytes
logic block and don't care about the actual logic block size of devices bound
to the gadget.
But if we want to share the bound block device partition between target board
and PC, in case the logic block size of the bound block device is 4KB, we
execute the following steps:
1. connect a board with mass storage gadget to PC(the board has set one
partition of on-board block device as file name of the mass storage)
2. PC format the mass storage to VFAT by default logic block size and
read/write it
3. disconnect boards from PC
4. target board mount the partition as VFAT
Step 4 will fail since kernel on target thinks the logic block size of the
bound partition as 4KB.
A typical error is "FAT: logical sector size too small for device (logical
sector size = 512)"
If we execute opposite steps:
1. format the partition to VFAT on target board and read/write this partition
2. connect the board to Windows PC as usb mass storage gadget, windows will
think the disk is not formatted
So the conclusion is that only as a gadget, the mass storage driver has no any
problem. But being shared VFAT or other filesystem on PC and target board, it
will fail.
This patch adapts logic block size to bound block devices and fix the issue.
Cc: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peiyu Li <peiyu.li@csr.com>
Signed-off-by: Xianglong Du <xianglong.du@csr.com>
Signed-off-by: Huayi Li <huayi.li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
It's useful to know which states core is going
through, as it might help us figure out misbehavior
on specific link states.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This flag will tell us which direction we're
expecting on the next (data or status) phase.
It will help us catching errors of host going
crazy and requesting data of the wrong direction.
Signed-off-by: Felipe Balbi <balbi@ti.com>
if req->dma isn't DMA_ADDR_INVALID it means gadget driver
mapped the request or allocated from coherent, so it's
unnecessary to do anything.
Signed-off-by: Felipe Balbi <balbi@ti.com>
If the gadget drivers sends a ZLP we are trying to map this this request
which does not work on all implementations. So we simply skip mapping
it.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
dwc3-wrapper can be used by any other wrapper,
using dwc3-omap makes it clear that we're running
on OMAP SoC.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The OMAP wrapper allows us to either control internal
OTG signals via SW or HW. Different boards might wish
to use one or the other mode of operation. Let's have
have that information passed via platform_data for now.
After DT conversion is finished for OMAP, we can easily
convert this to a DT attribute.
Signed-off-by: Felipe Balbi <balbi@ti.com>
We need to have actual HW in order to implement
and test that part of the code anyway. Until then
it's best to remove it.
Signed-off-by: Felipe Balbi <balbi@ti.com>
this field will hold the next expected event.
In certain cases, host might fall into some error
condition and ask from us the wrong Control phase.
On such situations, we should stall and restart.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Whenever we issue a Set Stall command on EP0,
the state machine will be restarted and Stall
is cleared automatically, when core receives
the next SETUP packet.
There's no need to track that EP0_STALL state.
Signed-off-by: Felipe Balbi <balbi@ti.com>
when we're going to issue Set Stall command,
we should clear DWC3_EP_STALL flag, but also
we should clear BUSY, HALTED and all others.
Signed-off-by: Felipe Balbi <balbi@ti.com>
There are two spots where we wait until the HW finishes processing a
certain command. Initially we had a few problems and we used 500ms as a
limit to be on a the safe side. Paul Zimmerman mentioned this is little too
much. After a debugging session, we noticed that we hardly ever go over 20us
and didn't pass 30usec so far. Using mdelay() seems way overloaded.
Giving the current numbers 500usec as the upper limit is more than enough.
Should it ever timeout then something is definitely wrong.
While here, also replace the type with u32 since long does not really
fit here.
Cc: Paul Zimmerman <paul.zimmerman@synopsys.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
