* [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 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] 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 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 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 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] 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 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
* [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 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
* [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
* [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 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
* [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] 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 21/22] arm: efistub: ignore dtb= when UEFI SecureBoot is enabled
From: Ard Biesheuvel @ 2014-02-05 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391619853-10601-22-git-send-email-leif.lindholm@linaro.org>
On 5 February 2014 18:04, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Loading unauthenticated FDT blobs directly from storage is a security hazard,
> so this should only be allowed when running with UEFI Secure Boot disabled.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> ---
> drivers/firmware/efi/arm-stub.c | 4 +++-
> drivers/firmware/efi/efi-stub-helper.c | 24 ++++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/arm-stub.c b/drivers/firmware/efi/arm-stub.c
> index b505fde..c651082 100644
> --- a/drivers/firmware/efi/arm-stub.c
> +++ b/drivers/firmware/efi/arm-stub.c
> @@ -95,7 +95,9 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
>
> /* Load a device tree from the configuration table, if present. */
> fdt_addr = (uintptr_t)get_fdt(sys_table);
> - if (!fdt_addr) {
> + if (efi_secureboot_enabled(sys_table))
> + pr_efi(sys_table, "UEFI Secure Boot is enabled, ignoring dtb= commandline option.\n");
I am pretty sure my original patch had braces on both branches of the if () :-)
Also, I think the precedence is backward here: dtb= should trump
config table, not the other way around.
--
Ard.
> + else if (!fdt_addr) {
> status = handle_cmdline_files(sys_table, image, cmdline_ptr,
> "dtb=",
> ~0UL, (unsigned long *)&fdt_addr,
> diff --git a/drivers/firmware/efi/efi-stub-helper.c b/drivers/firmware/efi/efi-stub-helper.c
> index 2ee69ea..6221be7 100644
> --- a/drivers/firmware/efi/efi-stub-helper.c
> +++ b/drivers/firmware/efi/efi-stub-helper.c
> @@ -721,3 +721,27 @@ static char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
> *cmd_line_len = options_bytes;
> return (char *)cmdline_addr;
> }
> +
> +static int __init efi_secureboot_enabled(efi_system_table_t *sys_table_arg)
> +{
> + static efi_guid_t const var_guid __initconst = EFI_GLOBAL_VARIABLE_GUID;
> + static efi_char16_t const var_name[] __initconst = {
> + 'S', 'e', 'c', 'u', 'r', 'e', 'B', 'o', 'o', 't', 0 };
> +
> + efi_get_variable_t *f_getvar = sys_table_arg->runtime->get_variable;
> + unsigned long size = sizeof(u8);
> + efi_status_t status;
> + u8 val;
> +
> + status = efi_call_phys5(f_getvar, (efi_char16_t *)var_name,
> + (efi_guid_t *)&var_guid, NULL, &size, &val);
> +
> + switch (status) {
> + case EFI_SUCCESS:
> + return val;
> + case EFI_NOT_FOUND:
> + return 0;
> + default:
> + return 1;
> + }
> +}
> --
> 1.7.10.4
>
^ permalink raw reply
* [alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Jean-Francois Moine @ 2014-02-05 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F2021A.9020804@metafoo.de>
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.
- snd_pcm_hw_constraint_mask64() is not exported.
Is there an other way to set constraints on the formats/sample widths?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 02/22] arm: add new asm macro update_sctlr
From: Will Deacon @ 2014-02-05 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391619853-10601-3-git-send-email-leif.lindholm@linaro.org>
On Wed, Feb 05, 2014 at 05:03:53PM +0000, Leif Lindholm wrote:
> A new macro for setting/clearing bits in the SCTLR.
>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/assembler.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Will Deacon <will.deacon@arm.com>
(although really minor comment below)
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 5c22851..e8ca24b 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -383,4 +383,18 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> #endif
> .endm
>
> +#ifdef CONFIG_CPU_CP15
> +/* Macro for setting/clearing bits in sctlr */
> + .macro update_sctlr, tmp:req, set=, clear=
> + mrc p15, 0, \tmp, c1, c0, 0
> + .ifnc \set,
> + orr \tmp, \set
I'd prefer the 3-arg form here for consistency (with this macro and the
rest of the file).
Will
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Bjorn Andersson @ 2014-02-05 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204200018.GZ22609@sirena.org.uk>
On Tue, Feb 4, 2014 at 12:00 PM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 11:09:03AM -0800, Bjorn Andersson wrote:
>
>> I have a regulator that's being configured from DT as:
>> regulator-min-microvolt = <2950000>;
>> regulator-max-microvolt = <2950000>;
>
>> In the consumer I do regulator_set_voltage(2.95V).
>
>> As min == max the voltage is applied by the regulator framework on registration
>> of the regulator; and the regulator_set_voltage() fails as
>> REGULATOR_CHANGE_VOLTAGE is not set for this regulator.
>
> 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?
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.
Regards,
Bjorn
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Jason Cooper @ 2014-02-05 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205140802.9977.19747@quantum>
On Wed, Feb 05, 2014 at 06:08:02AM -0800, Mike Turquette wrote:
> Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
> > 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.
>
> Sebastian,
>
> These patches look OK to me. I'd rather take Gregory Clement's "respect
> the clock dependencies in of_clk_init" patch towards 3.15, so this fix
> will still be necessary for the current -rc's.
>
> Jason, will you be sending a PR?
Ahh, just saw this now. ignore my previous comments about using
Gregory's series as the fix.
Sure, I'll put this together for a pr to the clk tree.
thx,
Jason.
> > 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(-)
> >
> > ---
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: Jason Cooper <jason@lakedaemon.net>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Gregory Clement <gregory.clement@free-electrons.com>
> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > --
> > 1.8.5.2
> >
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Rob Herring @ 2014-02-05 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F26444.5090707@ti.com>
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
^ permalink raw reply
* [PATCH] ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
From: Nishanth Menon @ 2014-02-05 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F26F53.20408@ti.com>
2014-02-05 Grygorii Strashko <grygorii.strashko@ti.com>:
> Hi All,
> On 02/05/2014 05:06 PM, Illia Smyrnov wrote:
>> Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
>> softreset bit cleaning right after set one. It is caused L3 error for
>> OMAP4 ISS because ISS register write occurs when ISS reset process is in
>> progress. Avoid this situation by cleaning softreset bit later, when reset
>> process is successfully finished.
>
> I'd like to mention that this issue has been caught while upgrading
> custom Linux Kernel 3.4 to the last Stable Kernel linux-3.4.y.
> So, the same OMAP4+ functionality can be broken in all Stable trees
> where commit "ARM: OMAP2+: hwmod: Fix SOFTRESET logic" was merged to.
>
> On OMAP4+ we should always try to wait until IP reset is finished before proceed.
>
> Reviewed-by: "Grygorii Strashko <grygorii.strashko@ti.com>"
>
> Error log example (k3.4):
>
Thanks - I for a moment thought it was on newer kernels :).
Looping in Dan who is currently looking at reset driver replacement
for existing hwmod based reset solution.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 05/22] Add shared printk wrapper for consistent prefixing
From: Joe Perches @ 2014-02-05 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391619853-10601-6-git-send-email-leif.lindholm@linaro.org>
On Wed, 2014-02-05 at 17:03 +0000, Leif Lindholm wrote:
> From: Roy Franz <roy.franz@linaro.org>
>
> Add a wrapper for printk to standardize the prefix for informational and
> error messages from the EFI stub.
trivia:
> diff --git a/drivers/firmware/efi/efi-stub-helper.c b/drivers/firmware/efi/efi-stub-helper.c
[]
> @@ -45,6 +45,9 @@ static void efi_printk(efi_system_table_t *sys_table_arg, char *str)
> }
> }
>
> +#define pr_efi(sys_table, msg) efi_printk(sys_table, "EFI stub: "msg)
> +#define pr_efi_err(sys_table, msg) efi_printk(sys_table, "EFI stub: ERROR: "msg)
Perhaps it'd be better to use a space after the second "
Also, maybe pr_efi should be pr_efi_info.
That would quiet any checkpatch noise around long msg uses.
^ permalink raw reply
* [GIT PULL] SOCFPGA DT updates for 3.15
From: dinguyen at altera.com @ 2014-02-05 17:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof,
Please consider pulling in these 2 patches for the enabling SD/MMC on the SOCFPGA
platform.
Thanks,
Dinh
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga-dts-for-3.15
for you to fetch changes up to e422c12bc07192289c3fec4edd457e6ffaa03b2b:
ARM: socfpga_defconfig: enable SD/MMC support (2014-02-05 11:19:34 -0600)
----------------------------------------------------------------
SOCFPGA dts updates for v3.15
----------------------------------------------------------------
Dinh Nguyen (2):
dts: socfpga: Add support for SD/MMC on the SOCFPGA platform
ARM: socfpga_defconfig: enable SD/MMC support
arch/arm/boot/dts/socfpga.dtsi | 13 ++++++++++++-
arch/arm/boot/dts/socfpga_arria5.dtsi | 11 +++++++++++
arch/arm/boot/dts/socfpga_cyclone5.dtsi | 11 +++++++++++
arch/arm/boot/dts/socfpga_vt.dts | 11 +++++++++++
arch/arm/configs/socfpga_defconfig | 2 ++
5 files changed, 47 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] mvebu : pcie: dt: potential issue in range parsing
From: Jason Cooper @ 2014-02-05 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205164710.082f689e@skate>
+ Bjorn, linux-pci
Bjorn,
It looks like this didn't get Cc'd to linux-pci. Here's a link:
http://www.spinics.net/lists/arm-kernel/msg299721.html
On Wed, Feb 05, 2014 at 04:47:10PM +0100, Thomas Petazzoni wrote:
> Dear Jean-Jacques Hiblot,
>
> On Fri, 10 Jan 2014 11:23:51 +0100, Jean-Jacques Hiblot wrote:
> > The second parameter of of_read_number is not the index, but a size.
> > As it happens, in this case it may work just fine because of the the conversion
> > to u32 and the favorable endianness on this architecture.
> >
> > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> > ---
> > drivers/pci/host/pci-mvebu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> > index c269e43..877e8ce 100644
> > --- a/drivers/pci/host/pci-mvebu.c
> > +++ b/drivers/pci/host/pci-mvebu.c
> > @@ -768,7 +768,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
> >
> > for (i = 0; i < nranges; i++) {
> > u32 flags = of_read_number(range, 1);
> > - u32 slot = of_read_number(range, 2);
> > + u32 slot = of_read_number(range + 1, 1);
> > u64 cpuaddr = of_read_number(range + na, pna);
> > unsigned long rtype;
> >
>
> Sorry for the long delay, and thanks for the fix!
>
> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> (on Armada 370, with PCIe cards plugged in)
Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Cc: <stable@vger.kernel.org> # v3.12+
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ 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