Support for TSYS02D temperature sensor
Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The code under the label can normally be inline, without the
jumping back and forth but the latter is an optimization.
Document that.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20151009170859.GA24266@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Guenter reports that commit:
7bf793115d ("efi, x86: Rearrange efi_mem_attributes()")
breaks the IA64 compilation with the following error:
drivers/built-in.o: In function `efi_mem_attributes': (.text+0xde962): undefined reference to `memmap'
Instead of using the (rather poorly named) global variable
'memmap' which doesn't exist on IA64, use efi.memmap which
points to the 'memmap' object on x86 and arm64 and which is NULL
for IA64.
The fact that efi.memmap is NULL for IA64 is OK because IA64
provides its own implementation of efi_mem_attributes().
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jonathan Zhang <zjzhang@codeaurora.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/20151003222607.GA2682@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
- Enable basic GICv3 support on 32bit ARM (mostly for running VMs with
more than 8 virtual CPUs)
- arm64 changes to deal with firmware limitations that forces a GICv3
to be used as a GICv2
- A GICv2m erratum workaround on Applied Micro X-Gene2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWGD66AAoJECPQ0LrRPXpD+P8P/2rEr+s6jmhBO6OWFnnJzDEy
s/EbgSMgbbCE29HxPnanhYriNUcM7qhyHkeUpLMrWiuPBBj6nB8dzry0ZVzy0JDb
swmzlufRfBHXNIYyW9GdLPAZpkDwFUFrUsP4H+desoJ4JCBEHNegkwLY7BVUnGMK
gujFzsFrMiDdNA8viaYHc+KmMSGowCpMlPLn5fS99SuZ/4B2+IwtM8bJFexNFPoX
nyf0Y09Uymww5ObzvYcbcAnBOSeqGjhKpD2HjN4c5UArmh88Cd++GDLBBVS2hHkr
m6Ds/ONaiEtjK58y+TD9QGtbrbThOTmnlhbp9hdZGP4RzoVBg2GdlWDqw2DzV7Qi
ntRgFzcieDcNM+gu3zYNLBffXBqdBMx34srdSq/DU2iUFRf2RnJ39ybdGL4z7yRa
ZT0gVBEYF7vGR0kmQXCWefNo7ogXgk8AOr4jdvPb3qkXIcXbxNU/dYEjEcH47E36
+Zj9K5YdqCVXOJFx4R/8kFhcEznMCPbGb07MGGGBkYvbaST35CfBEENooRyuOzbX
0WW2/0Ow+ubvrAchgVfHybnRFuzZAahwV8k49MA7htdOPQ9PMdMbElpMsThRjKZO
ed7JtTxVFsyQwEg1WM8clcas/sit4kCtwGwQI2E8rXqNJRLRwMbmoMvrgzqGDTXX
i7M0Ylhx4iGs04Dgsb8C
=qtSH
-----END PGP SIGNATURE-----
Merge tag 'gic-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
GIC updates for Linux 4.4 from Marc Zyngier:
- Enable basic GICv3 support on 32bit ARM (mostly for running VMs with
more than 8 virtual CPUs)
- arm64 changes to deal with firmware limitations that forces a GICv3
to be used as a GICv2
- A GICv2m erratum workaround on Applied Micro X-Gene2
My Intel email address will soon expire. Replace it with my
personal address so people still know where to send patches.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1444494136-10333-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Add fpga manager framework to MAINTAINERS and add myself as
maintainer.
Signed-off-by: Alan Tull <atull@opensource.altera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use unsigned long in place of size_t to operate on buffer sizes and
offsets to clean up the 32 bit build.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Source device's link is protected with srcu, mark it as such to have
proper build-time validation of accesses to this field. The update
side that's dereferencing it under an update lock also needs an
accessor to dereference this field to keep sparse happy.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When we initialize the driver/device, we really don't know how many
controllers are connected. So send a "query presence" command to the
base-station. (Command discovered by Zachary Lund)
Presence packet taken from:
https://github.com/computerquip/xpad5
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To allow us to later create / destroy the input device from the urb
callback, we need to initialize/ deinitialize the input device from a
separate function. So pull that logic out now to make later patches
more "obvious" as to what they do.
Signed-off-by: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
as discussed here[0], x360w is the only pad that maps dpad_to_button.
This is bad for downstream developers as they have to differ between
x360 and x360w which is not intuitive.
This patch implements the suggested solution of exposing the dpad both
as axes and as buttons. This retains backward compatibility with software
already dealing with the difference while makes new software work as
expected across x360/ x360w pads.
[0] http://www.spinics.net/lists/linux-input/msg34421.html
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Move submission logic to a single point at the end of the function.
This makes it easy to add locking/ queuing code later on.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This code was probably wrong ever since and is redundant with
xpad_send_led_command. Both try to send a similar command to the xbox360
controller. However xpad_send_led_command correctly uses the pad_nr instead
of bInterfaceNumber to select the led and re-uses the irq_out URB instead
of creating a new one.
Note that this change only affects the two supported wireless controllers.
Tested using the xbox360 wireless controller (PC).
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The pad_nr corresponds to the lit up LED on the controller. Therefore there
should be no gaps when enumerating. Currently a LED is only re-assigned
after a controller is re-connected 4 times.
This patch uses ida to track connected pads - this way we can re-assign
freed up pad number immediately.
Consider the following case:
1. pad A is connected and gets pad_nr = 0
2. pad B is connected and gets pad_nr = 1
3. pad A is disconnected
4. pad A is connected again
using ida_simple_get() controller A now correctly gets pad_nr = 0 again.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Rename led_no -> pad_nr: the number stored there is not the LED number - it
gets translated later on to a LED number in xpad_identify_controller;
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The "Razer Atrox Arcade Stick" features 10 buttons, and two of them (LT/RT)
don't work properly. Change its definition in xpad_device[] (mapping
field) to fix.
Signed-off-by: Dario Scarpa <dario.scarpa@duskzone.it>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
It is identical to the Xbox One controller but has a different product ID.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The copyright/license notice says that the code is licensed under GPL v2
only (not GPL v2+), so let's use proper string in MODULE_LICENSE().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Here are some small USB and PHY fixes and quirk updates for 4.3-rc5.
Nothing major here, full details in the shortlog, and all of these have
been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYZOFUACgkQMUfUDdst+ymLSACeLNl7IWSxq2acJ5rhUl5+LRxp
KtsAn3lMXJryk4xw2WpfJg30TXpWXnNM
=n9ei
-----END PGP SIGNATURE-----
Merge tag 'usb-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB and PHY fixes and quirk updates for 4.3-rc5.
Nothing major here, full details in the shortlog, and all of these
have been in linux-next for a while"
* tag 'usb-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: Add device quirk for Logitech PTZ cameras
USB: chaoskey read offset bug
USB: Add reset-resume quirk for two Plantronics usb headphones.
usb: renesas_usbhs: Add support for R-Car H3
usb: renesas_usbhs: fix build warning if 64-bit architecture
usb: gadget: bdc: fix memory leak
phy: berlin-sata: Fix module autoload for OF platform driver
phy: rockchip-usb: power down phy when rockchip phy probe
phy: qcom-ufs: fix build error when the component is built as a module
Here are a few bug fixes for the tty core that resolve reported issues,
and some serial driver fixes as well (including the much-reported imx
driver problem.)
All of these have been in linux-next with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYZOMsACgkQMUfUDdst+ykHVQCdEiZhPNcK5Y6E80pzvhGSSkHa
s+kAoJLT4hqzehZkP1hVImxKmWQpq1d1
=8zsH
-----END PGP SIGNATURE-----
Merge tag 'tty-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial driver fixes from Greg KH:
"Here are a few bug fixes for the tty core that resolve reported
issues, and some serial driver fixes as well (including the
much-reported imx driver problem)
All of these have been in linux-next with no reported problems"
* tag 'tty-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
drivers/tty: require read access for controlling terminal
serial: 8250: add uart_config entry for PORT_RT2880
tty: fix data race on tty_buffer.commit
tty: fix data race in tty_buffer_flush
tty: fix data race in flush_to_ldisc
tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c
serial: atmel: fix error path of probe function
tty: don't leak cdev in tty_cdev_add()
Revert "serial: imx: remove unbalanced clk_prepare"
Here are two tiny staging tree fixes for 4.3-rc5.
One fixes the broken speakup subsystem as reported by a user, and the
other removes an entry in the MAINTAINERS file for a developer that
doesn't want to be listed anymore.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYZOUkACgkQMUfUDdst+yk/wACgiCc+ChkU/WzC5eH+yACHOYwy
ouQAoNZgUZvmXQs9+X3VqTo/hAGa0/ru
=5fAh
-----END PGP SIGNATURE-----
Merge tag 'staging-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging fixes from Greg KH:
"Here are two tiny staging tree fixes for 4.3-rc5.
One fixes the broken speakup subsystem as reported by a user, and the
other removes an entry in the MAINTAINERS file for a developer that
doesn't want to be listed anymore"
* tag 'staging-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: speakup: fix speakup-r regression
MAINTAINERS: Remove myself as nvec co-maintainer
Here are some small fixes for some misc drivers that resolve some
reported issues. All of these have been linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlYZOecACgkQMUfUDdst+ykwmwCgpzrjwT0xxZRsDxk+ZeANvmlM
F+MAoJ0e+QZ0AeoADE9PjDgk5LHIUffH
=yAgG
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are some small fixes for some misc drivers that resolve some
reported issues. All of these have been linux-next for a while"
* tag 'char-misc-4.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mcb: Fix error handling in mcb_pci_probe()
mei: hbm: fix error in state check logic
nvmem: sunxi: Check for memory allocation failure
nvmem: core: Fix memory leak in nvmem_cell_write
nvmem: core: Handle shift bits in-place if cell->nbits is non-zero
nvmem: core: fix the out-of-range leak in read/write()
Pull MIPS fixes from Ralf Baechle:
- MIPS didn't define the new ioremap_uc. Defined it as an alias for
ioremap_uncached.
- Replace workaround for MIPS16 build issue with a correct one.
* git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Define ioremap_uc
MIPS: UAPI: Ignore __arch_swab{16,32,64} when using MIPS16
Revert "MIPS: UAPI: Fix unrecognized opcode WSBH/DSBH/DSHD when using MIPS16."
Pull swiotlb fixlet from Konrad Rzeszutek Wilk:
"Enable the SWIOTLB under 32-bit PAE kernels.
Nowadays most distros enable this due to CONFIG_HYPERVISOR|XEN=y which
select SWIOTLB. But for those that are not interested in
virtualization and wanting to use 32-bit PAE kernels and wanting to
have working DMA operations - this configures it for them"
* 'stable/for-linus-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb:
swiotlb: Enable it under x86 PAE
Leandro Awa writes:
"After switching to version 4.1.6, our parallelized and distributed
workflows now fail consistently with errors of the form:
T34: ./regex.c:39:22: error: config.h: No such file or directory
From our 'git bisect' testing, the following commit appears to be the
possible cause of the behavior we've been seeing: commit 766c4cbfac"
Al Viro says:
"What happens is that 766c4cbfac got the things subtly wrong.
We used to treat d_is_negative() after lookup_fast() as "fall with
ENOENT". That was wrong - checking ->d_flags outside of ->d_seq
protection is unreliable and failing with hard error on what should've
fallen back to non-RCU pathname resolution is a bug.
Unfortunately, we'd pulled the test too far up and ran afoul of
another kind of staleness. The dentry might have been absolutely
stable from the RCU point of view (and we might be on UP, etc), but
stale from the remote fs point of view. If ->d_revalidate() returns
"it's actually stale", dentry gets thrown away and the original code
wouldn't even have looked at its ->d_flags.
What we need is to check ->d_flags where 766c4cbfac does (prior to
->d_seq validation) but only use the result in cases where we do not
discard this dentry outright"
Reported-by: Leandro Awa <lawa@nvidia.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=104911
Fixes: 766c4cbfac ("namei: d_is_negative() should be checked...")
Tested-by: Leandro Awa <lawa@nvidia.com>
Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Removing barriers is scary, but a call to atomic_dec_and_test implies
a barrier, so we don't need to issue another one.
Signed-off-by: David Sterba <dsterba@suse.com>
waitqueue_active should be preceded by a barrier, in this function we
don't need to call it all the time.
Signed-off-by: David Sterba <dsterba@suse.com>
Normally the waitqueue_active would need a barrier, but this is not
necessary here because it's not a performance sensitive context and we
can call wake_up directly.
Suggested-by: Chris Mason <clm@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Now that the Demux kABI is documented at device-drivers.xml,
remove it from the API docbook.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
There are several stuff at media's kdapi.xml that don't
belong there, as it documents the Kernel internal ABI, and
not the userspace API.
Add the documentation here. The hole kdapi.xml will be
removed on a latter patch, after we finish documenting
what's there at the proper places.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
While we can't document #defines, documenting enums are
well supported by kernel-doc. So, convert the bitmap defines
into an enum.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The usage of #define at the kABI is fine, but it doesn't
allow adding a proper description. As those defines deserve
a proper documentation, let's convert them into an enum and
document them at device-drivers DocBook.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The dvb/kdapi.tmpl has already an extensive documentation about
this callback. Now that we've added function typedefs at kernel-doc,
add such documentation at demux.h, for it to appear at device-drivers
DocBook.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The dvb/kdapi.tmpl has already an extensive documentation about
this callback. Now that we've added function typedefs at kernel-doc,
add such documentation at demux.h, for it to appear at device-drivers
DocBook.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
A typedef function looks more likely a function and not a
normal typedef. Change the code to use the output_function_*,
in order to properly parse the function prototype parameters.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The current typedef parser only works for non-function typedefs.
As we need to also document some function typedefs, add a
parser for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
There are lots of CodingStyle violations here. Now that we're
touching a log on this header files, adding the documentation
here, make sure that this will follow the Kernel CodingStyle.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The requested bit rate can be outside the range supported by the driver.
The maximum bit rate this driver supports at the moment is 400Khz.
If the requested bit rate is larger than the maximum supported by the
driver, set the bitrate to the maximum supported before bitrate_khz is
calculated.
Maximum speed supported by the driver can be increased to 1Mhz by
adding support for "fast plus mode" in the future.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Clear line status and all generated interrupts from the interrupt
status register before starting a transfer, as we may have
unserviced interrupts from previous transfers that might be
handled in the context of the new transfer.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c->line_status accumulates the line status bits that have been seen
with each interrupt. As we're only interested in that bit from the
current interrupt, refer to line_status (the argument to img_i2c_auto)
instead of i2c->line_status.
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Currently, after determining the minimum value for the High period
(TCKH) the remainder of the internal clock pulses is set as the Low
period (TCKL). This causes the i2c clock duty cycle to be much less
than 50%.
Modify the starting position to TCKH and TCKL at 50% of the internal
clock, and adjusts the TCKH and TCKL values from there should the
minimum value for TCKL not be met. This results in duty cycles closer
to 50%.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Using % can be slow depending on the architecture.
Using DIV_ROUND_UP is nicer and more efficient way to do it.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Move scb_wr_rd_fence to before reading from fifo and writing to
fifo to make sure the the first read/write is done after the required
number of cycles.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The code to read from the master read fifo, and write to the master
write fifo, checks a bit in an SCB register before every byte to
ensure that the fifo is not full (write fifo) or empty (read fifo).
Due to clock domain crossing inside the SCB block the updated value
of this bit is only visible after 2 cycles.
The scb_wr_rd_fence() function does 2 dummy writes (to the read-only
revision register), and it's called before reading from or writing to the
fifos to ensure that subsequent reads of the fifo status bits do not read
stale values.
As the 2 dummy writes are required in all versions of the ip, the version
check is dropped.
Fixes: commit 27bce457d5 ("i2c: img-scb: Add Imagination Technologies I2C SCB driver")
Signed-off-by: Sifan Naeem <sifan.naeem@imgtec.com>
Acked-by: James Hogan <james.hogan@imgtec.com>
Reviewed-by: James Hartley <james.hartley@imgtec.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The header <panel.h> might be in /usr/include/ncursesw, which is not
part of the standard include path. This fixes compile on openSUSE.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
