Just a couple of things I came across whilst reviewing this file for
moving out of staging. I doubt anyone cares, but seemed sensible to fix
them now!
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These two attributes are only used in the one driver. Whilst they
are fairly general I'm not entirely happy committing to them at
this stage.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is one device supported by the driver which is not listed in the Kconfig
help test. This patch adds it. Also we are past the point were we can possible
fit all devices supported by the driver in the Kconfig entry title, so just list
the initial device that was supported by this driver and note that similar
devices are supported as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The AD5662 is compatible to the AD5660, but uses an external
reference instead of an internal.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We can not read back the value from the device, but we cache the value anyway so
we might as well return the cached value instead of an error.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The devices supported by this drivers only have a single shift register, which
contains both the power down mode and the output sample. So writing the power
down mode and the output sample can be done by the same function. Call this
function prepare_write as it will prepare the spi message for a write. Also
introduce a small helper function which performs the whole write by calling the
chip the specific prepare function followed by a spi_sync.
The two power down bits are always placed ontop of the msb of the output sample,
so we can easily calculate their position by adding the channels shift to the
channels realbits.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use extended channel attributes instead of raw sysfs files for the additional
channel attributes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are three identical chip_info entries. Remove two of them and use the id
of the remaining entry for all three device table entries.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the chip_info's int_vref_mv field to decide whether a certain chip has a
internal reference or not. There is no need to check for individual chip ids.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We currently only write 16 bit in case where we should write 24 bit. The spi message
length is calculated from the channel storage_size, but since the storage size
is only 16 bit we end up with the wrong value for devices which have power down
bits and thus a register with 24 bit. Since each store function knows how many
bytes it has to write just use the spi_write function from there instead of
going through the hassle of manually preparing a spi_message and keeping buffers
in the state struct.
Another advantage of this patch is that it will make implementing support for
similar I2C based DACs much easier.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AD5620_LOAD and AD5446_LOAD are both 0, so all these three functions are
identical and we can replace them with only one.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both the powerdown mode bits and the sample value are stored in the same
register, so writing a sample while the device is powered down will clear the
power down bits. To avoid this only update the cached value when the device is
powered down.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@kernel.org>
----
v1 actually had a small bug in that it would still write to the device's
register when the sample was updated while the device was powered down. This was
not critical since it would send out the powerdown mode again.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 026cee0086 had the side-effect of dropping the '=' from
the unknown boot arguments that are passed to init as environment
variables. This is because parse_args() puts a NUL in the string
where the '=' was when it passes the "param" and "val" pointers
to the parsing subfunctions. Previously, unknown_bootoption() was
the last parse_args() subfunction to run, and it carefully put back
the '=' character. Now the ignore_unknown_bootoption() is the last
one to run, and it wasn't doing the necessary repair, so the
envp params ended up with the embedded NUL and were no longer
seen as valid environment variables by init.
Tested-by: Woody Suwalski <terraluna977@gmail.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
- Add necessary #ifdefs for CONFIG_COMMON_CLOCK
- Add a global spinlock to protect the CCM registers
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Instead of having a cpu_is_* in each ccm register access it
is more efficient to make it a variable.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
We used to pass the timer clock directly to mxc_timer_init. We
should instead request the correct clock. This is an intermediate
step: For now we request the clock in the timer code when NULL
is passed as clock.
Also, the gpt on some i.MX have an additional ipg clock which can
be gated. Request and enable this.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Every i.MX ehci controller has a ahb and a ipg clock, so request
it on every SoC. Do not make a special case for the usb phy clock
of the i.MX51. Just request it but make it optional.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
the current i.MX clock support groups together unrelated clocks
to a single clock which is then used by the driver. This can't
be accomplished with the generic clock framework so we instead
request the individual clocks in the driver. For i.MX there are
generally three different clocks:
ipg: bus clock (needed to access registers)
ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
per: bit clock, pixel clock
This patch changes the driver to request the individual clocks.
Currently all clk_get will get the same clock until the SoCs
are converted to the generic clock framework
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reorder structure writeback_control to remove 8 bytes of padding on 64
bit builds, this shrinks its size from 48 to 40 bytes.
This structure is always on the stack and uses C99 named initialisation,
so should be safe and have a small impact on stack usage.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
In 3872c48b (tick: Document TICK_ONESHOT config option) Thomas describes
the circumstances under which TICK_ONESHOT should be selected. This is
an internal time keeping configuration symbol which should not be
selected by platform or arch code. So remove our select statements for
it.
This kills these warnings in OMAP builds:
kernel/time/tick-sched.c:47: warning: 'tick_do_update_jiffies64' defined but not used
kernel/time/tick-sched.c:89: warning: 'tick_init_jiffy_update' defined but not used
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
