* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Mark Brown @ 2014-02-05 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJAp7OjB-cJbLpdWo0RFJZefCKcCiKc8KgrjkBobJnddv4MSWA@mail.gmail.com>
On Wed, Feb 05, 2014 at 10:00:15AM -0800, Bjorn Andersson wrote:
> On Tue, Feb 4, 2014 at 12:00 PM, Mark Brown <broonie@kernel.org> wrote:
> > So we should be changing the code to allow a set_voltage() that sets the
> > voltage to the existing voltage regardless of constraints allowing a
> > change then - that's what the underlying issue is. Your change wouldn't
> > cover the case where the hardware defualt is being used for example.
> Makes sense, but the only thing we could check for would be if min_uV
> == max_uV == current-voltage. That would work out fine for this use
> case, but do you think it would be good enough?
It should be fine to check for min_uV <= current-voltage <= max_uV
instead if CHANGE_VOLTAGE isn't available, so long as the existing
setting is in the range it's fine.
> The best thing I've come up with then is to add the following check in
> regulator_set_voltage().
> if (min_uV == max_uV && _regulator_get_voltage(rdev) == min_uV)
> goto out;
> Would this be acceptable? It's achieving the same thing as my patch,
> is more robust and covers the case of setting the voltage to the hw
> default value.
That sort of thing yes, just short circuit out the main logic in this
case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/fda85355/attachment.sig>
^ permalink raw reply
* [PATCH V2 1/2] ARM: tegra: enable LCD panel on Seaboard
From: Stephen Warren @ 2014-02-05 18:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Seaboard uses a CLAA101WA01A LCD panel. Enable the relevant display
controller, backlight, and regulators.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
---
v2:
* s/chungwa/chunghwa/
* Use the correct PWM instance
(I intend to apply these immediately)
---
arch/arm/boot/dts/tegra20-seaboard.dts | 55 +++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index a11b6e7b4759..a1d4bf9895d7 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -17,6 +17,14 @@
};
host1x at 50000000 {
+ dc at 54200000 {
+ rgb {
+ status = "okay";
+
+ nvidia,panel = <&panel>;
+ };
+ };
+
hdmi at 54280000 {
status = "okay";
@@ -312,6 +320,10 @@
status = "okay";
};
+ pwm: pwm at 7000a000 {
+ status = "okay";
+ };
+
i2c at 7000c000 {
status = "okay";
clock-frequency = <400000>;
@@ -369,7 +381,7 @@
#size-cells = <0>;
};
- i2c at 1 {
+ lvds_ddc: i2c at 1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
@@ -762,6 +774,17 @@
non-removable;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+
+ enable-gpios = <&gpio TEGRA_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
+ power-supply = <&vdd_bl_reg>;
+ pwms = <&pwm 2 5000000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
@@ -795,6 +818,16 @@
};
};
+ panel: panel {
+ compatible = "chunghwa,claa101wa01a", "simple-panel";
+
+ power-supply = <&vdd_pnl_reg>;
+ enable-gpios = <&gpio TEGRA_GPIO(B, 2) GPIO_ACTIVE_HIGH>;
+
+ backlight = <&backlight>;
+ ddc-i2c-bus = <&lvds_ddc>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -839,6 +872,26 @@
regulator-always-on;
regulator-boot-on;
};
+
+ vdd_pnl_reg: regulator at 4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+ regulator-name = "vdd_pnl";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ gpio = <&gpio TEGRA_GPIO(C, 6) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vdd_bl_reg: regulator at 5 {
+ compatible = "regulator-fixed";
+ reg = <5>;
+ regulator-name = "vdd_bl";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ gpio = <&gpio TEGRA_GPIO(W, 0) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
sound {
--
1.8.1.5
^ permalink raw reply related
* [PATCH V2 2/2] ARM: tegra: enable LCD panel on Ventana
From: Stephen Warren @ 2014-02-05 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391624410-28632-1-git-send-email-swarren@wwwdotorg.org>
From: Stephen Warren <swarren@nvidia.com>
Ventana uses a CLAA101WA01A LCD panel. Enable the relevant display
controller, backlight, and regulators.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
---
v2:
* s/chungwa/chunghwa/
* Use the correct PWM instance
---
arch/arm/boot/dts/tegra20-ventana.dts | 39 ++++++++++++++++++++++++++++++++---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 571d12e6ac2d..ca8484cccddc 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -17,6 +17,14 @@
};
host1x at 50000000 {
+ dc at 54200000 {
+ rgb {
+ status = "okay";
+
+ nvidia,panel = <&panel>;
+ };
+ };
+
hdmi at 54280000 {
status = "okay";
@@ -309,6 +317,10 @@
status = "okay";
};
+ pwm: pwm at 7000a000 {
+ status = "okay";
+ };
+
i2c at 7000c000 {
status = "okay";
clock-frequency = <400000>;
@@ -359,7 +371,7 @@
#size-cells = <0>;
};
- i2c at 1 {
+ lvds_ddc: i2c at 1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
@@ -557,6 +569,17 @@
non-removable;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+
+ enable-gpios = <&gpio TEGRA_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
+ power-supply = <&vdd_bl_reg>;
+ pwms = <&pwm 2 5000000>;
+
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
@@ -581,6 +604,16 @@
};
};
+ panel: panel {
+ compatible = "chunghwa,claa101wa01a", "simple-panel";
+
+ power-supply = <&vdd_pnl_reg>;
+ enable-gpios = <&gpio TEGRA_GPIO(B, 2) GPIO_ACTIVE_HIGH>;
+
+ backlight = <&backlight>;
+ ddc-i2c-bus = <&lvds_ddc>;
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -614,7 +647,7 @@
enable-active-high;
};
- regulator at 3 {
+ vdd_pnl_reg: regulator at 3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "vdd_pnl";
@@ -624,7 +657,7 @@
enable-active-high;
};
- regulator at 4 {
+ vdd_bl_reg: regulator at 4 {
compatible = "regulator-fixed";
reg = <4>;
regulator-name = "vdd_bl";
--
1.8.1.5
^ permalink raw reply related
* [alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Lars-Peter Clausen @ 2014-02-05 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205190732.5617f200@armhf>
On 02/05/2014 07:07 PM, Jean-Francois Moine wrote:
> On Wed, 05 Feb 2014 10:19:22 +0100
> Lars-Peter Clausen <lars@metafoo.de> wrote:
>
>>> So, in the CODEC, I don't see how I could update the parameters
>>> dictated by the EDID otherwise in changing the DAI driver parameters.
>>>
>>
>> The startup function is the right place. But instead of modifying the DAI
>> use snd_pcm_hw_constraint_mask64(), snd_pcm_hw_constraint_list(), etc. to
>> setup the additional constraints that come from the EDID.
>
> It is more complicated, but it works. Nevertheless, I have 2 problems:
>
> - snd_pcm_hw_constraint_list() keeps a pointer to the list, so, it
> cannot be in the stack. It fix this with static struct and rate array.
>
Right. If the struct is modified though it should be per device and not
global. I think the best way to implement this is to make the array static
and specify a mask for the constraint based on the EDID. E.g.
static unsigned int hdmi_rates[] = {
32000,
44100,
48000,
88200,
96000,
176400,
192000,
};
rate_mask = 0;
while (...) {
...
rate_mask |= 1 << sad[1];
}
rate_constraints->list = hdmi_rates;
rate_constraints->count = ARRAY_SIZE(hdmi_rates);
rate_constraints->mask = rate_mask;
> - snd_pcm_hw_constraint_mask64() is not exported.
> Is there an other way to set constraints on the formats/sample widths?
I think that's a bug. Both snd_pcm_hw_constraint_mask() and
snd_pcm_hw_constraint_mask64() should be exported. Can you send a patch?
- Lars
^ permalink raw reply
* [PATCH 1/3] arm: dts: am33xx.dtsi: Add node name to rtc device node
From: Sergei Shtylyov @ 2014-02-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391602361-2666-1-git-send-email-sr@denx.de>
Hello.
On 02/05/2014 03:12 PM, Stefan Roese wrote:
> Making it possible to reference and therefor change (disable) this
> device node from other dts file which import this dtsi file.
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Lukas Stockmann <lukas.stockmann@siemens.com>
> Cc: Benoit Cousson <bcousson@baylibre.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/am33xx.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 6d95d3d..b8daf8c 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -399,7 +399,7 @@
> ti,timer-pwm;
> };
>
> - rtc at 44e3e000 {
> + rtc: rtc at 44e3e000 {
Node name is "rtc at 44e3e000" -- what you are adding is a label.
WBR, Sergei
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Jason Cooper @ 2014-02-05 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390673950-4521-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Sat, Jan 25, 2014 at 07:19:06PM +0100, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> registered before core clocks driver. Unfortunately, we cannot
> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> init order for our drivers is always core clocks before clock gating,
> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> init function that will register core clocks before clock gating
> driver.
>
> This patch is based on pre-v3.14-rc1 mainline and should go in as
> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> I suggest Jason picks it up as a topic branch.
>
> The patches have been boot tested on Dove and compile-tested only
> for Kirkwood, Armada 370 and XP.
>
> Sebastian Hesselbarth (4):
> clk: mvebu: armada-370: maintain clock init order
> clk: mvebu: armada-xp: maintain clock init order
> clk: mvebu: dove: maintain clock init order
> clk: mvebu: kirkwood: maintain clock init order
>
> drivers/clk/mvebu/armada-370.c | 21 ++++++++++-----------
> drivers/clk/mvebu/armada-xp.c | 20 +++++++++-----------
> drivers/clk/mvebu/dove.c | 19 +++++++++----------
> drivers/clk/mvebu/kirkwood.c | 34 ++++++++++++++++------------------
> 4 files changed, 44 insertions(+), 50 deletions(-)
Whole series applied to mvebu/clk-fixes.
thx,
Jason.
^ permalink raw reply
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Santosh Shilimkar @ 2014-02-05 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205162325.GB2248@e103592.cambridge.arm.com>
Dave,
On Wednesday 05 February 2014 11:23 AM, Dave Martin wrote:
> On Tue, Feb 04, 2014 at 06:04:56PM +0100, Arnd Bergmann wrote:
>> On Tuesday 04 February 2014 11:38:32 Santosh Shilimkar wrote:
>>> On Tuesday 04 February 2014 11:15 AM, Arnd Bergmann wrote:
>>>> On Tuesday 04 February 2014, Santosh Shilimkar wrote:
>>
>>>> I think this is going into a wrong direction. DMA translation is not
>>>> at all a platform-specific thing, but rather bus specific. The most
>>>> common scenario is that you have some 64-bit capable buses and some
>>>> buses that are limited to 32-bit DMA (or less if you are unfortunate).
>>>>
>>> I may be wrong but you could have 64 bit bus but 32 bit DMA controllers.
>>> That is one of the case I am dealing with.
>>
>> You are absolutely right. In fact you could have any combination of
>> bus widths between a device and the RAM and the correct way to deal
>> with this is probably to follow the dma-ranges properties of each
>> device in-between and take the intersection (that may not be the
>> right term in English, but I think you know what I mean).
>>
>>>> I guess for the legacy cases (omap1, iop13xx, ks8695), we can
>>>> hardcode dma_map_ops for all devices to get this right. For everything
>>>> else, I'd suggest defaulting to the arm_dma_ops unless we get
>>>> other information from DT. This means we have to create standardized
>>>> properties to handle any combination of these:
>>>>
>>> Thats the case and the $subject series doesn't change that.
>>>
>>>> 1. DMA is coherent
>>>> 2. DMA space is offset from phys space
>>>> 3. DMA space is smaller than 32-bit
>>>> 4. DMA space is larger than 32-bit
>>>> 5. DMA goes through an IOMMU
>
> As you explain above, these are properties of end-to-end paths between
> a bus-mastering device and the destination. They aren't properties
> of a device, or of a bus.
>
> For example, we can have the following system, which ePAPR can't describe
> and wouldn't occur with PCI (or, at least would occur in a transparent
> way so that software does not need to understand the difference between
> this structure and a simple CPU->devices tree).
>
> C
> |
> v
> I ---+
> / \ \
> / \ \
> v v \
> A ----> B \
> \ v
> +---------> D
>
> This follows from the unidirectional and minimalistic nature of ARM SoC
> buses (AMBA family, AHB, APB etc. ... and most likely many others too).
>
> To describe A's DMA mappings correctly, the additional links must be
> described, even though thay are irrelevant for direct CPU->device
> transactions.
>
>
>>>>
>>>> The dma-ranges property can deal with 2-4. Highbank already introduced
>>>> a "dma-coherent" flag for 1, and we can decide to generalize that.
>>>> I don't know what the state of IOMMU support is, but we have to come
>>>> up with something better than what we had on PowerPC, because we now
>>>> have to deal with a combination of different IOMMUs in the same system,
>>>> whereas the most complex case on PowerPC was some devices all going
>>>> through one IOMMU and the other devices being linearly mapped.
>>>>
>>> Just to be clear, the patch set is not fiddling with dma_ops as such.
>>> The dma_ops needs few accessors to convert addresses and these accessors
>>> are different on few platforms. And hence needs to be patched.
>>
>> well, iop13xx is certainly not going to be multiplatform any time
>> soon, so we don't have to worry about those. ks8695 won't be multiplatform
>> unless I do it I suspect. I don't know about the plans for OMAP1,
>> but since only the OHCI device is special there, it would be trivial
>> to do a separate dma_map_ops for that device, or to extend arm_dma_ops
>> to read the offset in a per-device variable as we probably have to
>> do for DT/multiplatform as well.
>>
>>> We will try to look at "dma-ranges" to see if it can address my case.
>>> Thanks for the pointer
>
> dma-ranges does work for simpler cases. In particular, it works where all
> bus-mastering children of a bus node can a) access each other using the
> address space of the bus node, and b) all have the same view of the rest
> of the system (which may be different from the view from outside the bus:
> the dma-ranges property on the bus describes the difference).
>
> Sometimes, we may be able to describe an otherwise undescribable situation
> by introducing additional fake bus nodes. But if there are cross-links
> between devices, this won't always work.
>
>
> This may not be the common case, but it does happen: we need to decide
> whether to describe it propertly, or to describe a fantasy in the DT
> and bodge around it elsewhere when it happens.
>
>
> Similarly, for IOMMU, the ARM SMMU is an independent component which is
> not directly associated with a bus: nor is there guaranteed to be a 1:1
> correspondence. Simply wedging properties in a bus or device node to say
> "this is associated with an IOMMU" is not always going to work: it is
> what you flow through on a given device->device path that matters, and
> that can vary from path to path.
>
>
> Santosh, bearing these arguments in mind, do you think that dma-ranges
> is natural for your hardware?
>
> The answer may be "yes", but if we're having to twist things to fit,
> by having to describe something fake or unreal in DT and/or writing board
> specific code to work around it, that motivates coming up with a better
> way of describing the hardware in these cases.
>
The answer at least not fully "yes" with the limited look at dma-ranges
so far.
- The of_translate_dma_address() can be used to translate addresses
from DMA to CPU address space. And this should work but it will be
expensive compared to classic macro's.
- We don't see a way for CPU -> DMA addresses translation using DT.
Probably some more digging/pointers are is needed.
Regards,
Santosh
^ permalink raw reply
* [PATCH v3 2/6] ARM: tegra: Add chipid, revision and fuse init
From: Stephen Warren @ 2014-02-05 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-3-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> All fuse related functionality will move to a driver in the following patches.
> To prepare for this, export all the required functionality in a global header
> file and move all users of fuse.h to tegra-soc.h
The patch subject and description don't appear related to each-other.
^ permalink raw reply
* [PATCH] PCI: MVEBU: Use Device ID and revision from underlying endpoint
From: Jason Cooper @ 2014-02-05 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391597749-29807-1-git-send-email-andrew@lunn.ch>
On Wed, Feb 05, 2014 at 11:55:49AM +0100, Andrew Lunn wrote:
> Marvell SoCs place the SoC number into the PCIe endpoint device ID.
> The SoC stepping is placed into the PCIe revision. The old plat-orion
> PCIe driver allowed this information to be seen in user space with a
> simple lspci command.
>
> The new driver places a virtual PCI-PCI bridge on top of these
> endpoints. It has its own hard coded PCI device ID. Thus it is no
> longer possible to see what the SoC is using lspci.
>
> When initializing the PCI-PCI bridge, set its device ID and revision
> from the underlying endpoint, thus restoring this functionality.
> Debian would like to use this in order to aid installing the correct
> DTB file.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/pci/host/pci-mvebu.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
Also, since this fixes a userspace regression:
Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Cc: <stable@vger.kernel.org> # v3.11+
thx,
Jason.
>
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13478ecd4113..0e79665afd44 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -60,14 +60,6 @@
> #define PCIE_DEBUG_CTRL 0x1a60
> #define PCIE_DEBUG_SOFT_RESET BIT(20)
>
> -/*
> - * This product ID is registered by Marvell, and used when the Marvell
> - * SoC is not the root complex, but an endpoint on the PCIe bus. It is
> - * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
> - * bridge.
> - */
> -#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
> -
> /* PCI configuration space of a PCI-to-PCI bridge */
> struct mvebu_sw_pci_bridge {
> u16 vendor;
> @@ -388,7 +380,8 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
>
> bridge->class = PCI_CLASS_BRIDGE_PCI;
> bridge->vendor = PCI_VENDOR_ID_MARVELL;
> - bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> + bridge->device = mvebu_readl(port, PCIE_DEV_ID_OFF) >> 16;
> + bridge->revision = mvebu_readl(port, PCIE_DEV_REV_OFF) & 0xff;
> bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
> bridge->cache_line_size = 0x10;
>
> --
> 1.8.5.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 4/6] ARM: tegra: Add efuse bindings
From: Stephen Warren @ 2014-02-05 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-5-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> Add efuse bindings for Tegra20, Tegra30, Tegra114 and Tegra124.
> diff --git a/Documentation/devicetree/bindings/fuse/fuse-tegra.txt b/Documentation/devicetree/bindings/fuse/fuse-tegra.txt
> +- clocks: Should contain a pointer to the fuse clock.
I would prefer to use clock-names, and to follow the same text as all
the other Tegra bindings that are clock clients. In other words:
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- fuse
(this will allow easy future changes to the binding if required)
^ permalink raw reply
* [PATCH v3 5/6] misc: enable fuse drivers
From: Stephen Warren @ 2014-02-05 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-6-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> Enable building the fuse drivers.
This isn't really about enabling them. It's about changing which Tegra
fuse driver is built. Perhaps rephrase this more as:
ARM: tegra: build fuse driver from drivers/misc instead
The Tegra fuse code has moved to drivers/misc/fuse/tegra. Enable the
building of that code, and disable the building of the old fuse code in
arch/arm/mach-tegra/.
^ permalink raw reply
* [PATCH v3 6/6] ARM: tegra: remove fuse files from mach-tegra
From: Stephen Warren @ 2014-02-05 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-7-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> All fuse related functionality is now provided by the tegra fuse driver.
> Hence all the fuse related files in mach-tegra can be removed.
It's probably worth squashing this into patch 5, since that's what makes
these files unused.
^ permalink raw reply
* [PATCH v3 0/6] efuse driver for Tegra
From: Stephen Warren @ 2014-02-05 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-1-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> This driver allows userspace to read the raw efuse data. Its userspace
> interface is modelled after the sunxi_sid driver which provides similar
> functionality for some Allwinner SoCs. It has been tested on
> Tegra20 (ventana), Tegra30 (beaverboard) and Tegra114 (dalmore).
I think this series should have been CC'd to Greg and Arnd, since
they're listed in MAINTAINERS for drivers/misc/. I'll need their ack to
apply these patches to the Tegra tree.
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-05 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL6YDcZJa5xziR7dP-bEt1CO4BtL1vsO8Qm+hFwgCiQ1w@mail.gmail.com>
On 02/05/2014 07:41 PM, Rob Herring wrote:
> On Wed, Feb 5, 2014 at 10:18 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
>> On 02/05/2014 04:39 PM, Rob Herring wrote:
>>> On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>>> wrote:
>>>> This patch provides bindings for the 64-bit timer in the KeyStone
>>>> architecture devices. The timer can be configured as a general-purpose
>>>> 64-bit
>>>> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
>>>> timers, each half can operate in conjunction (chain mode) or
>>>> independently
>>>> (unchained mode) of each other.
>>> This is software configurable or h/w design time configurations?
>>>
>>> Rob
>>>
>> This is h/w design time configurations
> Then it seems like the binding should provide for describing those
> differences either with a property or different compatible strings.
>
> Rob
Oh..sorry, seems I didn't catch, this is configurable by software.
These configurations are like modes in which timer can work
and they are not different hardware IPs. It depends on driver in
which mode it should work.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v3 0/6] IIO pulse capture support for TI ECAP
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v2:
- Remove various unneeded field initialization
- Call iio_triggered_buffer_cleanup() on remove
Changes since v1:
- Rebased to 3.14-rc1
- Renamed in_pulse_polarity to pulse_polarity
- Added ABI entries for pulse devices and TI ECAP
This series adds support for PWM capture devices within IIO and
adds a TI ECAP IIO driver.
PWM capture devices are supported using a new IIO "pulse" channel type.
The IIO ECAP driver implements interrupt driven triggered buffer capture
only as raw sample reads are not applicable to this hardware.
Initially, the driver supports a single pulse width measurement with
configurable polarity. The ECAP hardware can support measurement of a
complete period and duty cycle but this is not yet implemented.
Matt Porter (6):
iio: add support for pulse width capture devices
iio: pulse: add TI ECAP driver
iio: enable selection and build of pulse drivers
iio: Add ABI docs for pulse capture devices
pwm: enable TI PWMSS if the IIO tiecap driver is selected
ARM: dts: AM33XX: Add ecap interrupt properties
Documentation/ABI/testing/sysfs-bus-iio | 18 +
.../ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 +
arch/arm/boot/dts/am33xx.dtsi | 6 +
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-core.c | 1 +
drivers/iio/pulse/Kconfig | 20 +
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 491 +++++++++++++++++++++
drivers/pwm/Kconfig | 2 +-
include/linux/iio/types.h | 1 +
11 files changed, 555 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
--
1.8.4
^ permalink raw reply
* [PATCH v3 1/6] iio: add support for pulse width capture devices
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
Add a channel type to support pulse width capture devices.
These devices capture the timing of a PWM signal based on a
configurable trigger
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/iio/industrialio-core.c | 1 +
include/linux/iio/types.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index acc911a..6ea0cf8 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -70,6 +70,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CCT] = "cct",
[IIO_PRESSURE] = "pressure",
[IIO_HUMIDITYRELATIVE] = "humidityrelative",
+ [IIO_PULSE] = "pulse",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index 084d882..4fa8840 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -30,6 +30,7 @@ enum iio_chan_type {
IIO_CCT,
IIO_PRESSURE,
IIO_HUMIDITYRELATIVE,
+ IIO_PULSE,
};
enum iio_modifier {
--
1.8.4
^ permalink raw reply related
* [PATCH v3 2/6] iio: pulse: add TI ECAP driver
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
Adds support for capturing PWM signals using the TI ECAP peripheral.
This driver supports triggered buffer capture of pulses on multiple
ECAP instances. In addition, the driver supports configurable polarity
of the signal to be captured.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/iio/pulse/Kconfig | 20 ++
drivers/iio/pulse/Makefile | 6 +
drivers/iio/pulse/tiecap.c | 491 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 517 insertions(+)
create mode 100644 drivers/iio/pulse/Kconfig
create mode 100644 drivers/iio/pulse/Makefile
create mode 100644 drivers/iio/pulse/tiecap.c
diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
new file mode 100644
index 0000000..9864d4b
--- /dev/null
+++ b/drivers/iio/pulse/Kconfig
@@ -0,0 +1,20 @@
+#
+# Pulse Capture Devices
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "Pulse Capture Devices"
+
+config IIO_TIECAP
+ tristate "TI ECAP Pulse Capture"
+ depends on SOC_AM33XX
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ If you say yes here you get support for the TI ECAP peripheral
+ in pulse capture mode.
+
+ This driver can also be built as a module. If so, the module
+ will be called tiecap
+
+endmenu
diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
new file mode 100644
index 0000000..94d4b00
--- /dev/null
+++ b/drivers/iio/pulse/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for IIO PWM Capture Devices
+#
+
+# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_IIO_TIECAP) += tiecap.o
diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
new file mode 100644
index 0000000..fd96745
--- /dev/null
+++ b/drivers/iio/pulse/tiecap.c
@@ -0,0 +1,491 @@
+/*
+ * ECAP IIO pulse capture driver
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include "../../pwm/pwm-tipwmss.h"
+
+/* ECAP regs and bits */
+#define CAP1 0x08
+#define CAP2 0x0c
+#define ECCTL1 0x28
+#define ECCTL1_RUN_FREE BIT(15)
+#define ECCTL1_CAPLDEN BIT(8)
+#define ECCTL1_CAP2POL BIT(2)
+#define ECCTL1_CTRRST1 BIT(1)
+#define ECCTL1_CAP1POL BIT(0)
+#define ECCTL2 0x2a
+#define ECCTL2_SYNCO_SEL_DIS BIT(7)
+#define ECCTL2_TSCTR_FREERUN BIT(4)
+#define ECCTL2_REARM BIT(3)
+#define ECCTL2_STOP_WRAP_2 BIT(1)
+#define ECEINT 0x2c
+#define ECFLG 0x2e
+#define ECCLR 0x30
+#define ECINT_CTRCMP BIT(7)
+#define ECINT_CTRPRD BIT(6)
+#define ECINT_CTROVF BIT(5)
+#define ECINT_CEVT4 BIT(4)
+#define ECINT_CEVT3 BIT(3)
+#define ECINT_CEVT2 BIT(2)
+#define ECINT_CEVT1 BIT(1)
+#define ECINT_ALL (ECINT_CTRCMP | \
+ ECINT_CTRPRD | \
+ ECINT_CTROVF | \
+ ECINT_CEVT4 | \
+ ECINT_CEVT3 | \
+ ECINT_CEVT2 | \
+ ECINT_CEVT1)
+
+/* ECAP driver flags */
+#define ECAP_POLARITY_HIGH BIT(1)
+#define ECAP_ENABLED BIT(0)
+
+struct ecap_context {
+ u32 cap1;
+ u32 cap2;
+ u16 ecctl1;
+ u16 ecctl2;
+ u16 eceint;
+};
+
+struct ecap_state {
+ unsigned long flags;
+ unsigned int clk_rate;
+ void __iomem *regs;
+ u32 *buf;
+ struct ecap_context ctx;
+};
+
+#define dev_to_ecap_state(d) iio_priv(dev_to_iio_dev(d))
+
+static const struct iio_chan_spec ecap_channels[] = {
+ {
+ .type = IIO_PULSE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 32,
+ .storagebits = 32,
+ .endianness = IIO_LE,
+ },
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(1)
+};
+
+static ssize_t ecap_attr_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ return sprintf(buf, "%d\n",
+ test_bit(ECAP_POLARITY_HIGH, &state->flags));
+}
+
+static ssize_t ecap_attr_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
+{
+ int ret;
+ bool val;
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ return -EINVAL;
+
+ ret = strtobool(buf, &val);
+ if (ret)
+ return ret;
+
+ if (val)
+ set_bit(ECAP_POLARITY_HIGH, &state->flags);
+ else
+ clear_bit(ECAP_POLARITY_HIGH, &state->flags);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(pulse_polarity, S_IRUGO | S_IWUSR,
+ ecap_attr_show, ecap_attr_store, 0);
+
+static struct attribute *ecap_attributes[] = {
+ &iio_dev_attr_pulse_polarity.dev_attr.attr,
+ NULL,
+};
+
+static struct attribute_group ecap_attribute_group = {
+ .attrs = ecap_attributes,
+};
+
+static int ecap_read_raw(struct iio_dev *idev,
+ struct iio_chan_spec const *ch, int *val,
+ int *val2, long mask)
+{
+ struct ecap_state *state = iio_priv(idev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ /*
+ * Always return 0 as a pulse width sample
+ * is only valid in a triggered condition
+ */
+ *val = 0;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ *val = 0;
+ *val2 = NSEC_PER_SEC / state->clk_rate;
+ return IIO_VAL_INT_PLUS_NANO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info ecap_info = {
+ .driver_module = THIS_MODULE,
+ .attrs = &ecap_attribute_group,
+ .read_raw = &ecap_read_raw,
+};
+
+static irqreturn_t ecap_trigger_handler(int irq, void *private)
+{
+ struct iio_poll_func *pf = private;
+ struct iio_dev *idev = pf->indio_dev;
+ struct ecap_state *state = iio_priv(idev);
+
+ /* Read pulse counter value */
+ *state->buf = readl(state->regs + CAP2);
+
+ iio_push_to_buffers_with_timestamp(idev, state->buf, iio_get_time_ns());
+
+ iio_trigger_notify_done(idev->trig);
+
+ return IRQ_HANDLED;
+};
+
+
+static const struct iio_trigger_ops iio_interrupt_trigger_ops = {
+ .owner = THIS_MODULE,
+};
+
+static irqreturn_t ecap_interrupt_handler(int irq, void *private)
+{
+ struct iio_dev *idev = private;
+ struct ecap_state *state = iio_priv(idev);
+ u16 ints;
+
+ iio_trigger_poll(idev->trig, 0);
+
+ /* Clear CAP2 interrupt */
+ ints = readw(state->regs + ECFLG);
+ if (ints & ECINT_CEVT2)
+ writew(ECINT_CEVT2, state->regs + ECCLR);
+ else
+ dev_warn(&idev->dev, "unhandled interrupt flagged: %04x\n",
+ ints);
+
+ return IRQ_HANDLED;
+}
+
+static int ecap_buffer_predisable(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+ int ret = 0;
+ u16 ecctl2;
+
+ /* Stop capture */
+ clear_bit(ECAP_ENABLED, &state->flags);
+ ecctl2 = readw(state->regs + ECCTL2) & ~ECCTL2_TSCTR_FREERUN;
+ writew(ecctl2, state->regs + ECCTL2);
+
+ /* Disable and clear all interrupts */
+ writew(0, state->regs + ECEINT);
+ writew(ECINT_ALL, state->regs + ECCLR);
+
+ ret = iio_triggered_buffer_predisable(idev);
+
+ pm_runtime_put_sync(idev->dev.parent);
+
+ return ret;
+}
+
+static int ecap_buffer_postenable(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+ int ret = 0;
+ u16 ecctl1, ecctl2;
+
+ pm_runtime_get_sync(idev->dev.parent);
+
+ /* Configure pulse polarity */
+ ecctl1 = readw(state->regs + ECCTL1);
+ if (test_bit(ECAP_POLARITY_HIGH, &state->flags)) {
+ /* CAP1 rising, CAP2 falling */
+ ecctl1 |= ECCTL1_CAP2POL;
+ ecctl1 &= ~ECCTL1_CAP1POL;
+ } else {
+ /* CAP1 falling, CAP2 rising */
+ ecctl1 &= ~ECCTL1_CAP2POL;
+ ecctl1 |= ECCTL1_CAP1POL;
+ }
+ writew(ecctl1, state->regs + ECCTL1);
+
+ /* Enable CAP2 interrupt */
+ writew(ECINT_CEVT2, state->regs + ECEINT);
+
+ /* Enable capture */
+ ecctl2 = readw(state->regs + ECCTL2);
+ ecctl2 |= ECCTL2_TSCTR_FREERUN | ECCTL2_REARM;
+ writew(ecctl2, state->regs + ECCTL2);
+ set_bit(ECAP_ENABLED, &state->flags);
+
+ ret = iio_triggered_buffer_postenable(idev);
+
+ return ret;
+}
+
+static const struct iio_buffer_setup_ops ecap_buffer_setup_ops = {
+ .postenable = &ecap_buffer_postenable,
+ .predisable = &ecap_buffer_predisable,
+};
+
+static void ecap_init_hw(struct iio_dev *idev)
+{
+ struct ecap_state *state = iio_priv(idev);
+
+ clear_bit(ECAP_ENABLED, &state->flags);
+ set_bit(ECAP_POLARITY_HIGH, &state->flags);
+
+ writew(ECCTL1_RUN_FREE | ECCTL1_CAPLDEN |
+ ECCTL1_CAP2POL | ECCTL1_CTRRST1,
+ state->regs + ECCTL1);
+
+ writew(ECCTL2_SYNCO_SEL_DIS | ECCTL2_STOP_WRAP_2,
+ state->regs + ECCTL2);
+}
+
+static const struct of_device_id ecap_of_ids[] = {
+ { .compatible = "ti,am33xx-ecap" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ecap_of_ids);
+
+static int ecap_probe(struct platform_device *pdev)
+{
+ int irq, ret;
+ struct iio_dev *idev;
+ struct ecap_state *state;
+ struct resource *r;
+ struct clk *clk;
+ struct iio_trigger *trig;
+ u16 status;
+
+ idev = devm_iio_device_alloc(&pdev->dev, sizeof(struct ecap_state));
+ if (!idev)
+ return -ENOMEM;
+
+ state = iio_priv(idev);
+
+ clk = devm_clk_get(&pdev->dev, "fck");
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "failed to get clock\n");
+ return PTR_ERR(clk);
+ }
+
+ state->clk_rate = clk_get_rate(clk);
+ if (!state->clk_rate) {
+ dev_err(&pdev->dev, "failed to get clock rate\n");
+ return -EINVAL;
+ }
+
+ platform_set_drvdata(pdev, idev);
+
+ idev->dev.parent = &pdev->dev;
+ idev->name = dev_name(&pdev->dev);
+ idev->modes = INDIO_DIRECT_MODE;
+ idev->info = &ecap_info;
+ idev->channels = ecap_channels;
+ /* One h/w capture and one s/w timestamp channel per instance */
+ idev->num_channels = ARRAY_SIZE(ecap_channels);
+
+ trig = devm_iio_trigger_alloc(&pdev->dev, "%s-dev%d",
+ idev->name, idev->id);
+ if (!trig)
+ return -ENOMEM;
+ trig->dev.parent = idev->dev.parent;
+ iio_trigger_set_drvdata(trig, idev);
+ trig->ops = &iio_interrupt_trigger_ops;
+
+ ret = iio_trigger_register(trig);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register trigger\n");
+ return ret;
+ }
+
+ ret = iio_triggered_buffer_setup(idev, NULL,
+ &ecap_trigger_handler,
+ &ecap_buffer_setup_ops);
+ if (ret)
+ return ret;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq is specified\n");
+ return irq;
+ }
+ ret = devm_request_irq(&pdev->dev, irq,
+ &ecap_interrupt_handler,
+ 0, dev_name(&pdev->dev), idev);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to request irq\n");
+ goto uninit_buffer;
+ }
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ state->regs = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(state->regs)) {
+ dev_err(&pdev->dev, "unable to remap registers\n");
+ ret = PTR_ERR(state->regs);
+ goto uninit_buffer;
+ };
+
+ ret = iio_device_register(idev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "unable to register device\n");
+ goto uninit_buffer;
+ }
+
+ state->buf = devm_kzalloc(&idev->dev, idev->scan_bytes, GFP_KERNEL);
+ if (!state->buf) {
+ ret = -ENOMEM;
+ goto uninit_buffer;
+ }
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
+ status = pwmss_submodule_state_change(pdev->dev.parent,
+ PWMSS_ECAPCLK_EN);
+ if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
+ dev_err(&pdev->dev, "failed to enable PWMSS config space clock\n");
+ ret = -EINVAL;
+ goto pwmss_clk_failure;
+ }
+
+ ecap_init_hw(idev);
+
+ pm_runtime_put_sync(&pdev->dev);
+
+ return 0;
+
+pwmss_clk_failure:
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ iio_device_unregister(idev);
+
+uninit_buffer:
+ iio_triggered_buffer_cleanup(idev);
+
+ return ret;
+}
+
+static int ecap_remove(struct platform_device *pdev)
+{
+ struct iio_dev *idev = platform_get_drvdata(pdev);
+
+ pm_runtime_get_sync(&pdev->dev);
+
+ pwmss_submodule_state_change(pdev->dev.parent, PWMSS_ECAPCLK_STOP_REQ);
+
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
+ iio_device_unregister(idev);
+ iio_triggered_buffer_cleanup(idev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ecap_suspend(struct device *dev)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ pm_runtime_get_sync(dev);
+ state->ctx.cap1 = readl(state->regs + CAP1);
+ state->ctx.cap2 = readl(state->regs + CAP2);
+ state->ctx.eceint = readw(state->regs + ECEINT);
+ state->ctx.ecctl1 = readw(state->regs + ECCTL1);
+ state->ctx.ecctl2 = readw(state->regs + ECCTL2);
+ pm_runtime_put_sync(dev);
+
+ /* If capture was active, disable ECAP */
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int ecap_resume(struct device *dev)
+{
+ struct ecap_state *state = dev_to_ecap_state(dev);
+
+ /* If capture was active, enable ECAP */
+ if (test_bit(ECAP_ENABLED, &state->flags))
+ pm_runtime_get_sync(dev);
+
+ pm_runtime_get_sync(dev);
+ writel(state->ctx.cap1, state->regs + CAP1);
+ writel(state->ctx.cap2, state->regs + CAP2);
+ writew(state->ctx.eceint, state->regs + ECEINT);
+ writew(state->ctx.ecctl1, state->regs + ECCTL1);
+ writew(state->ctx.ecctl2, state->regs + ECCTL2);
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(ecap_pm_ops, ecap_suspend, ecap_resume);
+
+static struct platform_driver ecap_iio_driver = {
+ .driver = {
+ .name = "ecap",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(ecap_of_ids),
+ .pm = &ecap_pm_ops,
+ },
+ .probe = ecap_probe,
+ .remove = ecap_remove,
+};
+
+module_platform_driver(ecap_iio_driver);
+
+MODULE_DESCRIPTION("ECAP IIO pulse capture driver");
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_LICENSE("GPL");
--
1.8.4
^ permalink raw reply related
* [PATCH v3 3/6] iio: enable selection and build of pulse drivers
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
Add the pulse driver subdirectory when configuring and building
IIO.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/iio/Kconfig | 1 +
drivers/iio/Makefile | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 5dd0e12..286acc3 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -74,6 +74,7 @@ if IIO_TRIGGER
source "drivers/iio/trigger/Kconfig"
endif #IIO_TRIGGER
source "drivers/iio/pressure/Kconfig"
+source "drivers/iio/pulse/Kconfig"
source "drivers/iio/temperature/Kconfig"
endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 887d390..9a953c9 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -24,5 +24,6 @@ obj-y += light/
obj-y += magnetometer/
obj-y += orientation/
obj-y += pressure/
+obj-y += pulse/
obj-y += temperature/
obj-y += trigger/
--
1.8.4
^ permalink raw reply related
* [PATCH v3 4/6] iio: Add ABI docs for pulse capture devices
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
Add standard ABI entries for pulse capture devices. Also add
a separate ABI entry for the TI ECAP driver polarity option.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
Documentation/ABI/testing/sysfs-bus-iio | 18 ++++++++++++++++++
Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap | 9 +++++++++
2 files changed, 27 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..918a201 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -210,6 +210,14 @@ Contact: linux-iio at vger.kernel.org
Description:
Scaled humidity measurement in milli percent.
+What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_pulse_raw
+KernelVersion: 3.15
+Contact: linux-iio at vger.kernel.org
+Description:
+ Raw pulse measurement from channel Y. Units after
+ application of scale and offset are nanoseconds.
+
What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
@@ -220,6 +228,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_offset
+What: /sys/bus/iio/devices/iio:deviceX/in_pulse_offset
KernelVersion: 2.6.35
Contact: linux-iio at vger.kernel.org
Description:
@@ -251,6 +261,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_pulseY_scale
+What: /sys/bus/iio/devices/iio:deviceX/in_pulse_scale
KernelVersion: 2.6.35
Contact: linux-iio at vger.kernel.org
Description:
@@ -784,6 +796,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
+What: /sys/.../iio:deviceX/scan_elements/in_pulseY_en
+What: /sys/.../iio:deviceX/scan_elements/in_pulse_en
KernelVersion: 2.6.37
Contact: linux-iio at vger.kernel.org
Description:
@@ -799,6 +813,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
+What: /sys/.../iio:deviceX/scan_elements/in_pulseY_type
+What: /sys/.../iio:deviceX/scan_elements/in_pulse_type
KernelVersion: 2.6.37
Contact: linux-iio at vger.kernel.org
Description:
@@ -845,6 +861,8 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
+What: /sys/.../iio:deviceX/scan_elements/in_pulseY_index
+What: /sys/.../iio:deviceX/scan_elements/in_pulse_index
KernelVersion: 2.6.37
Contact: linux-iio at vger.kernel.org
Description:
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap
new file mode 100644
index 0000000..a9e4a9f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-pulse-tiecap
@@ -0,0 +1,9 @@
+What: /sys/bus/iio/devices/iio:deviceX/pulse_polarityY
+What: /sys/bus/iio/devices/iio:deviceX/pulse_polarity
+Date: January 2014
+KernelVersion: 3.15
+Contact: Matt Porter <mporter@linaro.org>
+Description:
+ Get and set the polarity of the pulse signal to be captured
+ for channel Y. 1 indicates a high pulse signal and 0
+ indicates a low pulse signal.
--
1.8.4
^ permalink raw reply related
* [PATCH v3 5/6] pwm: enable TI PWMSS if the IIO tiecap driver is selected
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
The IIO TI ECAP driver depends on the TI PWMSS management
driver in this subsystem. Enable PWMSS when the IIO TI ECAP
driver is selected.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
drivers/pwm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..bd3cc65 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -219,7 +219,7 @@ config PWM_TIEHRPWM
config PWM_TIPWMSS
bool
- default y if SOC_AM33XX && (PWM_TIECAP || PWM_TIEHRPWM)
+ default y if SOC_AM33XX && (IIO_TIECAP || PWM_TIECAP || PWM_TIEHRPWM)
help
PWM Subsystem driver support for AM33xx SOC.
--
1.8.4
^ permalink raw reply related
* [PATCH v3 6/6] ARM: dts: AM33XX: Add ecap interrupt properties
From: Matt Porter @ 2014-02-05 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391626901-31684-1-git-send-email-mporter@linaro.org>
Add missing interrupt properties to the ecap0, ecap1, and ecap2
nodes.
Signed-off-by: Matt Porter <mporter@linaro.org>
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 6d95d3d..b4139ba 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -582,6 +582,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48300100 0x80>;
+ interrupts = <31>;
+ interrupt-names = "ecap0";
ti,hwmods = "ecap0";
status = "disabled";
};
@@ -610,6 +612,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48302100 0x80>;
+ interrupts = <47>;
+ interrupt-names = "ecap1";
ti,hwmods = "ecap1";
status = "disabled";
};
@@ -638,6 +642,8 @@
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48304100 0x80>;
+ interrupts = <61>;
+ interrupt-names = "ecap2";
ti,hwmods = "ecap2";
status = "disabled";
};
--
1.8.4
^ permalink raw reply related
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-02-05 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Wim,
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
> This entire series depends on latest irqchip-orion fixes by Sebastian.
> Namely, this one: https://lkml.org/lkml/2014/1/23/594.
>
> How should we handle this dependency?
As this series depends on another branch we are handling (currently
mvebu-next/irqchip-fixes, destined for tglx's tree), would you mind if
we took this series through arm-soc with your Ack?
thx,
Jason.
>
> Changes from v4 are:
>
> * Provided better commit subject and commit log for patch 7:
> "watchdog: orion: Handle the interrupt so it's properly acked".
>
> * Corrected the misnamed fuction try_rstout_ioremap().
>
> * A bunch of s/interruption/interrupt fixes
>
> * Dropped the '0' as a valid IRQ in the platform_get_irq() check, given
> it should return a positive virq-space number.
>
> Changes from v3 are:
>
> * It wasn't nice to break DT compatibility by adding a second resource
> requirement, so we provided a fallback to use the RSTOUT address.
> All in all, the solution doesn't look too bad.
>
> * Added a full watchdog stop at driver probe time, *before* the call
> to request_irq().
>
> Notice that currently the request_irq() doesn't seem to clear the
> pending interrupt. This means the BRIDGE_CAUSE clear removal is
> still not safe.
>
> This should be fixed sooner than later and, of course, before this
> gets merged.
>
> * Rework the interrupt request, to use devm_request_irq() and
> avoid dealing with IRQ releasing.
>
> * Added proper clock error handling and fixed the probe() error path.
>
> * Typos and minor issues got fixed
>
> Changes from v2:
>
> * Add proper error checking on clk_prepare_enable() and return
> PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
>
> * After the usage of the atomic I/O and considering the watchdog core
> does its own serialization, the driver's spinlock was completely
> redundant and was removed. Also suggested by Fabio.
>
> * Instead of making the driver dependent on PLAT_ORION, added a dependency
> to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
> we're working on PLAT_ORION removal.
>
> Changes from v1:
>
> * Watchdog RSTOUT enable.
> While v1 enabled the RSTOUT at each machine initialization, Jason Gunthorpe
> later pointed out [2] that such enabling might lead to a spurious watchdog
> trigger, in the event of the watchdog expired event not being cleared.
>
> Therefore, the current patchset adds RSTOUT as a second address resource
> (or 'reg' entry in devicetree words) to allow different platforms specify
> the corresponding address of the register. This change allows to build the
> driver on multiplatforms builds as helps remove a mach-specific header.
>
> The drawback of this is that the DT backwards compatibility gets broken;
> this was timely discussed but no better solution was achieved or proposed.
>
> * BRIDGE CAUSE clear removal
> The watchdog cause clear should be done by the bridge irqchip driver, so
> it's fine to remove it from the watchdog driver and instead request the
> interrupt.
>
> However, there are still a few platforms (orion5x, and legacy
> kirkwood/dove) that doesn't have this bridge irqchip support enabled.
> On these platforms the bridge cause clear is simply *not* done.
>
> If we are paranoid about this, maybe we can simply add the clear on each
> mach-xxx/irq.c, together with the other irq is initialization.
>
> Once again, thanks to everyone who helped reviewing this.
>
> Ezequiel Garcia (20):
> ARM: Introduce atomic MMIO modify
> clocksource: orion: Use atomic access for shared registers
> watchdog: orion: Add clock error handling
> watchdog: orion: Use atomic access for shared registers
> watchdog: orion: Remove unused macros
> watchdog: orion: Make sure the watchdog is initially stopped
> watchdog: orion: Handle the interrupt so it's properly acked
> watchdog: orion: Make RSTOUT register a separate resource
> watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
> watchdog: orion: Introduce an orion_watchdog device structure
> watchdog: orion: Introduce per-compatible of_device_id data
> watchdog: orion: Add per-compatible clock initialization
> watchdog: orion: Add per-compatible watchdog start implementation
> watchdog: orion: Add support for Armada 370 and Armada XP SoC
> ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
> ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
> ARM: dove: Enable Dove watchdog in the devicetree
> watchdog: orion: Enable the build on ARCH_MVEBU
> ARM: mvebu: Enable watchdog support in defconfig
> ARM: dove: Enable watchdog support in the defconfig
>
> .../devicetree/bindings/watchdog/marvel.txt | 8 +-
> arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
> arch/arm/boot/dts/armada-370.dtsi | 5 +
> arch/arm/boot/dts/armada-xp.dtsi | 6 +
> arch/arm/boot/dts/dove.dtsi | 8 +
> arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> arch/arm/configs/dove_defconfig | 2 +
> arch/arm/configs/mvebu_defconfig | 2 +
> arch/arm/include/asm/io.h | 6 +
> arch/arm/kernel/io.c | 35 ++
> arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
> arch/arm/plat-orion/common.c | 10 +-
> drivers/clocksource/time-orion.c | 28 +-
> drivers/watchdog/Kconfig | 2 +-
> drivers/watchdog/orion_wdt.c | 369 ++++++++++++++++-----
> 18 files changed, 383 insertions(+), 108 deletions(-)
>
> --
> 1.8.1.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Will Deacon @ 2014-02-05 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3460536.Sh23gjDa6X@wuerfel>
Hi Arnd,
Thanks for having a look.
On Tue, Feb 04, 2014 at 07:13:49PM +0000, Arnd Bergmann wrote:
> On Tuesday 04 February 2014 16:53:03 Will Deacon wrote:
> > +
> > +- ranges : As described in IEEE Std 1275-1994, but must provide
> > + at least a definition of the Configuration Space plus
> > + one or both of IO and Memory Space.
> > +
>
> I might need to reread the spec, but I think the config space is not
> actually supposed to be in the 'ranges' of the host bridge at all,
> and it should just be listed in the 'reg'.
This wasn't at all clear to me (I listed it in the cover-letter as being
something to sort out).
> IIRC the reason why the config space is part of the three-cell address
> is so that you can have funky ways to say "memory space of the device
> with bus/dev/fn is actually translated to address X rather then Y".
>
> It's too late to change that for the other drivers now, after the
> binding is established.
The spec is based on the idea that open-firmware enumerates your entire PCI
bus topology, then provides the Conriguation Space address for each device
using a reg property.
Since:
(a) This doesn't match what we're planning to support
(b) Runs the risk of making the "reg" encoding something specific to this
driver
(c) Doesn't match how we describe Memory and IO Spaces
(d) There is already precendence in mainline
I chose to use "ranges" instead.
Now, if "reg" is definitely the correct thing to do, is it simply a matter
of putting the Configuration Space base address in there, or do we also need
to do the rest of what ePAPR says (expansion ROM details, ...)? I don't like
the idea of enumerating the entire bus in the DT when we don't need to.
> > +Configuration Space is assumed to be memory-mapped (as opposed to being
> > +accessed via an ioport) and laid out with a direct correspondence to the
> > +geography of a PCI bus address, by concatenating the various components
> > +to form a 24-bit offset:
> > +
> > + cfg_offset(bus, device, function, register) =
> > + bus << 16 | device << 11 | function << 8 | register
>
> This won't allow extended config space. Why not just do the
> regular mmconfig layout and make this:
>
> cfg_offset(bus, device, function, register) =
> bus << 20 | device << 15 | function << 12 | register;
Is it worth adding a DT property to support both, or is ECAM the only thing
to care about? I'm happy either way, although I'll need to hack kvmtool to
use the new scheme.
> > +static int virt_pci_setup(int nr, struct pci_sys_data *sys)
> > +{
> > + struct virt_pci *pci = sys->private_data;
> > +
> > + if (resource_type(&pci->io)) {
> > + pci_add_resource(&sys->resources, &pci->io);
> > + pci_ioremap_io(nr * resource_size(&pci->io), pci->io.start);
> > + }
>
> This should really compute an io_offset.
>
> > + if (resource_type(&pci->mem))
> > + pci_add_resource(&sys->resources, &pci->mem);
>
> and also a mem_offset, which is something different.
As somebody new to PCI, I'm afraid you've lost me here. Are you referring to
using pci_add_resource_offset instead, then removing my restriction on
having a single resource from the parsing code?
> > + pci->cfg_base = devm_ioremap_resource(pci->dev, &pci->cfg);
> > + return !IS_ERR(pci->cfg_base);
> > +}
> > +
> > +static const struct of_device_id virt_pci_of_match[] = {
> > + { .compatible = "linux,pci-virt" },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, virt_pci_of_match);
>
> I don't think we even want "virt" in the compatible string. The
> binding should be generic enough that it can actually work with
> real hardware.
Sure. How about "arm,pci-generic" ? Alternatives are
"arm,pcie-generic" or "linux,pci-generic".
> > + for_each_of_pci_range(&parser, &range) {
> > + u32 restype = range.flags & IORESOURCE_TYPE_BITS;
> > +
> > + switch (restype) {
> > + case IORESOURCE_IO:
> > + if (resource_type(&pci->io))
> > + dev_warn(dev,
> > + "ignoring additional io resource\n");
> > + else
> > + of_pci_range_to_resource(&range, np, &pci->io);
> > + break;
> > + case IORESOURCE_MEM:
> > + if (resource_type(&pci->mem))
> > + dev_warn(dev,
> > + "ignoring additional mem resource\n");
> > + else
> > + of_pci_range_to_resource(&range, np, &pci->mem);
> > + break;
>
> This shows once more that the range parser code is suboptimal. So far
> every single driver got the I/O space wrong here, because the obvious
> way to write this function is also completely wrong.
I see you mentioned to Liviu that you should register a logical resource,
rather than physical resource returned from the parser. It seems odd that
I/O space appears to work with this code as-is (I've tested it on arm using
kvmtool by removing the memory bars).
> What you get out of "of_pci_range_to_resource(&range, np, &pci->io)"
> is not the resource you want to pass into pci_add_resource()
> later.
Do I need to open-code the resource translation from phys -> logical?
>
> > + memset(&hw, 0, sizeof(hw));
> > + hw.nr_controllers = 1;
> > + hw.private_data = (void **)&pci;
> > + hw.setup = virt_pci_setup;
> > + hw.map_irq = of_irq_parse_and_map_pci;
> > + hw.ops = &virt_pci_ops;
> > + pci_common_init_dev(dev, &hw);
>
> Since most fields here are constant, I'd just write this as
>
> struct hw_pci hw = {
> .nr_controllers = 1,
> .setup = virt_pci_setup,
> ...
> };
Can do.
Thanks,
Will
^ permalink raw reply
* [PATCH v5 02/20] clocksource: orion: Use atomic access for shared registers
From: Jason Cooper @ 2014-02-05 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-3-git-send-email-ezequiel.garcia@free-electrons.com>
Daniel,
On Mon, Jan 27, 2014 at 12:27:02PM -0300, Ezequiel Garcia wrote:
> Replace the driver-specific thread-safe shared register API
> by the recently introduced atomic_io_clear_set().
>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> drivers/clocksource/time-orion.c | 28 ++++++++++------------------
> 1 file changed, 10 insertions(+), 18 deletions(-)
The MMIO patch this depends on:
c5ca95b507c8 ARM: 7930/1: Introduce atomic MMIO modify
made it in to v3.14-rc1. It looks like this change is independent of
the rest of the watchdog series, so:
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
> diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
> index 9c7f018..3f14e56 100644
> --- a/drivers/clocksource/time-orion.c
> +++ b/drivers/clocksource/time-orion.c
> @@ -35,20 +35,6 @@
> #define ORION_ONESHOT_MAX 0xfffffffe
>
> static void __iomem *timer_base;
> -static DEFINE_SPINLOCK(timer_ctrl_lock);
> -
> -/*
> - * Thread-safe access to TIMER_CTRL register
> - * (shared with watchdog timer)
> - */
> -void orion_timer_ctrl_clrset(u32 clr, u32 set)
> -{
> - spin_lock(&timer_ctrl_lock);
> - writel((readl(timer_base + TIMER_CTRL) & ~clr) | set,
> - timer_base + TIMER_CTRL);
> - spin_unlock(&timer_ctrl_lock);
> -}
> -EXPORT_SYMBOL(orion_timer_ctrl_clrset);
>
> /*
> * Free-running clocksource handling.
> @@ -68,7 +54,8 @@ static int orion_clkevt_next_event(unsigned long delta,
> {
> /* setup and enable one-shot timer */
> writel(delta, timer_base + TIMER1_VAL);
> - orion_timer_ctrl_clrset(TIMER1_RELOAD_EN, TIMER1_EN);
> + atomic_io_modify(timer_base + TIMER_CTRL,
> + TIMER1_RELOAD_EN | TIMER1_EN, TIMER1_EN);
>
> return 0;
> }
> @@ -80,10 +67,13 @@ static void orion_clkevt_mode(enum clock_event_mode mode,
> /* setup and enable periodic timer at 1/HZ intervals */
> writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD);
> writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL);
> - orion_timer_ctrl_clrset(0, TIMER1_RELOAD_EN | TIMER1_EN);
> + atomic_io_modify(timer_base + TIMER_CTRL,
> + TIMER1_RELOAD_EN | TIMER1_EN,
> + TIMER1_RELOAD_EN | TIMER1_EN);
> } else {
> /* disable timer */
> - orion_timer_ctrl_clrset(TIMER1_RELOAD_EN | TIMER1_EN, 0);
> + atomic_io_modify(timer_base + TIMER_CTRL,
> + TIMER1_RELOAD_EN | TIMER1_EN, 0);
> }
> }
>
> @@ -131,7 +121,9 @@ static void __init orion_timer_init(struct device_node *np)
> /* setup timer0 as free-running clocksource */
> writel(~0, timer_base + TIMER0_VAL);
> writel(~0, timer_base + TIMER0_RELOAD);
> - orion_timer_ctrl_clrset(0, TIMER0_RELOAD_EN | TIMER0_EN);
> + atomic_io_modify(timer_base + TIMER_CTRL,
> + TIMER0_RELOAD_EN | TIMER0_EN,
> + TIMER0_RELOAD_EN | TIMER0_EN);
> clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
> clk_get_rate(clk), 300, 32,
> clocksource_mmio_readl_down);
> --
> 1.8.1.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
From: Stephen Warren @ 2014-02-05 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-4-git-send-email-pdeschrijver@nvidia.com>
On 01/28/2014 04:36 PM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
I assume most of this code is simply cut/paste from the existing code in
arch/arm/mach-tegra/? If so, "git format-patch -C" would have been
useful to highlight what changed when duplicating the files.
> diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
> +What: /sys/devices/*/<our-device>/fuse
> +Date: December 2013
> +Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
> +Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
> + and Tegra124 SoC's from NVIDIA. The efuses contain write once
> + data programmed at the factory.
> +Users: any user space application which wants to read the efuses on
> + Tegra SoC's
Surely this file should describe the format of the file, since that's
part of the ABI too, right?
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra20.c b/drivers/misc/fuse/tegra/fuse-tegra20.c
> +static int tegra20_fuse_probe(struct platform_device *pdev)
...
> + sku_info.revision = tegra_revision;
> + tegra20_init_speedo_data(&sku_info, &pdev->dev);
...
> +}
> +
> +static struct platform_driver tegra20_fuse_driver = {
> + .probe = tegra20_fuse_probe,
> + .driver = {
> + .name = "tegra20_fuse",
> + .owner = THIS_MODULE,
> + .of_match_table = tegra20_fuse_of_match,
> + }
> +};
> +
> +static int __init tegra20_fuse_init(void)
> +{
> + return platform_driver_register(&tegra20_fuse_driver);
> +}
> +postcore_initcall(tegra20_fuse_init);
That call to tegra20_init_speedo_data() now happens much later in boot.
Are you sure there's nothing that relies on data it sets up between when
tegra_fuse_init() is called (which is where it happens before this
series), and the somewhat arbitrary later time when this driver probes?
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra30.c b/drivers/misc/fuse/tegra/fuse-tegra30.c
> +postcore_initcall(tegra30_fuse_init);
> +
There's a blank line at the end of the file. I thought checkpatch warned
about this? But actually it doesn't seem to at least in -f mode.
> diff --git a/drivers/misc/fuse/tegra/fuse.h b/drivers/misc/fuse/tegra/fuse.h
> +struct tegra_sku_info {
> + int sku_id;
> + int cpu_process_id;
> + int cpu_speedo_id;
> + int cpu_speedo_value;
> + int cpu_iddq_value;
> + int core_process_id;
> + int soc_speedo_id;
> + int gpu_speedo_id;
> + int gpu_process_id;
> + int gpu_speedo_value;
> + enum tegra_revision revision;
> +};
The only use of this appears to be to pass to tegra_fuse_create_sysfs()
which prints out the fields. Will there be more users in the future?
Otherwise, I'd be tempted to just print it out outside/before-calling
tegra_fuse_create_sysfs().
That said, I wonder if these values could/should be exposed in the sysfs
file to make it easier to interpret the fuses?
> diff --git a/drivers/misc/fuse/tegra/tegra114_speedo.c b/drivers/misc/fuse/tegra/tegra114_speedo.c
It might be nice to make these filenames consistent with the others,
e.g. fuse-speedo-tegraNNN.c/speedo-tegraNNN.c, or wrap them into
fuse-tegraNNN.c?
> diff --git a/drivers/misc/fuse/tegra/tegra30_speedo.c b/drivers/misc/fuse/tegra/tegra30_speedo.c
> +#define FUSE_SPEEDO_CALIB_0 0x14
> +#define FUSE_PACKAGE_INFO 0XFC
> +#define FUSE_TEST_PROG_VER 0X28
In arch/arm/mach-tegra/tegra30_speedo.c, those values are different:
#define FUSE_SPEEDO_CALIB_0 0x114
#define FUSE_PACKAGE_INFO 0X1FC
#define FUSE_TEST_PROG_VER 0X128
Was this change intentional? Perhaps it should be in a separate patch to
highlight the change, if it's an intentional bug-fix?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox