This patch adds a register cache to the bq27x00 battery driver.
Usually multiple, if not all, power_supply properties are queried at once,
for example when an uevent is generated. Since some registers are used by
multiple properties caching the registers should reduce the number of
reads.
The cache is valid for 5 seconds this roughly matches the internal update
interval of the current register for the bq27000/bq27200.
Fast changing properties(*_NOW) which can be obtained by reading a single
register are not cached.
It will also be used in the follow up patch to check if the battery status
has been changed since the last update to emit power_supply_changed events.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
This patch adds support for the bq27000 battery to the bq27x00 driver.
The bq27000 is similar to the bq27200 except that it uses the HDQ bus
instead of I2C to communicate with the host system.
The driver is implemented as a platform driver. The driver expects to be
provided with a read callback function through its platform data. The read
function is assumed to do the lowlevel HDQ handling and read out the value
of a certain register.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
This patch simplifies the drivers data structure and moves code to be
shared by the bq27000 and bq27200/bq27500 init functions into a common
function.
This patch has no functional changes, it only moves code around.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
This patch changes get_property callback of the bq27x00 battery to return
-ENODEV for properties other then the PROP_PRESENT if the battery is not
present.
The power subsystem core expects a driver to behave that way.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
According to the bq27000 datasheet the current should be calculated by
the following formula:
current = AI * 3570 / 20
This patch adjust the drivers code accordingly.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
This patch improves the precession of the temperature property of the
bq27x00 driver.
By dividing before multiplying the current code effectively cuts of the
last decimal digit. This patch fixes it by multiplying before dividing.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
This patch adds the type property to the bq27x00 battery driver.
All bq27x00 are lithium ion batteries.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Rodolfo Giometti <giometti@linux.it>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Calling device_add causes an inital uevent for that device to be generated.
The power_supply uevent function calls the drivers get_property function,
which might causes the driver to update its state, which again might
causes the driver to call power_supply_changed(). Since the power_supplys
changed_work has not been initialized at this point the behavior is
undefined and can result in an OOPS.
This patch fixes the issue by initializing the power_supplys changed_work
prior to adding the power_supplys device to the device tree.
Reported-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Sometimes a driver can not report a meaningful value for a certain property
and returns -ENODATA.
Currently when generating a uevent and a property return -ENODATA it is
treated as an error an no uevent is generated at all. This is not an
desirable behavior.
This patch adds a special case for -ENODATA and ignores properties which
return this error code when generating the uevent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Add new trigger to power_supply LEDs. It will blink when battery is
charging, and stay solid when battery is charged. It's usefull to
indicate battery state when there's only one LED available.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
As blink API is now available, it's possible to add ability to blink via
simple trigger.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Adding support for charge properties for gas gauge.
Also ensuring that battery mode is correct now for energy as well as
charge properties by setting it on the fly.
I also added 2 functions to power_supply.h to help identify the units for
specific properties more easily by power supplies.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Fix error test in fan_{read,write}_reg()
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
It turns out that some device drivers map pages from the ACPI NVS region
during resume using ioremap(), which conflicts with ioremap_cache() used
for mapping those pages by the NVS save/restore code in nvs.c.
Make the NVS pages mapped by the code in nvs.c be unmapped before device
drivers' resume routines run.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit ca9b600be3 ("ACPI / PM: Make suspend_nvs_save() use
acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c
from using different ioremap() variants by making the latter use
acpi_os_map_memory() for mapping the NVS pages. However, that also
requires acpi_os_unmap_memory() to be used for unmapping them, which
causes synchronize_rcu() to be executed many times in a row
unnecessarily and introduces substantial delays during resume on some
systems.
Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c
introduce acpi_os_ioremap() calling ioremap_cache() and make the code in
both osl.c and nvs.c use it.
Reported-by: Jeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix collision with kernel-supplied #define:
drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined
arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Replicate changes made to drivers/leds/ledtrig-backlight.c.
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.
This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel. A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).
Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Acked-by: David Woodhouse <david.woodhouse@intel.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During system suspend, the "wait for ring buffer to empty" loop would
always time out after three seconds, because the faster cached ring
buffer head read would always return zero. Force the slow-and-careful
PIO read on all but the first iterations of the loop to fix it.
This also removes the unused (and useless) 'actual_head' variable that
tried to approximate doing this, but did it incorrectly.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: DRI mailing list <dri-devel@lists.freedesktop.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
thanks to Clemens' and Maxim's fixes to firewire-ohci and -net in the
last two kernel releases.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This makes it possible to resume communication with a node that dropped
off the bus for a brief period. Otherwise communication will only be
possible after ARP cache entry timeouts.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (rebased)
Regression since commit 1038953674, "firewire: core: check for 1394a
compliant IRM, fix inaccessibility of Sony camcorder":
The camcorder Canon MV5i generates lots of bus resets when asynchronous
requests are sent to it (e.g. Config ROM read requests or FCP Command
write requests) if the camcorder is not root node. This causes drop-
outs in videos or makes the camcorder entirely inaccessible.
https://bugzilla.redhat.com/show_bug.cgi?id=633260
Fix this by allowing any Canon device, even if it is a pre-1394a IRM
like MV5i are, to remain root node (if it is at least Cycle Master
capable). With the FireWire controller cards that I tested, MV5i always
becomes root node when plugged in and left to its own devices.
Reported-by: Ralf Lange
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org> # 2.6.32.y and newer
This partially reverts commit da8aeb92d4
("ACPI / Battery: Update information on info notification and resume"),
which causes a hang on resume on at least some machines.
This bug was bisected on an ASUS EeePC 901, which hangs at resume time
if we do that "acpi_battery_refresh(battery)" in the battery resume
function.
Rafael suspects we'll still need to refresh the sysfs files upon resume,
but that that can be done from a PM notifier (that will run after
thawing user space).
Bisected-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Len Brown <len.brown@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We sometimes need to map between the virtio device and
the given pci device. One such use is OS installer that
gets the boot pci device from BIOS and needs to
find the relevant block device. Since it can't,
installation fails.
Instead of creating a top-level devices/virtio-pci
directory, create each device under the corresponding
pci device node. Symlinks to all virtio-pci
devices can be found under the pci driver link in
bus/pci/drivers/virtio-pci/devices, and all virtio
devices under drivers/bus/virtio/devices.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Gleb Natapov <gleb@redhat.com>
Tested-by: "Daniel P. Berrange" <berrange@redhat.com>
Cc: stable@kernel.org
arch/x86/lguest/boot.c: In function ‘lguest_init_IRQ’:
arch/x86/lguest/boot.c:824: error: macro "__this_cpu_write" requires 2 arguments, but only 1 given
arch/x86/lguest/boot.c:824: error: ‘__this_cpu_write’ undeclared (first use in this function)
arch/x86/lguest/boot.c:824: error: (Each undeclared identifier is reported only once
arch/x86/lguest/boot.c:824: error: for each function it appears in.)
drivers/lguest/x86/core.c: In function ‘copy_in_guest_info’:
drivers/lguest/x86/core.c:94: error: lvalue required as left operand of assignment
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When the lirc drivers were converted over to using memdup_user, I
mistakenly also removed corresponding calls to kfree. Add those back. I
also screwed up on the allocation error check in lirc_serial, using if
(PTR_ERR()) instead of if (IS_ERR()), which broke transmit.
Reported-by: Jiri Fojtasek <jiri.fojtasek@hlohovec.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current hdpvr code kmalloc's a new buffer for every i2c read and
write. Rather than do that, lets allocate a buffer in the driver's
device struct and just use that every time.
The size I've chosen for the buffer is the maximum size I could
ascertain might be used by either ir-kbd-i2c or lirc_zilog, plus a bit
of padding (lirc_zilog may use up to 100 bytes on tx, rounded that up
to 128).
Note that this might also remedy user reports of very sluggish behavior
of IR receive with hdpvr hardware.
v2: make sure (len <= (dev->i2c_buf)) [Jean Delvare]
Reported-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A number of things going on here, but the end result is that the IR part
on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
lirc_zilog.
First up, there are some conditional build fixes that come into play
whether i2c is built-in or modular. Second, we're swapping out
i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
always fails, but we *know* that all hdpvr devices have a z8 chip at
0x70 and 0x71. Third, we're poking at an i2c address directly without a
client, and writing some magic bits to actually turn on this IR part
(this could use some improvement in the future). Fourth, some of the
i2c_adapter storage has been reworked, as the existing implementation
used to lead to an oops following i2c changes c. 2.6.31.
Earlier editions of this patch have been floating around the 'net for a
while, including being patched into Fedora kernels, and they *do* work.
This specific version isn't yet tested, beyond loading ir-kbd-i2c and
confirming that it does bind to the RX address of the hdpvr.
[mchehab@redhat.com: I2C_CLASS_TV_ANALOG is not defined. Fix compilation bug]
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes an egregious bug in mceusb driver, where the receiver was being
put into idle mode far sooner than it should have, thanks to storing a
timeout value that in us where it should be ns. Basically, the receiver
kept going into idle mode before a trailing space had been fully
received, which was causing problems for some protocols, most notably
manifesting as lirc userspace never receiving a trailing space for any
rc5 signals.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a bug in v4l2_device_unregister where the sd pointer can be dereferenced
after it was freed.
Normally the i2c adapter is removed before this function is called. Removing
the adapter will also unregister all subdevs on that adapter, so generally
v4l2_device_unregister has nothing to do. However, in the case of a platform
i2c bus that bus is generally not freed.
In that case, after freeing the i2c subdevice the code will fall into the
second block when it tests if the subdev is a SPI device. But by that time
the subdev is already freed and the kernel oopses.
The fix is trivial: continue with the loop after freeing the i2c or spi
subdevice.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Reported-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Zeroing video_device.dev causes a memory leak if video_set_drvdata
was called before video_register_device was called. video_set_drvdata
calls dev_set_drvdata which allocates video_device.dev.p.
memsetting this will prevent freeing of that memory.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After a detach zero the whole device state to ensure a clean slate
on the next attach.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2_queryctrl sets the step value based on the control type. That would
be fine if it used the control type stored in the V4L2 kernel control
object, not the one stored in the userspace ioctl structure that has
just been memset to 0. Fix this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When queryctrl is called with a V4L2_CID_PRIVATE_BASE control ID, then
currently it is replaced by the real internal ID. This is not according to
the spec so keep the V4L2_CID_PRIVATE_BASE ID in this case.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
VIDIOC_S_CTRL did not check against read-only controls. Even worse, for
controls of type CTRL_CLASS it would cause a kernel oops since those controls
do not have a s_ctrl op.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts a portion of commit
44243fc2ef
A commit for which I errantly recommended that defaults for I2C address
0x71 not be set by ir-kbd-i2c.c
The pvrusb2 and bttv drivers currently rely on ir-kbd-i2c setting
defaults for that address. Until I can get those bridge drivers fixed
to properly send IR_i2c_init_data for boards with Zilog Z8 chips,
just add back the default settings for I2C address 0x71.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir_command() function is a do-nothing stub; remove it.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver is now structured so that it must handle an IR Tx unit
for a Z8 IR chip, or it refuses to handle that Z8 IR chip. This
allows us to assume that ir->tx != NULL in a few places in the driver,
and also allows us to always report Tx is available to userspace.
Get rid of unneeded tests for ir->tx == NULL and always report that
Tx is available.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The IR Rx polling thread was originally a kernel_thread long ago,
and had only been minimally converted to a kthread. This patch
finishes that conversion by
- cleaning up all the unneeded completions
- destroying the kthread properly by calling kthread_stop()
- changing lirc_thread() to test kthread_should_stop() just before
every point where it may sleep
- reorganizing the lirc_thread() function so it uses fewer lines
- modifying the name of the kthread from "lirc_zilog" to
"zilog-rx-i2c-N", so ps will show which kthread polls
which Zilog Z8 IR unit.
Also some minor tweaks were made to logging emitted by the
ir_probe() function.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is an extensive rework of the ir_probe() and ir_remove() functions.
It removes all the double binding and allocation problems on module load.
It removes almost all the memory leaks on module exit and on device
instantiation failure. Proper destruction of the Rx polling kthread still
needs investigation and more work, but it is no worse than it already was.
This rework also had side effects that include:
- encapsulation of the ir_devices[] array
- serialization of access to the ir_devices[] array
- semantic change of the module parameter "disable_rx" to "tx_only"
If tx_only is true, the module does not claim the i2c_client for the IR Rx
function, and only claims and handles the i2c_client for the IR Tx function.
This is a first step in providing the option of letting ir-kbd-i2c.c handle
IR Rx function, while lirc_zilog handles the IR Tx function.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't make private copies of the i2c clients provided by the I2C
subsystem, don't change the client address field, and don't probe
the client addresses - the bridge driver already did that. This
moves us to the proper I2C and binding model.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change is a mostly mechanical break of the main struct IR
data structure into common, Rx, and Tx structures. There were some
small logical changes required as well, such as eliminating "is_hdpvr",
to accomplish this.
This change is an intiial step in reworking lirc_zilog to decouple the
Rx and Tx handling as much as possible to fit with the new I2C
binding model. This change actually makes lirc_zilog a little more
broken than it already was - memory deallocation in particular got worse.
However, this change makes the remaining problems easier to see and address.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The only reason to use the lirc_zilog module is for IR Tx, so remove
the possibility of disabling IR Tx. If the user needs only IR Rx,
then the ir-kbd-i2c module works just fine, and doesn't require a
"firmware" image.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare <khali@linux-fr.org> suggested this better
format for debug output in ir_probe().
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After a recent update of xf86-input-evdev and xorg-server, I noticed
that X11 applications did not receive keypresses from the FireDTV
infrared remote control anymore. Instead, the Xorg log featured lots of
"FireDTV remote control: dropping event due to full queue!"
exclamations. The Linux console did not have an issue with the
FireDTV's RC though.
The fix is to insert EV_SYN events after the key-down/-up events.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Lars-Peter Clausen