The CX92755 is an SoC in the Conexant Digicolor series. The devicetree binding
document describes the I2C controller on the CX92755 SoC, that is also shared
by some other SoCs in the Digicolor series. The driver adds support.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[wsa: fixed spaces around operators]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Currently 'Playback Volume' is the correct way to express an analogue
volume control. However, this control name has initialisation defaults
applied when using 'alsactl restore' and in some cases this is not
appropriate. An example would be a control that has a selection of
0db and -6dB of gain that is intended to set the fullscale ouput
voltage of a DAC. The TI pcm512x family of DAcs have such a control.
In this case the device/driver reset defaults are preferred.
Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The AHB clock on sun5i and sun7i are muxable divider clocks.
Use a factors clock to support them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
NetCP 1.5 available on newer K2 SoCs such as K2E and K2L introduced 3
variants of the ethss subsystem, 9 port, 5 port and 2 port. These have
one host port towards the CPU and N external slave ports.
To customize the driver for these new ethss sub systems, multiple
compatibility strings are introduced. Currently some of parameters that
are different on different variants such as number of ALE ports, stats
modules and number of ports are defined through constants. These are now
changed to variables in gbe_priv data that get set based on the
compatibility string. This is required as there are no hardware
identification registers available to distinguish among the variants
of NetCP 1.5 ethss. However there is identification register available
to differentiate between NetCP 1.4 vs NetCP 1.5 and the same is made use
of in the code to differentiate them.
For more reading on the details of this peripheral, please refer to the
User Guide available at http://www.ti.com/lit/pdf/spruhz3
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Mugunthan V N <mugunthanvnm@ti.com>
CC: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
CC: Grygorii Strashko <grygorii.strashko@ti.com>
CC: Christoph Jaeger <cj@linux.com>
CC: Lokesh Vutla <lokeshvutla@ti.com>
CC: Markus Pargmann <mpa@pengutronix.de>
CC: Kumar Gala <galak@codeaurora.org>
CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Rob Herring <robh+dt@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Conflicts:
drivers/net/ethernet/emulex/benet/be_main.c
net/core/sysctl_net_core.c
net/ipv4/inet_diag.c
The be_main.c conflict resolution was really tricky. The conflict
hunks generated by GIT were very unhelpful, to say the least. It
split functions in half and moved them around, when the real actual
conflict only existed solely inside of one function, that being
be_map_pci_bars().
So instead, to resolve this, I checked out be_main.c from the top
of net-next, then I applied the be_main.c changes from 'net' since
the last time I merged. And this worked beautifully.
The inet_diag.c and sysctl_net_core.c conflicts were simple
overlapping changes, and were easily to resolve.
Signed-off-by: David S. Miller <davem@davemloft.net>
David suggested that the name "power_mgmt" is too ambiguous. Rename
the flag with a bit clearer one "power_save_node".
Also, add the corresponding description to HD-Audio.txt, too.
Reported-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently there are only two "tools" that can be specified by a multi-touch
driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch
vendor) and discussing their next-gen devices it seems that it will be
useful to have more tools so that their devices can give the upper layers
of the stack hints as to what is touching the sensor.
In particular they have new experimental firmware that can better
differentiate between palms vs fingertips and would like to plumb a patch
so that we can use their hints in higher-level gesture soft- ware. The
firmware on the device can reasonably do a better job of palm detection
because it has access to all of the raw sensor readings as opposed to just
the width/pressure/etc that are exposed by the driver. As such, the
firmware can characterize what a palm looks like in much finer-grained
detail and this change would allow such a device to share its findings with
the kernel.
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This patch fix spelling typo in Documentation/PCI.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The documentation is trying to describe accessing a field through a
pointer, but it is using '-<' instead of '->'. Fix that.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Remove mentioning of block barriers since they were removed.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Leonid V. Fedorenchik <leonidsbox@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Fix one grammar mistake (Allows->Allow) and add extra information about
the external editor add-on of Thunderbird: the developer must make sure
that their editor doesn't fork (IOW it mustn't return before closing)
thus they should be careful how they configure the addon. Furthermore,
add a tip how to do it with gvim.
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
[jc: some minor wording/formatting tweaks]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The patch 125e564("Move Kconfig.instrumentation to arch/Kconfig and
init/Kconfig") had removed the "Instrumentation Support" menu,
and the configurations under this had be moved to "General setup".
Update Documentation/kprobes.txt to reflect this change.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
We can remove the i2o documentation because a) the subsystem has been
moved to staging with commit 2cbf7fe2d5 (i2o: move to staging)
anyhow and b) the here removed files are present in the subsystem
directory again. There, README even has an additional paragraph and the
ioctl docs only differ in whitespaces. Well...
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The CONFIG_DEBUG_PAGEALLOC option now is located under "Kernel
hacking" / "Memory Debugging" / "Debug page memory allocations".
so we should update the description in kmemcheck.txt.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Fix a trivial typo in Documentation/memory-hotplug.txt.
Signed-off-by: Sheng Yong <shengyong1@huawei.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The documentation and the code disagrees; fix the former.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The IRQF_DISABLED is a NOOP and scheduled to be removed. According to Ingo
Molnar in commit e58aa3d2d0 (genirq: Run irq
handlers with interrupts disabled), running IRQ handlers with interrupts
enabled can cause stack overflows when the interrupt line of the issuing
device is still active.
This patch removes IRQF_DISABLED from this documentation. It was
mentioned to be a solution to avoid deadlocks when a device uses
multiple interrupts. As the flag is a NOOP this solution does not work
anymore.
Signed-off-by: Valentin Rothberg <Valentin.Rothberg@lip6.fr>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
max_ptes_none specifies how many extra small pages (that are
not already mapped) can be allocated when collapsing a group
of small pages into one large page.
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
A higher value leads to use additional memory for programs.
A lower value leads to gain less thp performance. Value of
max_ptes_none can waste cpu time very little, you can
ignore it.
Signed-off-by: Ebru Akagunduz <ebru.akagunduz@gmail.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
as the commit: "lib/vsprintf: implement bitmap printing through
'%*pb[l]'" add an easy way to print bitmaps. so printk-formats.txt
should reflect it.
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
And remove one bogus * from i915_gem_gtt.c since that's not a
kerneldoc there.
v2: Review from Chris:
- Clarify memory space to better distinguish from address space.
- Add note that shrink doesn't guarantee the freed memory and that
users must fall back to shrink_all.
- Explain how pinning ties in with eviction/shrinker.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge because of numerous and interleaving conflicts and git
rerere getting confused a bit too often.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
All conflicts are because of -next patches backported to -fixes, so
just go with the code in -next.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Johan Hedberg says:
====================
pull request: bluetooth-next 2015-03-19
This wont the last 4.1 bluetooth-next pull request, but we've piled up
enough patches in less than a week that I wanted to save you from a
single huge "last-minute" pull somewhere closer to the merge window.
The main changes are:
- Simultaneous LE & BR/EDR discovery support for HW that can do it
- Complete LE OOB pairing support
- More fine-grained mgmt-command access control (normal user can now do
harmless read-only operations).
- Added RF power amplifier support in cc2520 ieee802154 driver
- Some cleanups/fixes in ieee802154 code
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Document the subtly changed relationship between cpusets and isolcpus.
Turns out the old documentation did not match the code...
Signed-off-by: Rik van Riel <riel@redhat.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Zefan Li <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Similar to port id allow netdevices to specify port names and export
the name via sysfs. Drivers can implement the netdevice operation to
assist udev in having sane default names for the devices using the
rule:
$ cat /etc/udev/rules.d/80-net-setup-link.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{phys_port_name}!="",
NAME="$attr{phys_port_name}"
Use of phys_name versus phys_id was suggested-by Jiri Pirko.
Signed-off-by: David Ahern <dsahern@gmail.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds a tx_maxrate attribute to the tx queue sysfs entry allowing
for max-rate limiting. Along with DCB-ETS and BQL this provides another
knob to tune queue performance. The limit units are Mbps.
By default it is disabled. To disable the rate limitation after it
has been set for a queue, it should be set to zero.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The TI CC2521 is an RF power amplifier that is designed to interface
with the CC2520. Conveniently, it directly interfaces with the CC2520
and does not require any pins to be connected to a
microcontroller/processor. Adding a CC2591 increases the CC2520's range,
which is useful for border router and other wall-powered applications.
Using the CC2591 with the CC2520 requires configuring the CC2520 GPIOs
that are connected to the CC2591 to correctly set the CC2591 into TX and
RX modes. Further, TI recommends that the CC2520_TXPOWER and
CC2520_AGCCTRL1 registers are set differently to maximize the CC2591's
performance. These settings are covered in TI Application Note AN065.
This patch adds an optional `amplified` field to the cc2520 entry in the
device tree. If present, the CC2520 will be configured to operate with a
CC2591.
The expected pin mapping is:
CC2520 GPIO0 --> CC2591 EN
CC2520 GPIO5 --> CC2591 PAEN
Signed-off-by: Brad Campbell <bradjc5@gmail.com>
Acked-by: Varka Bhadram <varkabhadram@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
pinconf_generic_dt_node_to_map() scans only subnodes of the pinctrl-0 pahndle,
not the referenced node itself. Change the example nodes to match.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Renesas R-Car sound (= rsnd) needs 2 DMAC which are called as
Audio DMAC (= 1st DMAC) and Audio DMAC peri peri (2nd DMAC).
And rsnd had assumed that 1st / 2nd DMACs are implemented as DMAEngine.
But, in result of DMA ML discussion, 2nd DMAC was concluded that it is
not a general purpose DMAC (2nd DMAC is for Device to Device inside
sound system). Additionally, current DMAEngine can't support Device to
Device, and we don't have correct DT bindings for it at this point.
So the easiest solution for it is that move it from DMAEngine to rsnd
driver.
Audio DMAC peri peri on DMAEngine is no longer needed. remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Make sure that the ACPI enumeration.txt provides latest information on how
to describe and retrieve GPIOs now that we can take advantage of _DSD
device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the example code consistent wrt local function and struct definitions.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This API has changed in commit 6e5e959dde (pinctrl: API changes to support
multiple states per device).
Fixes: 6e5e959dde ('pinctrl: API changes to support multiple states per device')
Cc: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 03e9f0cac5 (pinctrl: clean up after enable refactoring) updated the
documentation to remove mention of disable(), and rename enable() to set_mux().
One in-text mention was forgotten. Fix this.
Fixes: 03e9f0cac5 ('pinctrl: clean up after enable refactoring')
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Scorpion supports a set of local performance monitor event
selection registers (LPM) sitting behind a cp15 based interface
that extend the architected PMU events to include Scorpion CPU
and Venum VFP specific events. To use these events the user is
expected to program the lpm register with the event code shifted
into the group they care about and then point the PMNx event at
that region+group combo by writing a LPMn_GROUPx event. Add
support for this hardware.
Note: the raw event number is a pure software construct that
allows us to map the multi-dimensional number space of regions,
groups, and event codes into a flat event number space suitable
for use by the perf framework.
This is based on code originally written by Sheetal Sahasrabudhe,
Ashwin Chaugule, and Neil Leeder [1].
[1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm.c?h=msm-3.4
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Neil Leeder <nleeder@codeaurora.org>
Cc: Ashwin Chaugule <ashwinc@codeaurora.org>
Cc: Sheetal Sahasrabudhe <sheetals@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
