* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-08 19:59 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Stewart Smith,
devicetree, linux-kernel, linux-mm, Alistair Popple,
Aneesh Kumar K.V, Bharata B Rao, Nathan Fontenot, linuxppc-dev
In-Reply-To: <201611080920.t1iTxguA%fengguang.wu@intel.com>
On Tue, Nov 08, 2016 at 09:59:26AM +0800, kbuild test robot wrote:
>All errors (new ones prefixed by >>):
>
> drivers/of/fdt.c: In function 'early_init_dt_scan_memory':
>>> drivers/of/fdt.c:1064:3: error: implicit declaration of function 'memblock_mark_hotplug'
> cc1: some warnings being treated as errors
>
>vim +/memblock_mark_hotplug +1064 drivers/of/fdt.c
>
> 1058 continue;
> 1059 pr_debug(" - %llx , %llx\n", (unsigned long long)base,
> 1060 (unsigned long long)size);
> 1061
> 1062 early_init_dt_add_memory_arch(base, size);
> 1063
>> 1064 if (hotpluggable && memblock_mark_hotplug(base, size))
> 1065 pr_warn("failed to mark hotplug range 0x%llx - 0x%llx\n",
> 1066 base, base + size);
> 1067 }
Ah, I need to adjust for !CONFIG_HAVE_MEMBLOCK. Will correct in v7.
--
Reza Arbab
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: sunxi: Add support for interrupt debouncing
From: Maxime Ripard @ 2016-11-08 19:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, Rob Herring, Chen-Yu Tsai
In-Reply-To: <CACRpkdZ40e03VV_ScKceahG-7jmFmbBmgCqxBv9bGcvS3TnrOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
On Mon, Nov 07, 2016 at 10:40:04AM +0100, Linus Walleij wrote:
> On Wed, Nov 2, 2016 at 8:51 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Oct 20, 2016 at 03:56:25PM +0200, Maxime Ripard wrote:
> >> On Thu, Oct 20, 2016 at 03:04:46PM +0200, Linus Walleij wrote:
> >> > On Wed, Oct 19, 2016 at 11:15 AM, Maxime Ripard
> >> > <maxime.ripard@free-electrons.com> wrote:
> >> >
> >> > > The pin controller found in the Allwinner SoCs has support for interrupts
> >> > > debouncing.
> >> > >
> >> > > However, this is not done per-pin, preventing us from using the generic
> >> > > pinconf binding for that,
> >> >
> >> > How typical.
> >> >
> >> > > but per irq bank, which, depending on the SoC,
> >> > > ranges from one to five.
> >> > >
> >> > > Introduce a device-wide property to deal with this using a nanosecond
> >> > > resolution.
> >> > >
> >> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> > (...)
> >> > > +Note: For backward compatibility reasons, the hosc and losc clocks are
> >> > > +only required if you need to use the optional
> >> > > +allwinner,debounce-time-ns property. Any new device tree should set them.
> >> > > +
> >> > > +Optional properties:
> >> > > + - allwinner,debounce-time-ns: Array of debouncing periods in
> >> > > + nanoseconds. One period per irq bank found in the controller
> >> >
> >> > Do you really *need* to specify this with nanosecond resolution?
> >> >
> >> > Else I would suggest to use microsecond resolution and just use
> >> > the generic binding (input-debounce) but on the device node instead
> >> > of the specific handler.
> >>
> >> Theorically, the debouncing clock can be set at 24MHz, which means a
> >> 42ns resolution.
> >>
> >> I've seen that the other bindings usually use microseconds, but in our
> >> case, we can really go lower than that.
> >>
> >> I don't really know if it makes sense though.
> >
> > Any comments on this?
>
> My first thought: can you atleast support both?
>
> My preference would be to add the standard binding and use that,
> and the day you realize that "howli mackarowli, this thingofabob
> actually needs to specify with nanosecond precision" then we
> could add the nanosecond granularity binding?
That works for me. I'll resend the patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Bjorn Andersson @ 2016-11-08 19:13 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1478622577-20699-2-git-send-email-srinivas.kandagatla@linaro.org>
On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 1dbe697..fde006c 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -627,6 +627,34 @@
> clock-names = "core";
> };
>
> + qcom,ssbi@c00000 {
No "qcom," in the node name.
> + compatible = "qcom,ssbi";
> + reg = <0x00c00000 0x1000>;
> + qcom,controller-type = "pmic-arbiter";
> +
> + pmicintc2: pmic@1 {
I think we should follow Linus' lead and label this "pm8821".
> + compatible = "qcom,pm8821";
> + interrupt-parent = <&tlmm_pinmux>;
> + interrupts = <76 8>;
Please spell out IRQ_TYPE_LEVEL_LOW.
And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
the two lines nicely.
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pm8821_mpps: mpps@50 {
> +
Extra newline.
> + compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
> + reg = <0x50>;
> +
> + interrupts = <24 1>, <25 1>, <26 1>,
> + <27 1>;
I think these should be IRQ_TYPE_NONE per the discussion on how to share
interrupts between the gpio/mpp driver and other clients.
On the other hand, per the pm8821 driver we only support LEVEL_LOW
(high?).
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> + };
> +
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 1/2] mfd: pm8921: add support to pm8821
From: Bjorn Andersson @ 2016-11-08 19:07 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1478622577-20699-1-git-send-email-srinivas.kandagatla@linaro.org>
On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>
Linus Walleij has a patch out for renaming a lot of things in this file,
so we should probably make sure that lands and then rebase this ontop.
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> Tested this patch for MPP and IRQ functionality on IFC6410 and SD600 EVAL
> board with mpps PM8821 and PM8921.
>
> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
> drivers/mfd/pm8921-core.c | 368 +++++++++++++++++++--
> 2 files changed, 340 insertions(+), 29 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..8f1b4ec 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
> Definition: must be one of:
> "qcom,pm8058"
> "qcom,pm8921"
> + "qcom,pm8821"
>
> - #address-cells:
> Usage: required
> diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
> index 0e3a2ea..28c2470 100644
> --- a/drivers/mfd/pm8921-core.c
> +++ b/drivers/mfd/pm8921-core.c
> @@ -28,16 +28,26 @@
> #include <linux/mfd/core.h>
>
> #define SSBI_REG_ADDR_IRQ_BASE 0x1BB
> -
> -#define SSBI_REG_ADDR_IRQ_ROOT (SSBI_REG_ADDR_IRQ_BASE + 0)
> -#define SSBI_REG_ADDR_IRQ_M_STATUS1 (SSBI_REG_ADDR_IRQ_BASE + 1)
> -#define SSBI_REG_ADDR_IRQ_M_STATUS2 (SSBI_REG_ADDR_IRQ_BASE + 2)
> -#define SSBI_REG_ADDR_IRQ_M_STATUS3 (SSBI_REG_ADDR_IRQ_BASE + 3)
> -#define SSBI_REG_ADDR_IRQ_M_STATUS4 (SSBI_REG_ADDR_IRQ_BASE + 4)
> -#define SSBI_REG_ADDR_IRQ_BLK_SEL (SSBI_REG_ADDR_IRQ_BASE + 5)
> -#define SSBI_REG_ADDR_IRQ_IT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 6)
> -#define SSBI_REG_ADDR_IRQ_CONFIG (SSBI_REG_ADDR_IRQ_BASE + 7)
> -#define SSBI_REG_ADDR_IRQ_RT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 8)
Keep these (per argumentation that follows), but try to name them
appropriately.
> +#define SSBI_PM8821_REG_ADDR_IRQ_BASE 0x100
> +
> +#define SSBI_REG_ADDR_IRQ_ROOT (0)
> +#define SSBI_REG_ADDR_IRQ_M_STATUS1 (1)
> +#define SSBI_REG_ADDR_IRQ_M_STATUS2 (2)
> +#define SSBI_REG_ADDR_IRQ_M_STATUS3 (3)
> +#define SSBI_REG_ADDR_IRQ_M_STATUS4 (4)
> +#define SSBI_REG_ADDR_IRQ_BLK_SEL (5)
> +#define SSBI_REG_ADDR_IRQ_IT_STATUS (6)
> +#define SSBI_REG_ADDR_IRQ_CONFIG (7)
> +#define SSBI_REG_ADDR_IRQ_RT_STATUS (8)
Unnecessary parenthesis.
> +
> +#define PM8821_TOTAL_IRQ_MASTERS 2
Unused.
> +#define PM8821_BLOCKS_PER_MASTER 7
> +#define PM8821_IRQ_MASTER1_SET 0x01
BIT(0), but I would prefer that you just inline this with a comment.
> +#define PM8821_IRQ_CLEAR_OFFSET 0x01
Rather than having a single define for this and add in the base and
block numbers I think you should split it into a master0 and master1
define. (And it's not a offset as much as a register)
> +#define PM8821_IRQ_RT_STATUS_OFFSET 0x0f
Dito
> +#define PM8821_IRQ_MASK_REG_OFFSET 0x08
Dito
> +#define SSBI_REG_ADDR_IRQ_MASTER0 0x30
> +#define SSBI_REG_ADDR_IRQ_MASTER1 0xb0
Fold these two into the registers above.
>
> #define PM_IRQF_LVL_SEL 0x01 /* level select */
> #define PM_IRQF_MASK_FE 0x02 /* mask falling edge */
> @@ -54,30 +64,41 @@
> #define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
>
> #define PM8921_NR_IRQS 256
> +#define PM8821_NR_IRQS 112
>
> struct pm_irq_chip {
> struct regmap *regmap;
> spinlock_t pm_irq_lock;
> struct irq_domain *irqdomain;
> + unsigned int irq_reg_base;
> unsigned int num_irqs;
> unsigned int num_blocks;
> unsigned int num_masters;
> u8 config[0];
> };
>
> +struct pm8xxx_data {
> + int num_irqs;
> + unsigned int irq_reg_base;
As far as I can see this is always SSBI_PM8821_REG_ADDR_IRQ_BASE in the
8821 functions and SSBI_REG_ADDR_IRQ_BASE in the pm8xxx functions. If
you have disjunct code paths I think it's better to not obscure this
with a variable.
Try renaming the constants appropriately instead. This also has the
benefit of reducing the size of the patch slightly.
> + const struct irq_domain_ops *irq_domain_ops;
> + void (*irq_handler)(struct irq_desc *desc);
> +};
> +
> static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
> unsigned int *ip)
> {
> int rc;
>
> spin_lock(&chip->pm_irq_lock);
> - rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> + rc = regmap_write(chip->regmap,
> + chip->irq_reg_base + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> if (rc) {
> pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
> goto bail;
> }
>
> - rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
> + rc = regmap_read(chip->regmap,
> + chip->irq_reg_base + SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
> if (rc)
> pr_err("Failed Reading Status rc=%d\n", rc);
> bail:
> @@ -91,14 +112,16 @@ pm8xxx_config_irq(struct pm_irq_chip *chip, unsigned int bp, unsigned int cp)
> int rc;
>
> spin_lock(&chip->pm_irq_lock);
> - rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> + rc = regmap_write(chip->regmap,
> + chip->irq_reg_base + SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> if (rc) {
> pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
> goto bail;
> }
>
> cp |= PM_IRQF_WRITE;
> - rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_CONFIG, cp);
> + rc = regmap_write(chip->regmap,
> + chip->irq_reg_base + SSBI_REG_ADDR_IRQ_CONFIG, cp);
> if (rc)
> pr_err("Failed Configuring IRQ rc=%d\n", rc);
> bail:
> @@ -137,8 +160,8 @@ static int pm8xxx_irq_master_handler(struct pm_irq_chip *chip, int master)
> unsigned int blockbits;
> int block_number, i, ret = 0;
>
> - ret = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_M_STATUS1 + master,
> - &blockbits);
> + ret = regmap_read(chip->regmap, chip->irq_reg_base +
> + SSBI_REG_ADDR_IRQ_M_STATUS1 + master, &blockbits);
> if (ret) {
> pr_err("Failed to read master %d ret=%d\n", master, ret);
> return ret;
> @@ -165,7 +188,8 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
>
> chained_irq_enter(irq_chip, desc);
>
> - ret = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_ROOT, &root);
> + ret = regmap_read(chip->regmap,
> + chip->irq_reg_base + SSBI_REG_ADDR_IRQ_ROOT, &root);
> if (ret) {
> pr_err("Can't read root status ret=%d\n", ret);
> return;
> @@ -182,6 +206,122 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
> chained_irq_exit(irq_chip, desc);
> }
>
> +static int pm8821_read_master_irq(const struct pm_irq_chip *chip,
> + int m, unsigned int *master)
> +{
I think you should inline this, as you already have the calls unrolled
in pm8821_irq_handler().
> + unsigned int base;
> +
> + if (!m)
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
> + else
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
> +
> + return regmap_read(chip->regmap, base, master);
> +}
> +
> +static int pm8821_read_block_irq(struct pm_irq_chip *chip, int master,
> + u8 block, unsigned int *bits)
> +{
> + int rc;
> +
> + unsigned int base;
Odd empty line between rc and base. (And btw, sorting your local
variables in descending length make things pretty).
> +
> + if (!master)
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
> + else
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
> +
> + spin_lock(&chip->pm_irq_lock);
The reason why this is done under a lock in the other case is because
the status register is paged, so you shouldn't need it here.
With this updated I think you can favorably inline this into
pm8821_irq_block_handler().
> +
> + rc = regmap_read(chip->regmap, base + block, bits);
> + if (rc)
> + pr_err("Failed Reading Status rc=%d\n", rc);
> +
> + spin_unlock(&chip->pm_irq_lock);
> + return rc;
> +}
> +
> +static int pm8821_irq_block_handler(struct pm_irq_chip *chip,
> + int master_number, int block)
> +{
> + int pmirq, irq, i, ret;
> + unsigned int bits;
> +
> + ret = pm8821_read_block_irq(chip, master_number, block, &bits);
> + if (ret) {
> + pr_err("Failed reading %d block ret=%d", block, ret);
> + return ret;
> + }
> + if (!bits) {
> + pr_err("block bit set in master but no irqs: %d", block);
> + return 0;
> + }
> +
> + /* Convert block offset to global block number */
> + block += (master_number * PM8821_BLOCKS_PER_MASTER) - 1;
So this is block -= 1 for master 0 and block += 6 for master 1, is the
latter correct?
> +
> + /* Check IRQ bits */
> + for (i = 0; i < 8; i++) {
> + if (bits & BIT(i)) {
> + pmirq = block * 8 + i;
> + irq = irq_find_mapping(chip->irqdomain, pmirq);
> + generic_handle_irq(irq);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int pm8821_irq_read_master(struct pm_irq_chip *chip,
> + int master_number, u8 master_val)
This isn't so much a matter of "reading master X" as "handle master X".
Also, you don't care about the return value, so no need to return one...
> +{
> + int ret = 0;
> + int block;
> +
> + for (block = 1; block < 8; block++) {
> + if (master_val & BIT(block)) {
> + ret |= pm8821_irq_block_handler(chip,
> + master_number, block);
> + }
> + }
> +
> + return ret;
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + int ret;
> + unsigned int master;
> +
> + chained_irq_enter(irq_chip, desc);
> + /* check master 0 */
> + ret = pm8821_read_master_irq(chip, 0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> + return;
> + }
> +
> + if (master & ~PM8821_IRQ_MASTER1_SET)
Rather than having a define for MASTER1_SET use BIT(0) here and write a
comment like:
"bits 1 through 7 marks the first 7 blocks"
> + pm8821_irq_read_master(chip, 0, master);
> +
and then
"bit 0 is set if second master contains any bits"
Or just skip this optimization and check the two masters unconditionally
in a loop.
> + /* check master 1 */
> + if (!(master & PM8821_IRQ_MASTER1_SET))
> + goto done;
> +
> + ret = pm8821_read_master_irq(chip, 1, &master);
> + if (ret) {
> + pr_err("Failed to read master 1 ret=%d\n", ret);
> + return;
> + }
> +
> + pm8821_irq_read_master(chip, 1, master);
> +
> +done:
> + chained_irq_exit(irq_chip, desc);
> +}
> +
> static void pm8xxx_irq_mask_ack(struct irq_data *d)
> {
> struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> @@ -254,13 +394,15 @@ static int pm8xxx_irq_get_irqchip_state(struct irq_data *d,
> irq_bit = pmirq % 8;
>
> spin_lock(&chip->pm_irq_lock);
> - rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, block);
> + rc = regmap_write(chip->regmap, chip->irq_reg_base +
> + SSBI_REG_ADDR_IRQ_BLK_SEL, block);
> if (rc) {
> pr_err("Failed Selecting Block %d rc=%d\n", block, rc);
> goto bail;
> }
>
> - rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
> + rc = regmap_read(chip->regmap, chip->irq_reg_base +
> + SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
> if (rc) {
> pr_err("Failed Reading Status rc=%d\n", rc);
> goto bail;
> @@ -299,6 +441,151 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
> .map = pm8xxx_irq_domain_map,
> };
>
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int base, pmirq = irqd_to_hwirq(d);
> + u8 block, master;
> + int irq_bit, rc;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
You can deobfuscate this somewhat by instead of testing for !master
below you just do:
if (block < PM8821_BLOCKS_PER_MASTER) {
base =
} else {
base =
block -= PM8821_BLOCKS_PER_MASTER;
}
> +
> + if (!master)
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
> + else
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
> +
> + spin_lock(&chip->pm_irq_lock);
The irqchip code grabs a lock on the irq_desc, so this can't race with
unmask - and the regmap_update_bits() is internally protecting the
read/write cycle.
So you shouldn't need to lock around this section.
> + rc = regmap_update_bits(chip->regmap,
> + base + PM8821_IRQ_MASK_REG_OFFSET + block,
> + BIT(irq_bit), BIT(irq_bit));
> +
> + if (rc) {
> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
> + goto fail;
> + }
> +
> + rc = regmap_update_bits(chip->regmap,
> + base + PM8821_IRQ_CLEAR_OFFSET + block,
> + BIT(irq_bit), BIT(irq_bit));
> +
> + if (rc) {
> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
> + pmirq, rc);
> + }
> +
> +fail:
> + spin_unlock(&chip->pm_irq_lock);
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int base, pmirq = irqd_to_hwirq(d);
> + int irq_bit, rc;
> + u8 block, master;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
As mask().
> +
> + if (!master)
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
> + else
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
> +
> + spin_lock(&chip->pm_irq_lock);
As mask().
> +
> + rc = regmap_update_bits(chip->regmap,
> + base + PM8821_IRQ_MASK_REG_OFFSET + block,
> + BIT(irq_bit), ~BIT(irq_bit));
> +
> + if (rc)
> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
> +
> + spin_unlock(&chip->pm_irq_lock);
> +}
> +
> +static int pm8821_irq_set_type(struct irq_data *d, unsigned int flow_type)
> +{
> +
> + /*
> + * PM8821 IRQ controller does not have explicit software support for
> + * IRQ flow type.
> + */
Is returning "success" here the right thing to do? Shouldn't we just
omit the function? Or did you perhaps hit some clients that wouldn't
deal with that?
> + return 0;
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool *state)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + int pmirq, rc;
> + u8 block, irq_bit, master;
> + unsigned int bits;
> + unsigned int base;
> + unsigned long flags;
> +
> + pmirq = irqd_to_hwirq(d);
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
Simplify as in mask().
> + if (!master)
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
> + else
> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
> +
> + spin_lock_irqsave(&chip->pm_irq_lock, flags);
No need to lock here as we're just reading a single register.
> +
> + rc = regmap_read(chip->regmap,
> + base + PM8821_IRQ_RT_STATUS_OFFSET + block, &bits);
> + if (rc) {
> + pr_err("Failed Reading Status rc=%d\n", rc);
> + goto bail_out;
> + }
> +
> + *state = !!(bits & BIT(irq_bit));
> +
> +bail_out:
> + spin_unlock_irqrestore(&chip->pm_irq_lock, flags);
> +
> + return rc;
> +}
> +
> +static struct irq_chip pm8821_irq_chip = {
> + .name = "pm8821",
> + .irq_mask_ack = pm8821_irq_mask_ack,
> + .irq_unmask = pm8821_irq_unmask,
> + .irq_set_type = pm8821_irq_set_type,
> + .irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
> + .flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
> +};
> +
Regards,
Bjorn
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: add usb device node
From: Axel Haslam @ 2016-11-08 18:58 UTC (permalink / raw)
To: gregkh, stern, nsekhar, khilman, david, robh+dt
Cc: linux-usb, linux-kernel, linux-arm-kernel, devicetree,
Axel Haslam
In-Reply-To: <20161108185831.17683-1-ahaslam@baylibre.com>
This adds the ohci device node for the da850 soc.
It also enables it for the omapl138 hawk board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 8 ++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..aaf533e 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -86,6 +86,14 @@
};
};
+&usb_phy {
+ status = "okay";
+};
+
+&ohci {
+ status = "okay";
+};
+
&serial2 {
pinctrl-names = "default";
pinctrl-0 = <&serial2_rxtx_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 2534aab..c74f1a6 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -405,6 +405,14 @@
>;
status = "disabled";
};
+ ohci: usb@225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ status = "disabled";
+ };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] USB: ohci: da8xx: Allow probing from DT
From: Axel Haslam @ 2016-11-08 18:58 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, nsekhar-l0cyMroinI0,
khilman-DgEjT+Ai2ygdnm+yROfE0A, david-nq/r/kbU++upp/zk7JDF2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Axel Haslam
In-Reply-To: <20161108185831.17683-1-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
This adds the compatible string to the ohci driver
to be able to probe from DT
Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/usb/host/ohci-da8xx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 83b182e..bbfe342 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -321,6 +321,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
}
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_ohci_ids[] = {
+ { .compatible = "ti,da830-ohci" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da8xx_ohci_ids);
+#endif
static int ohci_da8xx_probe(struct platform_device *pdev)
{
@@ -472,6 +479,7 @@ static struct platform_driver ohci_hcd_da8xx_driver = {
#endif
.driver = {
.name = DRV_NAME,
+ .of_match_table = of_match_ptr(da8xx_ohci_ids),
},
};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/3] USB: ohci: da8xx: Add devicetree bindings
From: Axel Haslam @ 2016-11-08 18:58 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, nsekhar-l0cyMroinI0,
khilman-DgEjT+Ai2ygdnm+yROfE0A, david-nq/r/kbU++upp/zk7JDF2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Axel Haslam
In-Reply-To: <20161108185831.17683-1-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
This patch documents the device tree bindings required for
the ohci controller found in TI da8xx family of SoC's
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/usb/ohci-da8xx.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
new file mode 100644
index 0000000..66672e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
@@ -0,0 +1,39 @@
+DA8XX USB OHCI controller
+
+Required properties:
+
+ - compatible: Should be "ti,da830-ohci"
+ - reg: Should contain one register range i.e. start and length
+ - interrupts: Description of the interrupt line
+ - phys: Phandle for the PHY device
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+ - vbus-supply: Regulator that controls vbus power
+
+Example:
+
+reg_usb_ohci: regulator@0 {
+ compatible = "regulator-fixed";
+ gpio = <&gpio 109 0>;
+ over-current-gpios = <&gpio 36 0>;
+ regulator-boot-on;
+ enable-active-high;
+ regulator-name = "usb_ohci_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+};
+
+usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+};
+
+ohci: usb@0225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ vbus-supply = <®_usb_ohci>;
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] [PART 4/4] USB: ohci-da8xx: Add DT support
From: Axel Haslam @ 2016-11-08 18:58 UTC (permalink / raw)
To: gregkh, stern, nsekhar, khilman, david, robh+dt
Cc: linux-usb, linux-kernel, linux-arm-kernel, devicetree,
Axel Haslam
This series defines the bindings and adds device tree support
for the davinci OHCI driver.
DEPENDENCIES:
1. [PATCH 0/3] fix ohci phy name
https://lkml.org/lkml/2016/11/2/208
2. [PATCH/RFC v2 0/3] regulator: handling of error conditions for usb drivers
https://lkml.org/lkml/2016/11/3/188
3. [PATCH v4 0/3] [PART 1/4] USB: ohci-da8xx: Allow a regulator for VBUS and over current
4. [PATCH 0/3] [PART 2/4] ARM: davinci: OHCI: Use a regulator instead of callbacks
5. [PATCH 0/2] [PART 3/4] USB: ohci-da8xx: Remove platform callbacks
A branch with all the dependencies can be found here:
https://github.com/axelhaslamx/linux-axel/commits/ohci-da8xx-dt-v4
Axel Haslam (3):
USB: ohci: da8xx: Add devicetree bindings
USB: ohci: da8xx: Allow probing from DT
ARM: dts: da850: add usb device node
.../devicetree/bindings/usb/ohci-da8xx.txt | 39 ++++++++++++++++++++++
arch/arm/boot/dts/da850-lcdk.dts | 8 +++++
arch/arm/boot/dts/da850.dtsi | 8 +++++
drivers/usb/host/ohci-da8xx.c | 8 +++++
4 files changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
--
2.10.1
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Maxime Ripard @ 2016-11-08 18:47 UTC (permalink / raw)
To: Hao Zhang
Cc: mark.rutland, devicetree, catalin.marinas, will.deacon,
linux-kernel, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20161107182247.GA3669@arx12>
[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]
Hi,
On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote:
> This adds the dma node for sun50i a64.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e3c3d7d8..855ae2c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -227,6 +227,15 @@
> };
> };
>
> + dma: dma-controller@01c02000 {
Please order the nodes by base adress, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator
From: Thomas Gleixner @ 2016-11-08 18:38 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, Daniel Baluta, Slawomir Stepien, linux-iio,
devicetree
In-Reply-To: <d8237286-d2ff-3146-d718-f54d05b0101d@axentia.se>
On Tue, 8 Nov 2016, Peter Rosin wrote:
> On 2016-11-08 16:59, Thomas Gleixner wrote:
> > So you need that whole dance including the delayed work because you cannot
> > call iio_write_channel_raw() from hard interrupt context, right?
>
> It's not the "cannot call from hard irq context" that made me do that, it's..
Well, what guarantees you that the DAC is writeable from IRQ context? It
might be hanging off an i2c/spi bus as well....
> > The core will mask the interrupt line until the threaded handler is
> > finished. The threaded handler is invoked with preemption enabled, so you
> > can sleep there as long as you want. So you can do everything in your
> > handler and the above dance is just not required.
>
> ...that I couldn't work out how to reenable a oneshot irq once it had fired,
> short of freeing the irq and requesting it again. That seemed entirely
> bogus, the driver shouldn't risk losing a resource like that so I don't know
> what I didn't see? Or maybe it was that I had a hard time resolving the race
> between the irq and the timeout in a nice way. I honestly don't remember
> why exactly I abandoned oneshot irqs, but this enable/sync/enable dance
> was much nicer than what I came up with for the oneshot irq solution I
> originally worked on.
Threaded ONESHOT irqs work this way:
interrupt fires
mask interrupt
handler thread is woken
handler thread runs
invokes isr
unmask interrupt
So if you rewrite the DAC to the new value in your ISR, then you should not
get any spurious interrupt.
Note, that this only works for level type interrupts.
We do not mask edge type interrupts as we might lose an edge, but if that
helps the cause of your problem it's simple enough to make it conditionally
doing so in the core.
> Or maybe I had problems with the possibly pending irq also when using a
> oneshot irq, but didn't realize it? That was something I discovered quite
> late in the process, some time after moving away from oneshot irqs. Are
> pending irqs cleared when requesting (or reenabling, however that is done)
> a oneshot irq?
Pending irqs are only replayed, when you reenable an interrupt via
enable_irq(). That can happen either by software or by hardware.
> Anyway, I do not want the interrupt to be serviced when no one is interested,
> since I'm afraid that nasty input might generate a flood of interrupts that
> might disturb other things that the cpu is doing. Which means that I need
> to enable/disable the interrupt as needed.
So the main issue I'm seing here, is that your comparator does not have
means to prevent it from firing interrupts.
> However, what *I* thought Jonathan wanted input on was the part where the
> interrupt edge/level is flipped when requesting "inverted" signals in
> envelope_store_invert(). That could perhaps be seen as unorthodox and in
> need of more eyes?
Flipping the dectection level of the interrupt is fine, but what's the
guarantee that it is correct in the first place? I don't see anything which
makes that sure at all. Aside of that this bit does not makes sense:
> + env->comp_irq_trigger = irq_get_trigger_type(env->comp_irq);
> + if (env->comp_irq_trigger & IRQF_TRIGGER_RISING)
> + env->comp_irq_trigger_inv |= IRQF_TRIGGER_FALLING;
What's the |= about?
> + if (env->comp_irq_trigger & IRQF_TRIGGER_FALLING)
and this should be 'else if'. If the interrupt is configured for both
edges, which is possible with some interrupt controllers then the whole
thing does not work at all.
> + env->comp_irq_trigger_inv |= IRQF_TRIGGER_RISING;
> + if (env->comp_irq_trigger & IRQF_TRIGGER_HIGH)
> + env->comp_irq_trigger_inv |= IRQF_TRIGGER_LOW;
> + if (env->comp_irq_trigger & IRQF_TRIGGER_LOW)
> + env->comp_irq_trigger_inv |= IRQF_TRIGGER_HIGH;
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Corey Minyard @ 2016-11-08 18:15 UTC (permalink / raw)
To: Cédric Le Goater, Arnd Bergmann
Cc: Joel Stanley, openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benjamin Herrenschmidt
In-Reply-To: <a886778e-a85e-758e-3a61-c4909652e39d-Bxea+6Xhats@public.gmane.org>
On 11/08/2016 09:52 AM, Cédric Le Goater wrote:
> O
snip
>>>> While we're modifying the binding, should we add a compat string for
>>>> the ast2500?
>>> Well, if the change in this patch is fine for all, may be we can add
>>> the ast2500 compat string in a followup patch ?
>> Sounds good to me.
> OK. So, how do we proceed with this patch ? Who would include it in its
> tree ?
I don't have anything for 4.9 at the moment. Arnd, if you have
something, can
you take this? Otherwise I will.
And I guess I should add:
Acked-by: Corey Minyard <cminyard-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
-corey
> Thanks,
>
> C.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-08 17:48 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Caesar Wang,
Shawn Lin, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Russell King,
Matthias Brugger, Wei Xu, Andy Yan, Mark Rutland, Will Deacon,
Catalin Marinas, Heiko Stuebner
In-Reply-To: <87wpgeibdh.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>> Add a vendor prefix and make the name more consistent by renaming it to
>> "snps,gadget-dma-enable".
>>
>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>> drivers/usb/dwc2/params.c | 9 ++++++++-
>> drivers/usb/dwc2/pci.c | 2 +-
>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 9472111..389a461 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>> Refer to usb/generic.txt
>> - snps,host-dma-disable: disable host DMA mode.
>> -- g-use-dma: enable dma usage in gadget driver.
>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>
> I don't see why you even have this binding. Looking through the code,
> you have:
>
> #define GHWCFG2_SLAVE_ONLY_ARCH 0
> #define GHWCFG2_EXT_DMA_ARCH 1
> #define GHWCFG2_INT_DMA_ARCH 2
>
> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
> {
> int valid = 1;
>
> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
> valid = 0;
> if (val < 0)
> valid = 0;
>
> if (!valid) {
> if (val >= 0)
> dev_err(hsotg->dev,
> "%d invalid for dma_enable parameter. Check HW configuration.\n",
> val);
> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
> }
>
> hsotg->core_params->dma_enable = val;
> }
>
> which seems to hint that DMA support is discoverable. If there is DMA,
> why would disable it?
>
Yes that's the case and I would prefer to make it discoverable and
enabled by default.
But the legacy behavior has always been like this because DMA was
never fully implemented in the gadget driver and it was an opt-in
feature. Periodic support was only added recently.
What do you think about enabling it by default now? I think most
platforms already use DMA.
We would still need a "disable" binding for IP validation purposes at
least.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 17:46 UTC (permalink / raw)
To: Sudeep Holla
Cc: Philippe Robin, devicetree, Neil Armstrong, linux-kernel,
Olof Johansson, linux-amlogic, linux-arm-kernel
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>
On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>
>
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE: Booting Trusted Firmware
> >NOTICE: BL1: v1.0(release):14b6608
> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL2
> >NOTICE: BL2: v1.0(release):14b6608
> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL3-1
> >NOTICE: BL3-1: v1.0(release):14b6608
> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
>
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.
Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)
> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
>
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
>
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.) "devices" shows nothing that's even remotely English.
> >
>
> I think startup.nsh needs some edits. Just replace it with something like:
>
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
>
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
>
> flash> eraseall
I've tried that, it still stops at the same point, after:
FV2 Hob 0xFE07B000 - 0xFE8253BF
and remains unresponsive.
I do notice that the uSD card becomes visible through USB at this point
though.
Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-08 17:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Philippe Robin
Cc: Sudeep Holla, devicetree, Neil Armstrong, linux-kernel,
Olof Johansson, linux-amlogic, linux-arm-kernel
In-Reply-To: <20161108160625.GU1041@n2100.armlinux.org.uk>
On 08/11/16 16:06, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> As it contains a zero sized Image and .dtb files, I tried copying my
>> Image and .dtb over, and also copied my original config.txt (only
>> change is AUTORUN: FALSE). It still doesn't appear to boot beyond
>> this point.
>
> Well, it seems that I can't even go back to my original set of firmware
> as UEFI has stopped working:
>
> NOTICE: Booting Trusted Firmware
> NOTICE: BL1: v1.0(release):14b6608
> NOTICE: BL1: Built : 14:15:51, Sep 1 2014
> NOTICE: BL1: Booting BL2
> NOTICE: BL2: v1.0(release):14b6608
> NOTICE: BL2: Built : 14:15:51, Sep 1 2014
> NOTICE: BL1: Booting BL3-1
> NOTICE: BL3-1: v1.0(release):14b6608
> NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
> UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> Warning: Fail to load FDT file 'juno.dtb'.
>
This again because of incompatibility of the configuration data saved in
NOR flash. The erase command I gave early is to erase that when you
switched between the UEFI binaries. It's really horrible mess UEFI
created in the initial days of Juno, and hopefully they have moved to
some standard format these days.
> and UEFI is the most unfriendly thing going - the "boot manager" thing
> doesn't let you view the configuration:
>
I completely agree. I had real bad times in past dealing with such
things in UEFI.
> [1] Linux from NOR Flash
> [2] Shell
> [3] Boot Manager
> Start: 3
> [1] Add Boot Device Entry
> [2] Update Boot Device Entry
> [3] Remove Boot Device Entry
> [4] Reorder Boot Device Entries
> [5] Update FDT path
> [6] Set Boot Timeout
> [7] Return to main menu
> Choice:
>
> and dropping into the shell... well, I've no idea how to get a listing
> of what it thinks is in the NOR device (or even how to refer to the
> NOR device.) "devices" shows nothing that's even remotely English.
>
I think startup.nsh needs some edits. Just replace it with something like:
"norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
alike. Currently it just echos and stops.
Regarding the new firmware stopping abruptly, I have no clue, except
asking you to erase the flash completely when switching between the
firmware versions. That has worked for me for all UEFI related issues in
the past. It's really annoying I understand.
flash> eraseall
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w @ 2016-11-08 17:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Vladimir Zapolskiy, marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ,
stefan-XLVq0VzYD2Y,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <3d2b6dfd-c03c-e635-8dc1-2dc9ac454f5a-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hello Shawn,
On 16-10-22 15:43:04, Vladimir Zapolskiy wrote:
> Hi Shawn,
>
> On 10/22/2016 06:25 AM, Shawn Guo wrote:
> > On Mon, Sep 19, 2016 at 10:41:51AM +0530, Sanchayan Maity wrote:
> > > Remove the use of DDC I2C bus bitbang to support reading of EDID
> > > and rely on support from internal HDMI I2C master controller instead.
> > > As a result remove the device tree property ddc-i2c-bus.
> > >
> > > Signed-off-by: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> > I think that the dw-hdmi i2c support [1] is a prerequisite of this
> > patch. I do not see it lands on v4.9-rc1. Or am I missing something?
> >
> > Shawn
> >
> > [1] https://patchwork.kernel.org/patch/9296883/
> >
>
> I'm adding Philipp to Cc, since he is the last one who tested the change
> and helped me to push the change to the mainline:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-September/118569.html
>
> The problem is that there is no official DW HDMI bridge maintainer, may be
> you can review the change, and if you find it satisfactory push it through
> ARM/iMX tree.
Shawn, is it okay if that patch goes through your ARM/iMX tree?
- Sanchayan.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-08 17:30 UTC (permalink / raw)
To: Moritz Fischer, Marek Vasut
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <CAAtXAHe_pz=oUpeP+t-Fy0z88LMmTeSffkD2Cbun3r+uTnmGYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>>> On the whole, I don't think the zero-length transfers are too
>>> egregiously bad, and all the alternatives seem worse to me.
>>
>> So why not turn the CS line into GPIO and just toggle the GPIO?
>
> Does that work with *all* SPI controllers?
>
It does not - no. See my other email.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-11-08 17:13 UTC (permalink / raw)
To: Marek Vasut, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <4bdba358-db18-48f1-3286-a7a7f4c30215-ynQEQJNshbs@public.gmane.org>
Hi Marek,
>>> Should be this way for the sake of readability, fix globally:
>>>
>>> struct spi_transfer assert_cs_then_reset_delay = {
>>> .cs_change = 1,
>>> .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
>>> };
>>
>> Sure ok. Personally, I prefer it to be concise, but I'm happy to accept
>> the norms.
>
> I prefer it to be readable :)
>
I'll conform to what you're saying.
But I just want to point out that this...
spi_message_add_tail(&(struct spi_transfer){.cs_change = 1,
.delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY}, &message);
...is clearly more readable than this...
struct spi_transfer assert_cs_then_reset_delay = {
.cs_change = 1,
.delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
};
....
<30 lines of unrelated code>
....
spi_message_add_tail(&assert_cs_then_reset_delay, &message);
...in my opinion anyway ;)
>> Previously I had a copy of spi_set_cs copy-pasted into my driver, but in
>> the end I decided to replace that with the zero-length transfers because
>> there's a danger that if the original spi_set_cs() gets rewritten some
>> time, my copy-paste code would leave around some nasty legacy.
>>
>> On the whole, I don't think the zero-length transfers are too
>> egregiously bad, and all the alternatives seem worse to me.
>
> So why not turn the CS line into GPIO and just toggle the GPIO?
>
Two reasons.
1. On some devices the CS line is built into the SPI master, rather than
being a normal GPIO.
2. The SPI driver stack addresses SPI devices in terms of which CS line
they are attached to. You can't have an spi_device in the kernel where
the SPI driver machinery doesn't have a CS line to control. Moreover it
needs to be possible for another SPI device to interrupt a running
transfer to the FPGA. Supporting this involves the SPI framework
managing the CS line.
Thanks
Joel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Mark Rutland @ 2016-11-08 17:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: zhichang.yuan, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, liviu.dudau-5wv7dgnIgG8,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <2368890.jTbyGqYR0M@wuerfel>
On Tue, Nov 08, 2016 at 05:19:54PM +0100, Arnd Bergmann wrote:
> On Tuesday, November 8, 2016 11:49:53 AM CET Mark Rutland wrote:
> > My understanding of ISA (which may be flawed) is that it's not part of
> > the PCI host bridge, but rather on x86 it happens to share the IO space
> > with PCI.
>
> On normal systems, ISA or LPC are behind a PCI bridge device, which
> passes down both low addresses of I/O space and memory space.
Ok, so the use of those address spaces is an artifact of the ISA
controller being a device under the PCI host bridge.
Given we can have multiple domains, surely that implies we can have
multiple ISA controllers in general?
> > I believe that we could theoretically have multiple independent LPC/ISA
> > busses, as is possible with PCI on !x86 systems. If the current ISA code
> > assumes a singleton bus, I think that's something that needs to be fixed
> > up more generically.
> >
> > I don't see why we should need any architecture-specific code here. Why
> > can we not fix up the ISA bus code in drivers/of/address.c such that it
> > handles multiple ISA bus instances, and translates all sub-device
> > addresses relative to the specific bus instance?
>
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
> when talking to an ISA device, so having multiple instances is
> already problematic.
I'm worried that this might not be a safe assumption. Hardware these
days has a habit of pushing the boundaries of our expectations.
If we're going to assume that, I'd certainly want the kernel to verify
that it's true for all instanciated ISA/LPC devices. Otherwise, I can
imagine people relying on (or working around) that assumption in ACPI
tables and DTs, and that will be a nightmare (at best) to untangle in
future.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Moritz Fischer @ 2016-11-08 17:06 UTC (permalink / raw)
To: Marek Vasut
Cc: Joel Holdsworth, Alan Tull, Geert Uytterhoeven, Rob Herring,
Devicetree List, Linux Kernel Mailing List, linux-spi,
Clifford Wolf
In-Reply-To: <4bdba358-db18-48f1-3286-a7a7f4c30215@denx.de>
Marek,
On Mon, Nov 7, 2016 at 10:53 AM, Marek Vasut <marex@denx.de> wrote:
>> On the whole, I don't think the zero-length transfers are too
>> egregiously bad, and all the alternatives seem worse to me.
>
> So why not turn the CS line into GPIO and just toggle the GPIO?
Does that work with *all* SPI controllers?
Cheers,
Moritz
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: John Garry @ 2016-11-08 17:05 UTC (permalink / raw)
To: Will Deacon
Cc: zhichang.yuan, mark.rutland, devicetree, lorenzo.pieralisi, benh,
minyard, arnd, catalin.marinas, gabriele.paoloni, zhichang.yuan02,
liviu.dudau, linux-kernel, xuwei5, linuxarm, olof, robh+dt,
zourongrong, linux-serial, linux-pci, bhelgaas, kantyzc,
linux-arm-kernel
In-Reply-To: <20161108164948.GG20591@arm.com>
On 08/11/2016 16:49, Will Deacon wrote:
> On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
>> On 08/11/2016 16:12, Will Deacon wrote:
>>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>>>> +static inline void arm64_set_extops(struct extio_ops *ops)
>>>> +{
>>>> + if (ops)
>>>> + WRITE_ONCE(arm64_extio_ops, ops);
>>>
>>> Why does this need to be WRITE_ONCE? You don't have READ_ONCE on the reader
>>> side. Also, what if multiple drivers want to set different ops for distinct
>>> address ranges?
>>
>> I think that the idea here is that we only have possibly one master in the
>> system which offers indirectIO backend, so another one could not possibly
>> re-set this value.
>
> Why is that assumption valid, and why does WRITE_ONCE help there? It's not
> ONCE as in WARN_ONCE, more ONCE as in exactly-once-per-invocation.
It's only valid based on the inherent assumption that all indirectIO is
redirected to one backend master, i.e. LPC driver.
Anyway, right, I don't think that WRITE_ONCE is correct. Zhichang was
looking for something which would only allow the pointer to be written
once ever.
>
>>>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>>>> new file mode 100644
>>>> index 0000000..647b3fa
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/extio.c
>>>> @@ -0,0 +1,27 @@
>>>> +/*
>>>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>>>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU General Public License
>>>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +
>>>> +struct extio_ops *arm64_extio_ops;
>>>> +
>>>> +
>>>> +BUILD_EXTIO(b, u8)
>>>> +
>>>> +BUILD_EXTIO(w, u16)
>>>> +
>>>> +BUILD_EXTIO(l, u32)
>>>
>>> Is there no way to make this slightly more generic, so that it can be
>>> re-used elsewhere? For example, if struct extio_ops was common, then
>>> you could have the singleton (which maybe should be an interval tree?),
>>> type definition, setter function and the BUILD_EXTIO invocations
>>> somewhere generic, rather than squirelled away in the arch backend.
>>>
>> The concern would be that some architecture which uses generic higher-level
>> ISA accessor ops, but have IO space, could be affected.
>
> You're already adding a Kconfig symbol for this stuff, so you can keep
> that if you don't want it on other architectures. I'm just arguing that
> plumbing drivers directly into arch code via arm64_set_extops is not
> something I'm particularly fond of, especially when it looks like it
> could be avoided with a small amount of effort.
We'll check this.
Cheers,
John
>
> Will
>
> .
>
^ permalink raw reply
* Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator
From: Peter Rosin @ 2016-11-08 17:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, Daniel Baluta, Slawomir Stepien,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.20.1611081630450.3501@nanos>
On 2016-11-08 16:59, Thomas Gleixner wrote:
> On Tue, 8 Nov 2016, Peter Rosin wrote:
>> +/*
>> + * The envelope_detector_comp_latch function works together with the compare
>> + * interrupt service routine below (envelope_detector_comp_isr) as a latch
>> + * (one-bit memory) for if the interrupt has triggered since last calling
>> + * this function.
>> + * The ..._comp_isr function disables the interrupt so that the cpu does not
>> + * need to service a possible interrupt flood from the comparator when no-one
>> + * cares anyway, and this ..._comp_latch function reenables them again if
>> + * needed.
>> + */
>> +static int envelope_detector_comp_latch(struct envelope *env)
>> +{
>> + int comp;
>> +
>> + spin_lock_irq(&env->comp_lock);
>> + comp = env->comp;
>> + env->comp = 0;
>> + spin_unlock_irq(&env->comp_lock);
>> +
>> + if (!comp)
>> + return 0;
>> +
>> + /*
>> + * The irq was disabled, and is reenabled just now.
>> + * But there might have been a pending irq that
>> + * happened while the irq was disabled that fires
>> + * just as the irq is reenabled. That is not what
>> + * is desired.
>> + */
>> + enable_irq(env->comp_irq);
>> +
>> + /* So, synchronize this possibly pending irq... */
>> + synchronize_irq(env->comp_irq);
>> +
>> + /* ...and redo the whole dance. */
>> + spin_lock_irq(&env->comp_lock);
>> + comp = env->comp;
>> + env->comp = 0;
>> + spin_unlock_irq(&env->comp_lock);
>> +
>> + if (comp)
>> + enable_irq(env->comp_irq);
>
> So you need that whole dance including the delayed work because you cannot
> call iio_write_channel_raw() from hard interrupt context, right?
It's not the "cannot call from hard irq context" that made me do that, it's...
> So you might just register a threaded interrupt handler, which should make
> this whole thing way simpler.
>
> devm_request_threaded_irq(dev, irq, NULL, your_isr, IRQF_ONESHOT, ...);
>
> The core will mask the interrupt line until the threaded handler is
> finished. The threaded handler is invoked with preemption enabled, so you
> can sleep there as long as you want. So you can do everything in your
> handler and the above dance is just not required.
...that I couldn't work out how to reenable a oneshot irq once it had fired,
short of freeing the irq and requesting it again. That seemed entirely
bogus, the driver shouldn't risk losing a resource like that so I don't know
what I didn't see? Or maybe it was that I had a hard time resolving the race
between the irq and the timeout in a nice way. I honestly don't remember
why exactly I abandoned oneshot irqs, but this enable/sync/enable dance
was much nicer than what I came up with for the oneshot irq solution I
originally worked on.
Or maybe I had problems with the possibly pending irq also when using a
oneshot irq, but didn't realize it? That was something I discovered quite
late in the process, some time after moving away from oneshot irqs. Are
pending irqs cleared when requesting (or reenabling, however that is done)
a oneshot irq?
Anyway, I do not want the interrupt to be serviced when no one is interested,
since I'm afraid that nasty input might generate a flood of interrupts that
might disturb other things that the cpu is doing. Which means that I need
to enable/disable the interrupt as needed.
However, what *I* thought Jonathan wanted input on was the part where the
interrupt edge/level is flipped when requesting "inverted" signals in
envelope_store_invert(). That could perhaps be seen as unorthodox and in
need of more eyes?
Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Will Deacon @ 2016-11-08 16:49 UTC (permalink / raw)
To: John Garry
Cc: zhichang.yuan, mark.rutland, devicetree, lorenzo.pieralisi, benh,
minyard, arnd, catalin.marinas, gabriele.paoloni, zhichang.yuan02,
liviu.dudau, linux-kernel, xuwei5, linuxarm, olof, robh+dt,
zourongrong, linux-serial, linux-pci, bhelgaas, kantyzc,
linux-arm-kernel
In-Reply-To: <8adfe182-4939-479d-6013-25ec40021b20@huawei.com>
On Tue, Nov 08, 2016 at 04:33:44PM +0000, John Garry wrote:
> On 08/11/2016 16:12, Will Deacon wrote:
> >On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> >>+static inline void arm64_set_extops(struct extio_ops *ops)
> >>+{
> >>+ if (ops)
> >>+ WRITE_ONCE(arm64_extio_ops, ops);
> >
> >Why does this need to be WRITE_ONCE? You don't have READ_ONCE on the reader
> >side. Also, what if multiple drivers want to set different ops for distinct
> >address ranges?
>
> I think that the idea here is that we only have possibly one master in the
> system which offers indirectIO backend, so another one could not possibly
> re-set this value.
Why is that assumption valid, and why does WRITE_ONCE help there? It's not
ONCE as in WARN_ONCE, more ONCE as in exactly-once-per-invocation.
> >>diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
> >>new file mode 100644
> >>index 0000000..647b3fa
> >>--- /dev/null
> >>+++ b/arch/arm64/kernel/extio.c
> >>@@ -0,0 +1,27 @@
> >>+/*
> >>+ * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
> >>+ * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License version 2 as
> >>+ * published by the Free Software Foundation.
> >>+ *
> >>+ * This program is distributed in the hope that it will be useful,
> >>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>+ * GNU General Public License for more details.
> >>+ *
> >>+ * You should have received a copy of the GNU General Public License
> >>+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
> >>+ */
> >>+
> >>+#include <linux/io.h>
> >>+
> >>+struct extio_ops *arm64_extio_ops;
> >>+
> >>+
> >>+BUILD_EXTIO(b, u8)
> >>+
> >>+BUILD_EXTIO(w, u16)
> >>+
> >>+BUILD_EXTIO(l, u32)
> >
> >Is there no way to make this slightly more generic, so that it can be
> >re-used elsewhere? For example, if struct extio_ops was common, then
> >you could have the singleton (which maybe should be an interval tree?),
> >type definition, setter function and the BUILD_EXTIO invocations
> >somewhere generic, rather than squirelled away in the arch backend.
> >
> The concern would be that some architecture which uses generic higher-level
> ISA accessor ops, but have IO space, could be affected.
You're already adding a Kconfig symbol for this stuff, so you can keep
that if you don't want it on other architectures. I'm just arguing that
plumbing drivers directly into arch code via arm64_set_extops is not
something I'm particularly fond of, especially when it looks like it
could be avoided with a small amount of effort.
Will
^ permalink raw reply
* Re: [PATCH v3 00/10] Add DT support for ohci-da8xx
From: Axel Haslam @ 2016-11-08 16:37 UTC (permalink / raw)
To: Alan Stern, Greg KH, Sekhar Nori, Kevin Hilman, David Lechner,
robh+dt
Cc: devicetree, linux-usb, linux-kernel, linux-arm-kernel,
Axel Haslam
In-Reply-To: <20161107203948.28324-1-ahaslam@baylibre.com>
Hi,
On Mon, Nov 7, 2016 at 9:39 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> The purpose of this patch series is to add DT support for the davinci
> ohci driver.
>
To make it easier to review. I will split the arch/arm and driver
patches into separate series.
Regards
Axel
> To be able to use device tree to probe the driver, we need to remove
> the platform callbacks that are handling vbus and over current.
>
> The first four patches prepare the stage by allowing to use a regulator
> instead of the callbacks.
>
> The next three patches convert the callback users to use a regulator
> instead and then remove the callbacks from the driver and platform code.
>
> Finally, we add device tree bindings and support in the driver.
>
> DEPENDENCIES:
> This series has depends on some patches currently under review
> but mostly accepted:
> 1. [PATCH 0/3] fix ohci phy name [1] (accepted)
> 2. [PATCH/RFC v2 0/3] regulator: handling of error conditions for usb drivers [2] (accepted)
> 3. [PATCH] gpio: davinci: Use unique labels for each gpio chip [3] (review pending)
>
> Also the current davinci baranches soon to be pulled to linux-next:
> davinci-for-v4.10/soc
> davinci-for-v4.10/dt
> davinci-for-v4.10/defconfig
> davinci-for-v4.10/cleanup
>
> A branch with all the dependencies can be found here [4].
>
> Changes form v2->v3
> * drop patches that have been integrated to arch/arm
> * drop regulator patches which will be integrated through regulator tree
> * use of the accepted regulator API to get over current status
> * better patch separation with the use of wrappers
>
> Changes from v1->v2
> * Rebased and added patch to make ohci a separate driver
> * Use a regulator instead of handling Gpios (David Lechner)
> * Add an over current mode to regulator framework
> * Fixed regulator is able to register for and over current irq
> * Added patch by Alexandre to remove build warnings
> * Moved global variables into private hcd structure.
>
> [1] https://lkml.org/lkml/2016/11/2/208
> [2] https://lkml.org/lkml/2016/11/3/188
> [3] http://www.spinics.net/lists/linux-gpio/msg17710.html
> [4] https://github.com/axelhaslamx/linux-axel/commits/ohci-da8xx-dt-v3
>
> Axel Haslam (10):
> USB: ohci: da8xx: use ohci priv data instead of globals
> USB: ohci: da8xx: Prepare to remove platform callbacks
> USB: ohci: da8xx: Allow a regulator to handle VBUS
> ARM: davinci: da830: Handle vbus with a regulator
> ARM: davinci: hawk: Remove vbus and over current gpios
> USB: ohci: da8xx: Remove ohci platform callbacks
> USB: ohci: da8xx: use a flag instead of mask for ocic
> USB: ohci: da8xx: Add devicetree bindings
> USB: ohci: da8xx: Allow probing from DT
> ARM: dts: da850: add usb device node
>
> .../devicetree/bindings/usb/ohci-da8xx.txt | 39 ++++
> arch/arm/boot/dts/da850-lcdk.dts | 8 +
> arch/arm/boot/dts/da850.dtsi | 8 +
> arch/arm/mach-davinci/board-da830-evm.c | 108 ++++-----
> arch/arm/mach-davinci/board-omapl138-hawk.c | 99 +-------
> arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
> arch/arm/mach-davinci/usb-da8xx.c | 3 +-
> drivers/usb/host/ohci-da8xx.c | 253 +++++++++++++++------
> include/linux/platform_data/usb-davinci.h | 20 --
> 9 files changed, 283 insertions(+), 257 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
>
> --
> 2.10.1
>
^ permalink raw reply
* Re: [PATCH V2 3/4] regulator: pv88080: Update Regulator driver for MFD support
From: Mark Brown @ 2016-11-08 16:37 UTC (permalink / raw)
To: Eric Hyeung Dong Jeong
Cc: LINUX-KERNEL, Liam Girdwood, Alexandre Courbot, DEVICETREE,
LINUX-GPIO, Lee Jones, Linus Walleij, Mark Rutland, Rob Herring,
Support Opensource
In-Reply-To: <8FA4409277D6E54680546B8811D85410029DFAA2EA@NB-EX-MBX01.diasemi.com>
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
On Tue, Nov 08, 2016 at 05:59:41AM +0000, Eric Hyeung Dong Jeong wrote:
> Thank you for the comments.
> There was an internal request to release driver based on Kernel 3.18 for GPIO and MFD support.
> After that, the code has been kept. I will send a patch again after changes.
Please don't submit code for ancient kernels upstream, we can't merge
anything that isn't for current kernels.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: John Garry @ 2016-11-08 16:33 UTC (permalink / raw)
To: Will Deacon, zhichang.yuan
Cc: mark.rutland, devicetree, lorenzo.pieralisi, benh, minyard, arnd,
catalin.marinas, gabriele.paoloni, zhichang.yuan02, liviu.dudau,
linux-kernel, xuwei5, linuxarm, olof, robh+dt, zourongrong,
linux-serial, linux-pci, bhelgaas, kantyzc, linux-arm-kernel
In-Reply-To: <20161108161245.GD20591@arm.com>
On 08/11/2016 16:12, Will Deacon wrote:
> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>> For arm64, there is no I/O space as other architectural platforms, such as
>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>> known port addresses are used to control the corresponding target devices, for
>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>> normal MMIO mode in using.
>>
>> To drive these devices, this patch introduces a method named indirect-IO.
>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>> redefined. When upper layer drivers call in/out with those known legacy port
>> addresses to access the peripherals, the hooking functions corrresponding to
>> those target peripherals will be called. Through this way, those upper layer
>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> arch/arm64/Kconfig | 6 +++
>> arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
>> arch/arm64/include/asm/io.h | 29 +++++++++++++
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/extio.c | 27 ++++++++++++
>> 5 files changed, 157 insertions(+)
>> create mode 100644 arch/arm64/include/asm/extio.h
>> create mode 100644 arch/arm64/kernel/extio.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 969ef88..b44070b 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
>> config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> default 16
>>
>> +config ARM64_INDIRECT_PIO
>> + bool "access peripherals with legacy I/O port"
>> + help
>> + Support special accessors for ISA I/O devices. This is needed for
>> + SoCs that do not support standard read/write for the ISA range.
>> +
>> config NO_IOPORT_MAP
>> def_bool y if !PCI
>>
>> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
>> new file mode 100644
>> index 0000000..6ae0787
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/extio.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __LINUX_EXTIO_H
>> +#define __LINUX_EXTIO_H
>> +
>> +struct extio_ops {
>> + unsigned long start;/* inclusive, sys io addr */
>> + unsigned long end;/* inclusive, sys io addr */
>> +
>> + u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
>> + void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
>> + size_t dlen);
>> + u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
>> + size_t dlen, unsigned int count);
>> + void (*pfouts)(void *devobj, unsigned long ptaddr,
>> + const void *outbuf, size_t dlen,
>> + unsigned int count);
>> + void *devpara;
>> +};
>> +
>> +extern struct extio_ops *arm64_extio_ops;
>> +
>> +#define DECLARE_EXTIO(bw, type) \
>> +extern type in##bw(unsigned long addr); \
>> +extern void out##bw(type value, unsigned long addr); \
>> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
>> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
>> +
>> +#define BUILD_EXTIO(bw, type) \
>> +type in##bw(unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + return read##bw(PCI_IOBASE + addr); \
>> + return arm64_extio_ops->pfin ? \
>> + arm64_extio_ops->pfin(arm64_extio_ops->devpara, \
>> + addr, sizeof(type)) : -1; \
>> +} \
>> + \
>> +void out##bw(type value, unsigned long addr) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + write##bw(value, PCI_IOBASE + addr); \
>> + else \
>> + if (arm64_extio_ops->pfout) \
>> + arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>> + addr, value, sizeof(type)); \
>> +} \
>> + \
>> +void ins##bw(unsigned long addr, void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + reads##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfins) \
>> + arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +} \
>> + \
>> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count) \
>> +{ \
>> + if (!arm64_extio_ops || arm64_extio_ops->start > addr || \
>> + arm64_extio_ops->end < addr) \
>> + writes##bw(PCI_IOBASE + addr, buffer, count); \
>> + else \
>> + if (arm64_extio_ops->pfouts) \
>> + arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
>> + addr, buffer, sizeof(type), count); \
>> +}
>> +
>> +static inline void arm64_set_extops(struct extio_ops *ops)
>> +{
>> + if (ops)
>> + WRITE_ONCE(arm64_extio_ops, ops);
>
> Why does this need to be WRITE_ONCE? You don't have READ_ONCE on the reader
> side. Also, what if multiple drivers want to set different ops for distinct
> address ranges?
I think that the idea here is that we only have possibly one master in
the system which offers indirectIO backend, so another one could not
possibly re-set this value.
>
>> +}
>> +
>> +#endif /* __LINUX_EXTIO_H*/
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0bba427..136735d 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -31,6 +31,7 @@
>> #include <asm/early_ioremap.h>
>> #include <asm/alternative.h>
>> #include <asm/cpufeature.h>
>> +#include <asm/extio.h>
>>
>> #include <xen/xen.h>
>>
>> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define IO_SPACE_LIMIT (PCI_IO_SIZE - 1)
>> #define PCI_IOBASE ((void __iomem *)PCI_IO_START)
>>
>> +
>> +/*
>> + * redefine the in(s)b/out(s)b for indirect-IO.
>> + */
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define inb inb
>> +#define outb outb
>> +#define insb insb
>> +#define outsb outsb
>> +/* external declaration */
>> +DECLARE_EXTIO(b, u8)
>> +
>> +#define inw inw
>> +#define outw outw
>> +#define insw insw
>> +#define outsw outsw
>> +
>> +DECLARE_EXTIO(w, u16)
>> +
>> +#define inl inl
>> +#define outl outl
>> +#define insl insl
>> +#define outsl outsl
>> +
>> +DECLARE_EXTIO(l, u32)
>> +#endif
>> +
>> +
>> /*
>> * String version of I/O memory access operations.
>> */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 7d66bba..60e0482 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
>> sys_compat.o entry32.o
>> arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
>> arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
>> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
>> arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
>> arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
>> arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> new file mode 100644
>> index 0000000..647b3fa
>> --- /dev/null
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/io.h>
>> +
>> +struct extio_ops *arm64_extio_ops;
>> +
>> +
>> +BUILD_EXTIO(b, u8)
>> +
>> +BUILD_EXTIO(w, u16)
>> +
>> +BUILD_EXTIO(l, u32)
>
> Is there no way to make this slightly more generic, so that it can be
> re-used elsewhere? For example, if struct extio_ops was common, then
> you could have the singleton (which maybe should be an interval tree?),
> type definition, setter function and the BUILD_EXTIO invocations
> somewhere generic, rather than squirelled away in the arch backend.
>
> Will
The concern would be that some architecture which uses generic
higher-level ISA accessor ops, but have IO space, could be affected.
John
>
> .
>
^ 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