Add simple-panel support for the Sharp LQ101K1LY04, which is a 10"
WXGA (1280x800) LVDS panel.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The LG LP079QX1-SP0V is an 7.9" QXGA TFT with LED Backlight unit and
32 pins eDP interface. This module supports 1536x2048 mode.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Sharp LQ123P1JX31 is an 12.3", 2400x1600 TFT-LCD panel connected
using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Sharp LQ123P1JX31 is an 12.3" 2400x1600 TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD
panel connected using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some backlight drivers ignore the power property and instead only use
the state property. Fixup the panel driver to set the state property in
addition to the power property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
When disabling a PWM channel, the PWM clock was being stopped
immediately after writing to PWM_DIS. As a result, the disabling
of the PWM channel did not complete properly, and the PWM output
might be left at the wrong level.
Fix this by waiting for the channel to be effectively disabled
(by checking the PWM_SR register) before disabling the clock.
Signed-off-by: Guillermo Rodriguez <guille.rodriguez@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add device tree bindings for the PWM controller found on R-Car H3 SoCs.
The controller is compatible with the one found in earlier generations
of R-Car SoCs.
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra186 has multiple PWM controllers with only one output instead of
one controller with four outputs in earlier SoC generations.
Add support for Tegra186 and detect the number of PWM outputs using
device tree match data.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Tegra186 has 8 different PWM controllers and each controller has only
one output. Earlier SoC generations have 4 PWM outputs per controller.
Add a device tree compatible string for Tegra186 to be able to
differentiate between the two.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
duty_ns * (1 << PWM_DUTY_WIDTH) could overflow in integer calculation
when the PWM rate is low. Hence do all calculation on unsigned long long
to avoid overflow.
Signed-off-by: Hyong Bin Kim <hyongbink@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To get 100 % duty cycle (always high), pulse width needs to be set to
256.
Signed-off-by: Victor(Weiguo) Pan <wpan@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add reset control of the PWM controller to reset it before
accessing the PWM register.
Signed-off-by: Rohith Seelaboyina <rseelaboyina@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The former is much longer to type and is ambiguous because the value
stored in the field is not the (physical) base address of the memory-
mapped I/O registers, but the virtual address of those registers as
mapped through the MMU.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This macro is used to initialize the ->npwm field of the PWM chip. Use a
literal instead and make all other places rely on ->npwm.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM_PIN_LEVEL bit is leave unset by the kernel PWM driver.
Prior to commit 08ee77b5a5,
the PWM_PIN_LEVEL bit was always clear when the PWM was disable
and a 0 logic level was apply to the output.
According to the LPC32x0 User Manual [1],
the default value for bit 30 (PWM_PIN_LEVEL) is 0.
This change initialize the pin level to 0 (default value) and
update the register value accordingly.
[1] http://www.nxp.com/documents/user_manual/UM10326.pdf
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This adds a driver for the PWM block found in chips of the STMPE 24xx
series of multi-purpose I2C expanders. (I think STMPE means ST
Microelectronics Multi-Purpose Expander.) This PWM was designed in
accordance with Nokia specifications and is kind of weird and usually
just switched between max and zero duty cycle. However it is indeed a
PWM so it needs to live in the PWM subsystem.
This PWM is mostly used for white LED backlight.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This adds fairly standard device tree bindings for the STMPE PWM found
in STMPE24xx multi-purpose expanders.
Cc: devicetree@vger.kernel.org
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->apply() function to add support for atomic update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Implement the ->get_state() function to expose initial state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.
These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.
Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:
pwm_apply_state(): register = period * 112666667 / 1000000000;
pwm_get_state(): period = register * 1000000000 / 112666667;
or in other words:
period = period * 112666667 / 1000000000 * 1000000000 / 112666667;
which yields a sequence like:
3333 -> 3328
3328 -> 3319
3319 -> 3310
3310 -> 3301
3301 -> 3292
3292 -> ... (etc) ...
With this patch, we'd see instead:
period = div_round_closest(period * 112666667, 1000000000) *
1000000000 / 112666667;
which yields a stable sequence:
3333 -> 3337
3337 -> 3337
3337 -> ... (etc) ...
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Add support for the PWM controller present in Broadcom's iProc family of
SoCs. It has been tested on the Northstar+ bcm958625HR board.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
[thierry.reding@gmail.com: bunch of coding style fixes, cleanups]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is no need to check each time if the clk_rate defined or not when we call
pwm_lpss_config(). Move the check to ->probe() instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch corrects an off-by-one error in the DecodeQ931 function in
the nf_conntrack_h323 module. This error could result in reading off
the end of a Q.931 frame.
Signed-off-by: Toby DiPasquale <toby@cbcg.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Simon Horman says:
====================
IPVS Updates for v4.8
please consider these enhancements to the IPVS. This alters the behaviour
of the "least connection" schedulers such that pre-established connections
are included in the active connection count. This avoids overloading
servers when a large number of new connections arrive in a short space of
time - e.g. when clients reconnect after a node or network failure.
====================
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
We can pass the netns pointer as parameter to the functions that need to
gain access to it. From basechains, I didn't find any client for this
field anymore so let's remove this too.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
If we want to use ct packets expr, and add a rule like follows:
# nft add rule filter input ct packets gt 1 counter
We will find that no packets will hit it, because
nf_conntrack_acct is disabled by default. So It will
not work until we enable it manually via
"echo 1 > /proc/sys/net/netfilter/nf_conntrack_acct".
This is not friendly, so like xt_connbytes do, if the user
want to use ct byte/packet expr, enable nf_conntrack_acct
automatically.
Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
physdev_mt() will check skb->nf_bridge first, which was alloced in
br_nf_pre_routing. So if we want to use --physdev-out and physdev-is-out,
we need to match it in FORWARD or POSTROUTING chain. physdev_mt_check()
only checked physdev-out and missed physdev-is-out. Fix it and update the
debug message to make it clearer.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Marcelo R Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The function is called by both 32-bit and 64-bit early setup right
after early_init_devtree(). All it does is run yet another early
DT parser which is precisely what early_init_devtree() is about,
so move it in there.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Anything in early_setup() needs to be justified to be there, in
this case, we need the trampolines before we can take exceptions
and thus before we turn on the MMU.
Also remove a pretty meaningless and misplaced debug message
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Fix comment formatting]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
early_init() is called in-place before kernel relocation and using
whatever MMU setup exists at the point the kernel is entered.
machine_init() is called after relocation and after some initial
mapping of PAGE_OFFSET has been established (typically using BATs
on 6xx/7xx/7xxx processors or some form of bolted TLB on others).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
It did use a fixed-size bucket list plus single lock to protect add/del.
Unlike the main conntrack table we only need to add and remove keys.
Convert it to rhashtable to get table autosizing and per-bucket locking.
The maximum number of entries is -- as before -- tied to the number of
conntracks so we do not need another upperlimit.
The change does not handle rhashtable_remove_fast error, only possible
"error" is -ENOENT, and that is something that can happen legitimetely,
e.g. because nat module was inserted at a later time and no src manip
took place yet.
Tested with http-client-benchmark + httpterm with DNAT and SNAT rules
in place.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Intel Edison has 4 PWM channels on the die with the same IP as in
Broxton. Enable it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
If duty_ns is large enough multiplying it by 255 overflows and results
wrong duty cycle value being programmed. For example with 10ms duty when
period is 20ms (50%) we get
255 * 10000000 / 20000000 = -87
because 255 * 10000000 overlows int. Whereas correct value should be
255 * 10000000 / 20000000 = 127
Fix this by using unsigned long long as type for on_time_div and changing
integer literals to use proper type annotation.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The base_unit calculation applies an offset of 0x2 which adds
significant error for lower frequencies and doesn't appear to be
warranted - rounding the division result gives a correct value.
Also, the upper limit check for base_unit is off-by-one; the upper
nibble of base_unit is invalid if >=128 according to the Table 88
in the Z8000 Processor Series Datasheet Volume 1 (Rev. 2).
Verified on UP Board (Cherry Trail) and Minnowboard Max (Bay Trail).
Signed-off-by: Dan O'Donovan <dan@emutex.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.
Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
There is not need to drop leading zeros from the RSA output
operations results.
Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
