Re: [PATCH v2 2/4] nvmem: NXP LPC18xx EEPROM memory NVMEM driver
Hi Srinivas, On 16 November 2015 at 12:37, Srinivas Kandagatla wrote: > > > On 16/11/15 15:33, Ariel D'Alessandro wrote: >> >>>cut<-- >> From 8cae10eff8ea8da9c5a8058ff75abeeddd8a8224 Mon Sep 17 00:00:00 >> 2001 >>From: Srinivas Kandagatla >>Date: Mon, 26 Oct 2015 13:30:24 + >>Subject: [PATCH] nvmem: core: return error for non word aligned bytes >> >>nvmem providers have restrictions on register strides, so return error >>code when users attempt to read/write buffers with sizes which are not >>aligned to the word boundary. >> >>Without this patch the userspace would continue to try as it does not >>get any error from the nvmem core, resulting in a hang. >> >>Signed-off-by: Srinivas Kandagatla >>--- >> drivers/nvmem/core.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >>diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c >>index 6fd4e5a..9d11d98 100644 >>--- a/drivers/nvmem/core.c >>+++ b/drivers/nvmem/core.c >>@@ -70,6 +70,9 @@ static ssize_t bin_attr_nvmem_read(struct file >> *filp, >>struct kobject *kobj, >> if (pos >= nvmem->size) >> return 0; >> >>+if (count < nvmem->word_size) >>+return -EINVAL; >>+ >> if (pos + count > nvmem->size) >> count = nvmem->size - pos; >> >>@@ -95,6 +98,9 @@ static ssize_t bin_attr_nvmem_write(struct file >> *filp, >>struct kobject *kobj, >> if (pos >= nvmem->size) >> return 0; >> >>+if (count < nvmem->word_size) >>+return -EINVAL; >>+ >> if (pos + count > nvmem->size) >> count = nvmem->size - pos; >> >>> >>> > >>> >Patch looks good to me. I think that it solves the issue. >>> >I don't have the board here right now, so I'll check it ASAP and give >>> >some feedback. >> >> Finally tested this. As it seemed, it solved the issue. >> Are you submitting a patch for this? > > Yes, I will send a patch to the mailing list. > Ping? It would be good to have that patch and be able to merge this lpc18xx-nvmem driver in time for the next merge window. Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] nvmem: NXP LPC18xx EEPROM memory NVMEM driver
Hi Srinivas, Ariel, On 30 October 2015 at 12:42, Ariel D'Alessandro wrote: > El 26/10/15 a las 11:23, Srinivas Kandagatla escribió: >> >> >> On 19/10/15 18:32, Ariel D'Alessandro wrote: >>> This commit adds support for NXP LPC18xx EEPROM memory found in NXP >> s/commit/patch > > OK. > What's wrong with using "commit" ? If the patch gets accepted and is merged, it will become a commit. Hence, it's customary to use "commit" in the commit log. I really don't think it's wrong to use either patch or commit. -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] pwm: lpc18xx_pwm: use pwm_set_chip_data
(+ Ariel) Hi Oliver, Not sure why there's some many people in Cc for such a silly change. I guess you are using get_maintainers.pl on the entire patchset and get this rather long list. IMO, the value of submitting patches as part of a larger series is to be able to push patches that need to be applied in some given order, or otherwise have some kind of logical relationship between them. However, this is not the case: it's just a very small change and has no relation to the rest of the patches in the series. I think a simple standalone patch would be better here. Also, get_maintainer.pl is just a hint, and not meant to be used as-is. In particular, you are missing the driver's author. On 26 October 2015 at 18:32, Olliver Schinagl wrote: > From: Olliver Schinagl > > The lpc18xx driver currently manipulates the pwm_device struct directly > rather then using the pwm_set_chip_data. While the current method may > save a clock cycle or two, it is more obvious that data is set to the > chip pointer (especially since it is only a single int holding struct. > > Signed-off-by: Olliver Schinagl > --- > drivers/pwm/pwm-lpc18xx-sct.c | 11 +++ > drivers/pwm/pwm-sun4i.c | 11 +++ > 2 files changed, 18 insertions(+), 4 deletions(-) > ...and this diffstat is obviously fishy. -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation
+DT bindings maintainers As per the documentation in Documentation/devicetree/bindings/submitting-patches.txt this binding should be patch 1/2. On 16 October 2015 at 11:07, Ariel D'Alessandro wrote: > Add the devicetree binding document for NXP LPC18xx EEPROM memory. > > Signed-off-by: Ariel D'Alessandro > --- > .../devicetree/bindings/nvmem/lpc18xx_eeprom.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > > diff --git a/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > new file mode 100644 > index 000..372ff8c > --- /dev/null > +++ b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > @@ -0,0 +1,26 @@ > +* NXP LPC18xx EEPROM memory NVMEM driver > + > +Required properties: > + - compatible: Should be "nxp,lpc1850-eeprom" Correct me if I'm wrong, but I believe not all LPC18xx/43xx devices have an EEPROM. Isn't it restricted to LPC18x7/LPC43x7 devices? Should the compatible be nxp,lpc1857-eeprom to avoid confusion? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] input: rotary-encoder: Support 'steps-per-period' DT property
On 14 October 2015 at 03:55, Dmitry Torokhov wrote:
> On Fri, Oct 09, 2015 at 10:46:56AM -0300, Ezequiel Garcia wrote:
>> As per the recent devicetree binding changes, this commit adds the
>> support for the new 'steps-per-period' property.
>>
>> Legacy properties to specify the rotary behavior, are now deprecated
>> and instead the new 'steps-per-period' is supported. The default behavior
>> is retained.
>>
>> This allows to support rotary-encoder devices with detents wich are capable
>> of producing a stable event on each step.
>>
>> Signed-off-by: Guido Martínez
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/input/misc/rotary_encoder.c | 87
>> +++--
>> include/linux/rotary_encoder.h | 2 +-
>> 2 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/input/misc/rotary_encoder.c
>> b/drivers/input/misc/rotary_encoder.c
>> index 15a4cc670a3f..e021615dd3c0 100644
>> --- a/drivers/input/misc/rotary_encoder.c
>> +++ b/drivers/input/misc/rotary_encoder.c
>> @@ -142,6 +142,55 @@ static irqreturn_t rotary_encoder_half_period_irq(int
>> irq, void *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> +static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
>> +{
>> + struct rotary_encoder *encoder = dev_id;
>> + unsigned char sum;
>> + int state;
>> +
>> + state = rotary_encoder_get_state(encoder->pdata);
>> +
>> + /*
>> + * We encode the previous and the current state using a byte.
>> + * The previous state in the MSB nibble, the current state in the LSB
>> + * nibble. Then use a table to decide the direction of the turn.
>> + */
>> + sum = (encoder->last_stable << 4) + state;
>> + switch (sum) {
>> + case 0x31:
>> + case 0x10:
>> + case 0x02:
>> + case 0x23:
>> + encoder->dir = 0; /* clockwise */
>> + break;
>> +
>> + case 0x13:
>> + case 0x01:
>> + case 0x20:
>> + case 0x32:
>> + encoder->dir = 1; /* counter-clockwise */
>> + break;
>> +
>> + default:
>> + /*
>> + * Ignore all other values. This covers the case when the
>> + * state didn't change (a spurious interrupt) and the
>> + * cases where the state changed by two steps, making it
>> + * impossible to tell the direction.
>> + *
>> + * In either case, don't report any event and save the
>> + * state for later.
>> + */
>> + goto out;
>> + }
>> +
>> + rotary_encoder_report_event(encoder);
>> +
>> +out:
>> + encoder->last_stable = state;
>> + return IRQ_HANDLED;
>> +}
>> +
>> #ifdef CONFIG_OF
>> static const struct of_device_id rotary_encoder_of_match[] = {
>> { .compatible = "rotary-encoder", },
>> @@ -176,7 +225,26 @@ static struct rotary_encoder_platform_data
>> *rotary_encoder_parse_dt(struct devic
>>
>> pdata->relative_axis = of_property_read_bool(np,
>> "rotary-encoder,relative-axis");
>> pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover");
>> - pdata->half_period = of_property_read_bool(np,
>> "rotary-encoder,half-period");
>> +
>> + if (!of_get_property(np, "rotary-encoder,steps-per-period", NULL)) {
>> + /*
>> + * Fallback to a one step per period behavior if the
>> + * 'steps-per-period' is not set.
>> + */
>> + pdata->steps_per_period = 1;
>> + } else {
>> + of_property_read_u32(np, "rotary-encoder,steps-per-period",
>> + &pdata->steps_per_period);
>> + }
>> +
>> + /*
>> + * The 'half-period' property has been deprecated, you must use
>> + * 'steps-per-period' and set an appropriate value.
>> + */
>> + if (of_get_property(np, "rotary-encoder,half-period", NULL)) {
>> + pr_warn(FW_WARN "\"rotary-encoder,half-period\" is
>> deprecated\n");
>> + pdata->steps_per_period = 2;
>> + }
>
> Hmm, I do not think we need to warn about old DTSes if
Re: [PATCH 2/3] input: rotary-encoder: Introduce new 'steps-per-period' property
On 9 October 2015 at 10:57, Rob Herring wrote: > On Fri, Oct 9, 2015 at 8:46 AM, Ezequiel Garcia > wrote: >> This commit deprecates the 'half-period' property and introduces >> a new property 'steps-per-period'. This property specifies the >> number of steps (stable states) produced by the rotary encoder >> for each GPIO period. >> >> Such a property is required to accurately describe all kinds of >> rotary-encoders devices. >> >> Signed-off-by: Ezequiel Garcia > > Acked-by: Rob Herring > > Are there any in tree dts's using the deprecated property? If so, > please update them. > Nope, no dts's using it. Thanks, -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] input: rotary-encoder: Support 'steps-per-period' DT property
As per the recent devicetree binding changes, this commit adds the
support for the new 'steps-per-period' property.
Legacy properties to specify the rotary behavior, are now deprecated
and instead the new 'steps-per-period' is supported. The default behavior
is retained.
This allows to support rotary-encoder devices with detents wich are capable
of producing a stable event on each step.
Signed-off-by: Guido Martínez
Signed-off-by: Ezequiel Garcia
---
drivers/input/misc/rotary_encoder.c | 87 +++--
include/linux/rotary_encoder.h | 2 +-
2 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/input/misc/rotary_encoder.c
b/drivers/input/misc/rotary_encoder.c
index 15a4cc670a3f..e021615dd3c0 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -142,6 +142,55 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq,
void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
+{
+ struct rotary_encoder *encoder = dev_id;
+ unsigned char sum;
+ int state;
+
+ state = rotary_encoder_get_state(encoder->pdata);
+
+ /*
+* We encode the previous and the current state using a byte.
+* The previous state in the MSB nibble, the current state in the LSB
+* nibble. Then use a table to decide the direction of the turn.
+*/
+ sum = (encoder->last_stable << 4) + state;
+ switch (sum) {
+ case 0x31:
+ case 0x10:
+ case 0x02:
+ case 0x23:
+ encoder->dir = 0; /* clockwise */
+ break;
+
+ case 0x13:
+ case 0x01:
+ case 0x20:
+ case 0x32:
+ encoder->dir = 1; /* counter-clockwise */
+ break;
+
+ default:
+ /*
+* Ignore all other values. This covers the case when the
+* state didn't change (a spurious interrupt) and the
+* cases where the state changed by two steps, making it
+* impossible to tell the direction.
+*
+* In either case, don't report any event and save the
+* state for later.
+*/
+ goto out;
+ }
+
+ rotary_encoder_report_event(encoder);
+
+out:
+ encoder->last_stable = state;
+ return IRQ_HANDLED;
+}
+
#ifdef CONFIG_OF
static const struct of_device_id rotary_encoder_of_match[] = {
{ .compatible = "rotary-encoder", },
@@ -176,7 +225,26 @@ static struct rotary_encoder_platform_data
*rotary_encoder_parse_dt(struct devic
pdata->relative_axis = of_property_read_bool(np,
"rotary-encoder,relative-axis");
pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover");
- pdata->half_period = of_property_read_bool(np,
"rotary-encoder,half-period");
+
+ if (!of_get_property(np, "rotary-encoder,steps-per-period", NULL)) {
+ /*
+* Fallback to a one step per period behavior if the
+* 'steps-per-period' is not set.
+*/
+ pdata->steps_per_period = 1;
+ } else {
+ of_property_read_u32(np, "rotary-encoder,steps-per-period",
+&pdata->steps_per_period);
+ }
+
+ /*
+* The 'half-period' property has been deprecated, you must use
+* 'steps-per-period' and set an appropriate value.
+*/
+ if (of_get_property(np, "rotary-encoder,half-period", NULL)) {
+ pr_warn(FW_WARN "\"rotary-encoder,half-period\" is
deprecated\n");
+ pdata->steps_per_period = 2;
+ }
return pdata;
}
@@ -247,12 +315,23 @@ static int rotary_encoder_probe(struct platform_device
*pdev)
encoder->irq_a = gpio_to_irq(pdata->gpio_a);
encoder->irq_b = gpio_to_irq(pdata->gpio_b);
- /* request the IRQs */
- if (pdata->half_period) {
+ switch (pdata->steps_per_period) {
+ case 4:
+ handler = &rotary_encoder_quarter_period_irq;
+ encoder->last_stable = rotary_encoder_get_state(pdata);
+ break;
+ case 2:
handler = &rotary_encoder_half_period_irq;
encoder->last_stable = rotary_encoder_get_state(pdata);
- } else {
+ break;
+ case 1:
handler = &rotary_encoder_irq;
+ break;
+ default:
+ dev_err(dev, "'%d' is not a valid steps-per-period value\n",
+ pdata->steps_per_period);
+ err = -EINVAL;
+ goto ex
[PATCH 2/3] input: rotary-encoder: Introduce new 'steps-per-period' property
This commit deprecates the 'half-period' property and introduces a new property 'steps-per-period'. This property specifies the number of steps (stable states) produced by the rotary encoder for each GPIO period. Such a property is required to accurately describe all kinds of rotary-encoders devices. Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/input/rotary-encoder.txt | 9 + Documentation/input/rotary-encoder.txt | 8 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt index 331549593ed5..5715ad70d28e 100644 --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt @@ -14,7 +14,16 @@ Optional properties: device, hence no steps need to be passed. - rotary-encoder,rollover: Automatic rollove when the rotary value becomes greater than the specified steps or smaller than 0. For absolute axis only. +- rotary-encoder,steps-per-period: Number of steps (stable states) per period. + The values have the following meaning: + 1: Full-period mode (default) + 2: Half-period mode + 4: Quarter-period mode + +Deprecated properties: - rotary-encoder,half-period: Makes the driver work on half-period mode. + This property is deprecated. Instead, a 'steps-per-period ' value should + be used, such as "rotary-encoder,steps-per-period = <2>". See Documentation/input/rotary-encoder.txt for more information. diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 5737e3590adb..00acf88e4064 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt @@ -9,8 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees and by triggering on falling and rising edges, the turn direction can be determined. -Some encoders have both outputs low in stable states, whereas others also have -a stable state with both outputs high (half-period mode). +Some encoders have both outputs low in stable states, others also have +a stable state with both outputs high (half-period mode) and some have +a stable state in all steps (quarter-period mode). The phase diagram of these two outputs look like this: @@ -32,6 +33,9 @@ The phase diagram of these two outputs look like this: |<-->| one step (half-period mode) +|<>| + one step (quarter-period mode) + For more information, please see https://en.wikipedia.org/wiki/Rotary_encoder -- 2.5.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] input: Simplifying the rotary encoder devicetree binding
Hi Dmitry, This patchset is another attempt at supporting rotary encoders with stable state on each output states. Previous efforts to support this has been done by Sascha Hauer [1] and myself [2]. After some discussion we agreed to remove the current ad-hoc bindings for each of the rotary-encoders types, and instead introduce "one binding to rule them all". This patchset introduces a new 'steps-per-period' property. Such a property can be used to model the three types of rotary-encoders. >From the GPIO output diagram, we can see where these types come from, and how the steps-per-period describes each of them. _ _ _ | | | | | | Channel A | |_| |_| | : : : : : : : : : : : : __ _ _ _ | | | | | | | Channel B |_| |_| |_| |__ : : : : : : : : : : : : Event a b c d a b c d a b c d |<>| one step, steps-per-period = 1 |<-->| one step, steps-per-period = 2 |<>| one step, steps-per-period = 4 The 'half-period' property is marked as deprecated and a warning message is issued if it's used, although the driver retains its old behavior. I'm also submitting Ben Gamari's cleanup, with the commit log slightly ammended. Feedback welcome! [1] http://www.spinics.net/lists/linux-input/msg28701.html [2] http://www.spinics.net/lists/linux-input/msg27644.html Ben Gamari (1): input: rotary-encoder: Use of_property_read_bool Ezequiel Garcia (2): input: rotary-encoder: Introduce new 'steps-per-period' property input: rotary-encoder: Support 'steps-per-period' DT property .../devicetree/bindings/input/rotary-encoder.txt | 9 +++ Documentation/input/rotary-encoder.txt | 8 +- drivers/input/misc/rotary_encoder.c| 94 +++--- include/linux/rotary_encoder.h | 2 +- 4 files changed, 101 insertions(+), 12 deletions(-) -- 2.5.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] input: rotary-encoder: Use of_property_read_bool
From: Ben Gamari This commit makes uses of_property_read_bool() to read boolean properties. This is just cosmetic cleanup. Signed-off-by: Ben Gamari --- drivers/input/misc/rotary_encoder.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c index f27f81ee84ed..15a4cc670a3f 100644 --- a/drivers/input/misc/rotary_encoder.c +++ b/drivers/input/misc/rotary_encoder.c @@ -174,12 +174,9 @@ static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct devic pdata->gpio_b = of_get_gpio_flags(np, 1, &flags); pdata->inverted_b = flags & OF_GPIO_ACTIVE_LOW; - pdata->relative_axis = !!of_get_property(np, - "rotary-encoder,relative-axis", NULL); - pdata->rollover = !!of_get_property(np, - "rotary-encoder,rollover", NULL); - pdata->half_period = !!of_get_property(np, - "rotary-encoder,half-period", NULL); + pdata->relative_axis = of_property_read_bool(np, "rotary-encoder,relative-axis"); + pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover"); + pdata->half_period = of_property_read_bool(np, "rotary-encoder,half-period"); return pdata; } -- 2.5.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
On 6 October 2015 at 13:27, Harvey Hunt wrote:
> From: Alex Smith
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah Kakakhel
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Paul Burton
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith
> Signed-off-by: Harvey Hunt
> ---
> v6 -> v7:
> - Add nand-ecc-mode to DT.
> - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
> - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
> arch/mips/boot/dts/ingenic/ci20.dts| 54
> ++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 26
> 2 files changed, 80 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
> &uart4 {
> status = "okay";
> };
> +
> +&nemc {
> + status = "okay";
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;
> +
Why is this in the ci20.dts instead of the SoC dtsi?
Seems at least compatible and reg is not board-specific.
Thanks,
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm64: dts: mt8173: Add nor flash node
On 8 September 2015 at 08:53, Jagan Teki wrote:
> On 8 September 2015 at 15:19, Bayi Cheng wrote:
>> Add Mediatek nor flash node
>>
>> Signed-off-by: Bayi Cheng
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..a14f005 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,16 @@
>> status = "disabled";
>> };
>>
>> + nor_flash: nor@1100d000 {
>
> Based on the comments from 1/3 - this notation needs to be change something
> like
> qspi0: quadspi@1100d000
>
Actually, to follow ePAPR recomendations it should be named as flash@1100d000.
(See ePAPR, 2.2.2 Generic Names Recommendation).
I believe the phandle name choice can be more descriptive.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] dt-bindings: binding for jz4780-{nand,bch}
On 27 July 2015 at 10:50, Alex Smith wrote:
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah Kakakhel
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> v3 -> v4:
> - No change
>
> v2 -> v3:
> - Rebase to 4.0-rc6
> - Changed ingenic,ecc-size to common nand-ecc-step-size
> - Changed ingenic,ecc-strength to common nand-ecc-strength
> - Changed ingenic,busy-gpio to common rb-gpios
> - Changed ingenic,wp-gpio to common wp-gpios
>
> v1 -> v2:
> - Rebase to 4.0-rc3
> ---
> .../bindings/mtd/ingenic,jz4780-nand.txt | 57
> ++
> 1 file changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index ..1e8e2eeffbf7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,57 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> + an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND device properties:
> +- ingenic,bch-device: To make use of the hardware BCH controller, this
> property
> + must contain a phandle for the BCH controller node. The required properties
> + for this node are described below. If this is not specified, software BCH
> + will be used instead.
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>; /* Bank 1 */
> +
> + ingenic,bch-device = <&bch>;
I believe it's slighly more common to use a -controller suffix for
such a property:
$ git grep "controller = <&" Documentation/devicetree/bindings/
Other than this, it looks good.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] i2c: add i2c-lpc2k driver
On 16 Aug 08:10 PM, Joachim Eastwood wrote:
[..]
> +
> +static int i2c_lpc2k_clear_arb(struct lpc2k_i2c *i2c)
> +{
> + unsigned long timeout = jiffies + msecs_to_jiffies(1000);
> +
> + /*
> + * If the transfer needs to abort for some reason, we'll try to
> + * force a stop condition to clear any pending bus conditions
> + */
> + writel(LPC24XX_STO, i2c->base + LPC24XX_I2CONSET);
> +
> + /* Wait for status change */
> + while (readl(i2c->base + LPC24XX_I2STAT) != M_I2C_IDLE) {
> + if (time_after(jiffies, timeout)) {
> + /* Bus was not idle, try to reset adapter */
> + i2c_lpc2k_reset(i2c);
> + return -EBUSY;
> + }
> +
> + cpu_relax();
> + }
I believe you can use readl_{relaxed}_poll_timeout_{atomic} here.
Ccing Ariel, maybe he can help with a test.
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] NXP SPIFI driver for LPC18xx/43xx familiy
Brian, Mind if I ping you on this one? On 9 July 2015 at 17:19, Joachim Eastwood wrote: > This patch set adds a SPI-NOR driver for the NXP SPI Flash (SPIFI) > controller that can be found on newer NXP MCUs. For example on the > LPC18xx and LPC43xx familiy. > > NXP SPIFI is a specialized SPI interface for serial Flash devices. > It supports one Flash device with 1-, 2- and 4-bits width in SPI > mode 0 or 3. The controller operates in either command or memory > mode. In memory mode the Flash is made accessible for the CPU as > normal memory. > > This version fix a bug in the write function discovered during > testing with JFFS2. > > Changes since v3: > - fix bug in write function > - rebase on 4.2-rc1 > > Changes since v2: > - default to auto detection unless chip is specified > - update doc with reference to jedec,spi-nor.txt > > Changes since v1: > - use readb_poll_timeout instead of open coding > - cache current mode (memory/command) > - depend on HAS_IOMEM > - removed stray white space > - removed leftover debug print > > Joachim Eastwood (2): > mtd: spi-nor: add driver for NXP SPI Flash Interface (SPIFI) > doc: dt: add documentation for nxp,lpc1773-spifi > > .../devicetree/bindings/mtd/nxp-spifi.txt | 58 +++ > drivers/mtd/spi-nor/Kconfig| 11 + > drivers/mtd/spi-nor/Makefile | 1 + > drivers/mtd/spi-nor/nxp-spifi.c| 494 > + > 4 files changed, 564 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/nxp-spifi.txt > create mode 100644 drivers/mtd/spi-nor/nxp-spifi.c > > -- > 1.8.0 > -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/7] clocksource: Add Pistachio clocksource-only driver
Hi Daniel,
Thanks for the review!
On 4 August 2015 at 06:21, Daniel Lezcano wrote:
> On 07/27/2015 04:02 PM, Govindraj Raja wrote:
>>
>> From: Ezequiel Garcia
>>
>> The Pistachio SoC provides four general purpose timers, and allow
>> to implement a clocksource driver.
>>
>> This driver can be used as a replacement for the MIPS GIC and MIPS R4K
>> clocksources and sched clocks, which are clocked from the CPU clock.
>>
>> Given the general purpose timers are clocked from an independent clock,
>> this new clocksource driver will be useful to introduce CPUFreq support
>> for Pistachio machines.
>>
>> Signed-off-by: Govindraj Raja
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/clocksource/Kconfig | 4 +
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/time-pistachio.c | 194
>> +++
>> 3 files changed, 199 insertions(+)
>> create mode 100644 drivers/clocksource/time-pistachio.c
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index 4e57730..74e002e 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -111,6 +111,10 @@ config CLKSRC_LPC32XX
>> select CLKSRC_MMIO
>> select CLKSRC_OF
>>
>> +config CLKSRC_PISTACHIO
>> + bool
>> + select CLKSRC_OF
>> +
>> config CLKSRC_STM32
>> bool "Clocksource for STM32 SoCs" if !ARCH_STM32
>> depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
>> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
>> index f228354..066337e 100644
>> --- a/drivers/clocksource/Makefile
>> +++ b/drivers/clocksource/Makefile
>> @@ -44,6 +44,7 @@ obj-$(CONFIG_FSL_FTM_TIMER) += fsl_ftm_timer.o
>> obj-$(CONFIG_VF_PIT_TIMER)+= vf_pit_timer.o
>> obj-$(CONFIG_CLKSRC_QCOM) += qcom-timer.o
>> obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
>> +obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
>>
>> obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
>> obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
>> diff --git a/drivers/clocksource/time-pistachio.c
>> b/drivers/clocksource/time-pistachio.c
>> new file mode 100644
>> index 000..d461bd1
>> --- /dev/null
>> +++ b/drivers/clocksource/time-pistachio.c
>> @@ -0,0 +1,194 @@
>> +/*
>> + * Pistachio clocksource based on general-purpose timers
>> + *
>> + * Copyright (C) 2015 Imagination Technologies
>> + *
>> + * This file is subject to the terms and conditions of the GNU General
>> Public
>> + * License. See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + */
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* Top level reg */
>> +#define CR_TIMER_CTRL_CFG 0x00
>> +#define TIMER_ME_GLOBAL BIT(0)
>
>
> extra space.
>
>> +#define CR_TIMER_REV 0x10
>> +
>> +/* Timer specific registers */
>> +#define TIMER_CFG 0x20
>> +#define TIMER_ME_LOCALBIT(0)
>
>
> extra space.
>
These are not extra spaces, but they are there
to separate register definitions from bit definitions.
Same thing is done on time-armada-370-xp.c.
>
>> +#define TIMER_RELOAD_VALUE 0x24
>> +#define TIMER_CURRENT_VALUE0x28
>> +#define TIMER_CURRENT_OVERFLOW_VALUE 0x2C
>> +#define TIMER_IRQ_STATUS 0x30
>> +#define TIMER_IRQ_CLEAR0x34
>> +#define TIMER_IRQ_MASK 0x38
>> +
>> +#define PERIP_TIMER_CONTROL0x90
>> +
>> +/* Timer specific configuration Values */
>> +#define RELOAD_VALUE 0x
>> +
>> +static void __iomem *timer_base;
>> +static DEFINE_RAW_SPINLOCK(lock);
>> +
>> +static inline u32 gpt_readl(u32 offset, u32 gpt_id)
>> +{
>> + return readl(timer_base + 0x20 * gpt_id + offset);
>> +}
>> +
>> +static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
>> +{
>> + writel(value, timer_base + 0x20 * gpt_id + offset);
>> +}
Re: [PATCH 2/2] DT: pwm: Add NXP LPC18xx PWM/SCT binding documentation
Joachim,
On 30 July 2015 at 20:30, Joachim Eastwood wrote:
> On 29 July 2015 at 15:47, Ezequiel Garcia
> wrote:
>> +devicetree guys
>>
>> On 28 July 2015 at 20:22, Joachim Eastwood wrote:
>>> On 29 July 2015 at 00:45, Ezequiel Garcia
>>> wrote:
>>>> On 28 July 2015 at 19:37, Joachim Eastwood wrote:
>>>>> On 27 July 2015 at 06:45, Ariel D'Alessandro
>>>>> wrote:
>>>>>> Add the devicetree binding document for NXP LPC18xx PWM/SCT.
>>>>>>
>>>>>> Signed-off-by: Ariel D'Alessandro
>>>>>> ---
>>>>>> .../devicetree/bindings/pwm/lpc1850-pwm.txt | 20
>>>>>>
>>>>>> 1 file changed, 20 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>>>> b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>>>> new file mode 100644
>>>>>> index 000..3055429
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +* NXP LPC18xx Pulse Width Modulator driver
>>>>>> +
>>>>>> +Required properties:
>>>>>> + - compatible: Should be "nxp,lpc1850-pwm"
>>>>>> + - reg: Should contain physical base address and length of pwm
>>>>>> registers.
>>>>>> + - clocks: Must contain an entry for each entry in clock-names.
>>>>>> +See ../clock/clock-bindings.txt for details.
>>>>>> + - clock-names: Must include the following entries.
>>>>>> +- pwm: PWM operating clock.
>>>>>> + - #pwm-cells: Should be 3. See pwm.txt in this directory for the
>>>>>> description
>>>>>> +of the cells format.
>>>>>> +
>>>>>> +Example:
>>>>>> + pwm: pwm@4000 {
>>>>>> +compatible = "nxp,lpc1850-pwm";
>>>>>
>>>>> I would prefer "nxp,lpc1850-sct" for a couple of reasons. SCT is the
>>>>> name of hardware block as described in the user manual and while PWM
>>>>> is the most obvious usage for this block on Linux, the hardware is not
>>>>> limited to just doing that. So as a bit of future proofing if someone
>>>>> wants to use this block for more than PWM I would prefer SCT.
>>>>>
>>>>
>>>> Shouldn't we use something like "nxp,lpc1850-sct-pwm"?
>>>>
>>>> Sounds like the word PWM should be in the compatible as it describes
>>>> not only the device, but the device used in a certain way.
>>>>
>>>> Otherwise, how would we use "nxp,lpc1850-sct" to distinguish a PWM from
>>>> e.g. a clocksource/clockevents (we can also use SCT for that)?
>>>
>>> I not sure how to best handle dt bindings with such flexible hardware
>>> blocks.
>>>
>>> But are you suggestion to have multiple drivers for the same hw block?
>>> ie.: "nxp,lpc1850-sct-pwm" for PWM and for example
>>> "nxp,lpc1850-sct-clocksource" for clocksource and then use/enable one
>>> or the other.
>>>
>>
>> Yup, I'm suggesting just that. If the hardware is capable, I can't see
>> why we can't have different drivers for it.
>
> Well, I think it would be nice if we could have one driver per hw
> block. But then you need a way to select whether you want to use the
> counter in the SCT block for PWM or, for example, clocksource. Sort of
> mode selection I guess.
>
> But then again if someone has some very custom and application
> specific usage for the SCT block that maybe better served by a
> standalone driver anyway.
>
Technically speaking, I believe we can use "nxp,lpc1850-sct" to expose
both a PWM interface and a clocksource in a single driver. Not too
clean, though.
Alternatively, we should be able to have a multifunction device (MFD) to mux
the SCT resources to be consumed by different kind of drivers.
Given there's no counter API to feed SCT, and given we use the other
timer hw block to feed clocksource and clockevents for the LPC18/43xx,
I think currently the simplest choice is to have "nxp,lpc1850-sct-pwm"
describing this PWM SCT driver.
If we later want to change completely the PWM SCT driver, we can do
that without any bindings change.
> So for now I am fine with "nxp,lpc1850-sct-pwm". I shouldn't be too
> hard to change the bindings if we see other users of this block, I
> believe.
>
Well, that would break DT backward compatibility, so it's not an ideal.
Like I said, "nxp,lpc1850-sct-pwm" seems to be specific enough to
describe this driver.
I'd like to know what Thierry thinks here.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] DT: pwm: Add NXP LPC18xx PWM/SCT binding documentation
+devicetree guys
On 28 July 2015 at 20:22, Joachim Eastwood wrote:
> On 29 July 2015 at 00:45, Ezequiel Garcia
> wrote:
>> On 28 July 2015 at 19:37, Joachim Eastwood wrote:
>>> On 27 July 2015 at 06:45, Ariel D'Alessandro
>>> wrote:
>>>> Add the devicetree binding document for NXP LPC18xx PWM/SCT.
>>>>
>>>> Signed-off-by: Ariel D'Alessandro
>>>> ---
>>>> .../devicetree/bindings/pwm/lpc1850-pwm.txt | 20
>>>>
>>>> 1 file changed, 20 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>> b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>> new file mode 100644
>>>> index 000..3055429
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/pwm/lpc1850-pwm.txt
>>>> @@ -0,0 +1,20 @@
>>>> +* NXP LPC18xx Pulse Width Modulator driver
>>>> +
>>>> +Required properties:
>>>> + - compatible: Should be "nxp,lpc1850-pwm"
>>>> + - reg: Should contain physical base address and length of pwm registers.
>>>> + - clocks: Must contain an entry for each entry in clock-names.
>>>> +See ../clock/clock-bindings.txt for details.
>>>> + - clock-names: Must include the following entries.
>>>> +- pwm: PWM operating clock.
>>>> + - #pwm-cells: Should be 3. See pwm.txt in this directory for the
>>>> description
>>>> +of the cells format.
>>>> +
>>>> +Example:
>>>> + pwm: pwm@4000 {
>>>> +compatible = "nxp,lpc1850-pwm";
>>>
>>> I would prefer "nxp,lpc1850-sct" for a couple of reasons. SCT is the
>>> name of hardware block as described in the user manual and while PWM
>>> is the most obvious usage for this block on Linux, the hardware is not
>>> limited to just doing that. So as a bit of future proofing if someone
>>> wants to use this block for more than PWM I would prefer SCT.
>>>
>>
>> Shouldn't we use something like "nxp,lpc1850-sct-pwm"?
>>
>> Sounds like the word PWM should be in the compatible as it describes
>> not only the device, but the device used in a certain way.
>>
>> Otherwise, how would we use "nxp,lpc1850-sct" to distinguish a PWM from
>> e.g. a clocksource/clockevents (we can also use SCT for that)?
>
> I not sure how to best handle dt bindings with such flexible hardware blocks.
>
> But are you suggestion to have multiple drivers for the same hw block?
> ie.: "nxp,lpc1850-sct-pwm" for PWM and for example
> "nxp,lpc1850-sct-clocksource" for clocksource and then use/enable one
> or the other.
>
Yup, I'm suggesting just that. If the hardware is capable, I can't see
why we can't have different drivers for it.
> So I am not sure how to best handle this, but I think we should at
> least consider more than just PWM usage for this hw block. Note that
> not against calling it "lpc1850-sct-pwm", I like that better than just
> "lpc1850-pwm".
>
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] reset driver for NXP LPC18xx family
On 05/07/2015 10:01 AM, Philipp Zabel wrote: > Am Mittwoch, den 06.05.2015, 00:10 +0200 schrieb Joachim Eastwood: >> This patch set adds a reset driver for NXP LPC18xx/43xx devices. >> >> Changes in v3: >> * add patch descriptions >> * change parameter name in to_rgu_data macro to avoid a potential >> issue if code is changed. >> >> Changes in v2: >> * clean up header includes >> * prefix M0 reset defines with LPC43XX >> * fix comment about M0 reset lines >> * reorganize reset call chains >> * add reset number table to dt doc >> >> There are no dependencies in this patch set. The DTS changes will >> be sent separately to arm-soc once this patch set goes upstream. >> >> Base support for the NXP LPC18xx family can be found here: >> http://marc.info/?l=linux-arm-kernel&m=143016894704253&w=2 >> >> Joachim Eastwood (2): >> reset: add driver for lpc18xx rgu >> doc: dt: add documentation for lpc1850-rgu reset driver > > Applied both, thanks. > Philipp, Any chance we can have the reset controllers' tree to linux-next? Thanks! -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] mtd: spi-nor: add driver for NXP SPI Flash Interface (SPIFI)
Joachim,
I tested the driver and found an issue with it.
On 05/31/2015 06:06 PM, Joachim Eastwood wrote:
> +
> + spifi->mtd.priv = &spifi->nor;
> + spifi->nor.mtd = &spifi->mtd;
> + spifi->nor.dev = spifi->dev;
> + spifi->nor.priv = spifi;
> + spifi->nor.read = nxp_spifi_read;
> + spifi->nor.write = nxp_spifi_write;
> + spifi->nor.erase = nxp_spifi_erase;
> + spifi->nor.read_reg = nxp_spifi_read_reg;
> + spifi->nor.write_reg = nxp_spifi_write_reg;
> +
> + ret = of_modalias_node(np, modalias, sizeof(modalias));
> + if (ret < 0) {
> + dev_err(spifi->dev, "unable to get device modalias\n");
> + return ret;
> + }
> +
> + /*
> + * The first read on a hard reset isn't reliable so do a
> + * dummy read of the id before calling spi_nor_scan().
> + * The reason for this problem is unknown.
> + *
> + * The official NXP spifilib uses more or less the same
> + * workaround that is applied here by reading the device
> + * id multiple times.
> + */
> + nxp_spifi_dummy_id_read(&spifi->nor);
> +
Actually, I think there's an issue here. See how m25p80 deals
with modalias:
[..]
else if (!strcmp(spi->modalias, "spi-nor"))
flash_name = NULL; /* auto-detect */
else
flash_name = spi->modalias;
ret = spi_nor_scan(nor, flash_name, mode);
if (ret)
return ret;
I think the "auto-detect" quirk is really needed, or you are will
otherwise fail to probe with the generic "jedec,spi-nor" compatible
string.
Notice that the binding specifies the chip-specific compatible
as optional (it says _May_):
- compatible : May include a device-specific string consisting of the
manufacturer and name of the chip.
> + ret = spi_nor_scan(&spifi->nor, modalias, flash_read);
> + if (ret) {
> + dev_err(spifi->dev, "device scan failed\n");
> + return ret;
> + }
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mtd: spi-nor: add driver for NXP SPI Flash Interface (SPIFI)
On 05/30/2015 04:37 PM, Joachim Eastwood wrote: > On 30 May 2015 at 21:33, Richard Weinberger wrote: >> Am 30.05.2015 um 20:08 schrieb Ezequiel Garcia: >>> +Richard >>> >>> On 05/30/2015 01:51 PM, Joachim Eastwood wrote: >>>> Hi Ezequiel, >>>> >>>> On 30 May 2015 at 17:43, Ezequiel Garcia >>>> wrote: >>>>> Hi Joachim, >>>>> >>>>> Looks pretty neat. I've just a couple comments. >>>>> >>>>> On 05/29/2015 02:50 PM, Joachim Eastwood wrote: >>>>>> Add SPI-NOR driver for the SPI Flash Interface (SPIFI) >>>>>> controller that is found newer NXP MCU devices. >>>>>> >>>>>> The controller supports serial SPI Flash devices with 1-, 2- >>>>>> and 4-bit width in either SPI mode 0 or 3. The controller >>>>>> can operate in either command or memory mode. In memory mode >>>>>> the Flash is exposed as normal memory and can be directly >>>>>> accessed by the CPU. >>>>>> >>>>>> Signed-off-by: Joachim Eastwood >>>>>> --- >>>>>> drivers/mtd/spi-nor/Kconfig | 10 + >>>>>> drivers/mtd/spi-nor/Makefile| 1 + >>>>>> drivers/mtd/spi-nor/nxp-spifi.c | 508 >>>>>> >>>>>> 3 files changed, 519 insertions(+) >>>>>> create mode 100644 drivers/mtd/spi-nor/nxp-spifi.c >>>>>> >>>>>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig >>>>>> index 64a4f0edabc7..f10a37f1a4ef 100644 >>>>>> --- a/drivers/mtd/spi-nor/Kconfig >>>>>> +++ b/drivers/mtd/spi-nor/Kconfig >>>>>> @@ -28,4 +28,14 @@ config SPI_FSL_QUADSPI >>>>>> This enables support for the Quad SPI controller in master mode. >>>>>> We only connect the NOR to this controller now. >>>>>> >>>>>> +config SPI_NXP_SPIFI >>>>>> + tristate "NXP SPI Flash Interface (SPIFI)" >>>>>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST) >>>>> >>>>> Since you are adding COMPILE_TEST, maybe you want >>>>> 'depends on HAS_IOMEM' as well? >>>> >>>> Since MTD depends on GENERIC_IO is that needed? >>>> Or am I confusing the config options here(?) >>>> >>> >>> I think you need HAS_IOMEM for ioremap stuff. >>> Maybe Brian or Richard will know better. >> >> Yes, if you need ioremap() your driver has to depend on HAS_IOMEM. >> >> We have GENERIC_IO to allow non-physical MTD stuff >> on architectures without io memory, namely s390 and UML. >> Some time ago I've implemented GENERIC_IO to make nandsim >> and UBI work on UML. > > Got it. > Thanks Richard. > > I'll send a new version of the patch within a couple of days. > You can add my reviewed on that. Reviewed-by: Ezequiel Garcia -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mtd: spi-nor: add driver for NXP SPI Flash Interface (SPIFI)
+Richard
On 05/30/2015 01:51 PM, Joachim Eastwood wrote:
> Hi Ezequiel,
>
> On 30 May 2015 at 17:43, Ezequiel Garcia
> wrote:
>> Hi Joachim,
>>
>> Looks pretty neat. I've just a couple comments.
>>
>> On 05/29/2015 02:50 PM, Joachim Eastwood wrote:
>>> Add SPI-NOR driver for the SPI Flash Interface (SPIFI)
>>> controller that is found newer NXP MCU devices.
>>>
>>> The controller supports serial SPI Flash devices with 1-, 2-
>>> and 4-bit width in either SPI mode 0 or 3. The controller
>>> can operate in either command or memory mode. In memory mode
>>> the Flash is exposed as normal memory and can be directly
>>> accessed by the CPU.
>>>
>>> Signed-off-by: Joachim Eastwood
>>> ---
>>> drivers/mtd/spi-nor/Kconfig | 10 +
>>> drivers/mtd/spi-nor/Makefile| 1 +
>>> drivers/mtd/spi-nor/nxp-spifi.c | 508
>>>
>>> 3 files changed, 519 insertions(+)
>>> create mode 100644 drivers/mtd/spi-nor/nxp-spifi.c
>>>
>>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>>> index 64a4f0edabc7..f10a37f1a4ef 100644
>>> --- a/drivers/mtd/spi-nor/Kconfig
>>> +++ b/drivers/mtd/spi-nor/Kconfig
>>> @@ -28,4 +28,14 @@ config SPI_FSL_QUADSPI
>>> This enables support for the Quad SPI controller in master mode.
>>> We only connect the NOR to this controller now.
>>>
>>> +config SPI_NXP_SPIFI
>>> + tristate "NXP SPI Flash Interface (SPIFI)"
>>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>>
>> Since you are adding COMPILE_TEST, maybe you want
>> 'depends on HAS_IOMEM' as well?
>
> Since MTD depends on GENERIC_IO is that needed?
> Or am I confusing the config options here(?)
>
I think you need HAS_IOMEM for ioremap stuff.
Maybe Brian or Richard will know better.
>>> +static int nxp_spifi_wait_for_event(struct nxp_spifi *spifi, u32 event)
>>> +{
>>> + int retry = 3;
>>> + u32 stat;
>>> +
>>> + do {
>>> + stat = readb(spifi->io_base + SPIFI_STAT);
>>> + if (!(stat & event))
>>> + return 0;
>>> +
>>> + udelay(10);
>>> + } while (retry--);
>>> +
>>> + return -ETIMEDOUT;
>>
>> This could be replaced with the readb_poll_timeout_atomic().
>> But it seems you would also use readb_poll_timeout(), since won't be
>> called in atomic context.
>
> Didn't know about the readX_poll_timeout functions and does indeed
> look usable. Thanks for the tip.
>
>
>>> +static int nxp_spifi_set_memory_mode_on(struct nxp_spifi *spifi)
>>> +{
>>> + int retry = 3;
>>> + u32 stat;
>>> +
>>> + stat = readb(spifi->io_base + SPIFI_STAT);
>>> + if (stat & SPIFI_STAT_MCINIT)
>>> + return 0;
>>
>> Do you think it makes sense to cache the memory/command mode
>> instead of reading it?
>
> I think that's good idea.
>
>> Would it affect throughput in any sense?
>
> Maybe. It's done for every read/write operation so making it a bit
> faster is good idea. I don't see any downsides to implement it the way
> you suggest either.
>
>
>> I'm thinking these slow-clocked microcontrollers might benefit from
>> such tricks, but I don't have actual numbers to back this up.
>>
>>> +
>>> + writel(spifi->mcmd, spifi->io_base + SPIFI_MCMD);
>>> +
>>> + do {
>>> + stat = readb(spifi->io_base + SPIFI_STAT);
>>> + if (stat & SPIFI_STAT_MCINIT)
>>> + return 0;
>>> +
>>> + udelay(10);
>>> + } while (retry--);
>>
>> Same here about using iopoll variants.
>
> Yeah, got it.
>
>
>>> +
>>> + dev_err(spifi->dev, "unable to enter memory mode\n");
>>> +
>>> + return -ETIMEDOUT;
>>> +}
>>> +
>>> +static int nxp_spifi_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int
>>> len)
>>> +{
>>> + struct nxp_spifi *spifi = nor->priv;
>>> + u32 cmd;
>>> + int ret;
>>> +
>>> + ret = nxp_spifi_set_memory_mode_off(spifi);
>>> + if (ret)
>>> + return ret;
>>> +
>>> +
Re: [PATCH 1/2] mtd: spi-nor: add driver for NXP SPI Flash Interface (SPIFI)
ritel(ctrl, spifi->io_base + SPIFI_CTRL);
> + dev_info(spifi->dev, "spifi ctrl = 0x%08x\n", ctrl);
> +
> + spifi->mtd.priv = &spifi->nor;
> + spifi->nor.mtd = &spifi->mtd;
> + spifi->nor.dev = spifi->dev;
> + spifi->nor.priv = spifi;
> + spifi->nor.read = nxp_spifi_read;
> + spifi->nor.write = nxp_spifi_write;
> + spifi->nor.erase = nxp_spifi_erase;
> + spifi->nor.read_reg = nxp_spifi_read_reg;
> + spifi->nor.write_reg = nxp_spifi_write_reg;
> +
> + ret = of_modalias_node(np, modalias, sizeof(modalias));
> + if (ret < 0) {
> + dev_err(spifi->dev, "unable to get device modalias\n");
> + return ret;
> + }
> +
> + /*
> + * The first read on a hard reset isn't reliable so do a
> + * dummy read of the id before calling spi_nor_scan().
> + * The reason for this problem is unknown.
> + *
> + * The official NXP spifilib uses more or less the same
> + * workaround that is applied here by reading the device
> + * id multiple times.
> + */
> + nxp_spifi_dummy_id_read(&spifi->nor);
> +
> + ret = spi_nor_scan(&spifi->nor, modalias, flash_read);
> + if (ret) {
> + dev_err(spifi->dev, "device scan failed\n");
> + return ret;
> + }
> +
> + ret = nxp_spifi_setup_memory_cmd(spifi);
> + if (ret) {
> + dev_err(spifi->dev, "memory command setup failed\n");
> + return ret;
> + }
> +
> + ppdata.of_node = np;
> + ret = mtd_device_parse_register(&spifi->mtd, NULL, &ppdata, NULL, 0);
> + if (ret) {
> + dev_err(spifi->dev, "mtd device parse failed\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int nxp_spifi_probe(struct platform_device *pdev)
> +{
> + struct device_node *flash_np;
> + struct nxp_spifi *spifi;
> + struct resource *res;
> + int ret;
> +
> + spifi = devm_kzalloc(&pdev->dev, sizeof(*spifi), GFP_KERNEL);
> + if (!spifi)
> + return -ENOMEM;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "spifi");
> + spifi->io_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(spifi->io_base))
> + return PTR_ERR(spifi->io_base);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "flash");
> + spifi->flash_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(spifi->flash_base))
> + return PTR_ERR(spifi->flash_base);
> +
Just curious: is the memory mapping fixed?
> + spifi->clk_spifi = devm_clk_get(&pdev->dev, "spifi");
> + if (IS_ERR(spifi->clk_spifi)) {
> + dev_err(&pdev->dev, "spifi clock not found\n");
> + return PTR_ERR(spifi->clk_spifi);
> + }
> +
> + spifi->clk_reg = devm_clk_get(&pdev->dev, "reg");
> + if (IS_ERR(spifi->clk_reg)) {
> + dev_err(&pdev->dev, "reg clock not found\n");
> + return PTR_ERR(spifi->clk_reg);
> + }
> +
> + ret = clk_prepare_enable(spifi->clk_reg);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to enable reg clock\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(spifi->clk_spifi);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to enable spifi clock\n");
> + goto dis_clk_reg;
> + }
> +
> + spifi->dev = &pdev->dev;
> + platform_set_drvdata(pdev, spifi);
> +
> + /* Initialize and reset device */
> + nxp_spifi_reset(spifi);
> + writel(0, spifi->io_base + SPIFI_IDATA);
> + writel(0, spifi->io_base + SPIFI_MCMD);
> + nxp_spifi_reset(spifi);
> +
> + flash_np = of_get_next_available_child(pdev->dev.of_node, NULL);
> + if (!flash_np) {
> + dev_err(&pdev->dev, "no spi flash device to configure\n");
> + ret = -ENODEV;
> + goto dis_clks;
> + }
> +
> + ret = nxp_spifi_setup_flash(spifi, flash_np);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to setup flash chip\n");
> + goto dis_clks;
> + }
> +
> + return 0;
> +
> +dis_clks:
> + clk_disable_unprepare(spifi->clk_spifi);
> +dis_clk_reg:
> + clk_disable_unprepare(spifi->clk_reg);
> + return ret;
> +}
> +
> +static int nxp_spifi_remove(struct platform_device *pdev)
> +{
> + struct nxp_spifi *spifi = platform_get_drvdata(pdev);
> +
> + mtd_device_unregister(&spifi->mtd);
> + clk_disable_unprepare(spifi->clk_spifi);
> + clk_disable_unprepare(spifi->clk_reg);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id nxp_spifi_match[] = {
> + {.compatible = "nxp,lpc1773-spifi"},
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, nxp_spifi_match);
> +
> +static struct platform_driver nxp_spifi_driver = {
> + .probe = nxp_spifi_probe,
> + .remove = nxp_spifi_remove,
> + .driver = {
> + .name = "nxp-spifi",
> + .of_match_table = nxp_spifi_match,
> + },
> +};
> +module_platform_driver(nxp_spifi_driver);
> +
> +MODULE_DESCRIPTION("NXP SPI Flash Interface driver");
> +MODULE_AUTHOR("Joachim Eastwood ");
> +MODULE_LICENSE("GPL v2");
>
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] clocksource: Add Pistachio SoC general purpose timer binding document
Add a device-tree binding document for the clocksource driver provided
by Pistachio SoC general purpose timers.
Reviewed-by: Andrew Bresticker
Signed-off-by: Ezequiel Garcia
---
Changes from v2:
* Fix spacing for consistency as pointed out by Sergei.
Changes from v1:
* No changes.
.../bindings/timer/img,pistachio-gptimer.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
diff --git a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
new file mode 100644
index 000..7afce80
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
@@ -0,0 +1,28 @@
+* Pistachio general-purpose timer based clocksource
+
+Required properties:
+ - compatible: "img,pistachio-gptimer".
+ - reg: Address range of the timer registers.
+ - interrupts: An interrupt for each of the four timers
+ - clocks: Should contain a clock specifier for each entry in clock-names
+ - clock-names: Should contain the following entries:
+"sys", interface clock
+"slow", slow counter clock
+"fast", fast counter clock
+ - img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node.
+
+Example:
+ timer: timer@18102000 {
+ compatible = "img,pistachio-gptimer";
+ reg = <0x18102000 0x100>;
+ interrupts = ,
+,
+,
+;
+ clocks = <&clk_periph PERIPH_CLK_COUNTER_FAST>,
+<&clk_periph PERIPH_CLK_COUNTER_SLOW>,
+<&cr_periph SYS_CLK_TIMER>;
+ clock-names = "fast", "slow", "sys";
+ img,cr-periph = <&cr_periph>;
+ };
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] mips: pistachio: Allow to enable the external timer based clocksource
This commit introduces a new config, so the user can choose to enable the General Purpose Timer based clocksource. This option is required to have CPUFreq support. Signed-off-by: Ezequiel Garcia --- arch/mips/Kconfig | 1 + arch/mips/pistachio/Kconfig | 13 + 2 files changed, 14 insertions(+) create mode 100644 arch/mips/pistachio/Kconfig diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f501665..91f6ca0 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -934,6 +934,7 @@ source "arch/mips/jazz/Kconfig" source "arch/mips/jz4740/Kconfig" source "arch/mips/lantiq/Kconfig" source "arch/mips/lasat/Kconfig" +source "arch/mips/pistachio/Kconfig" source "arch/mips/pmcs-msp71xx/Kconfig" source "arch/mips/ralink/Kconfig" source "arch/mips/sgi-ip27/Kconfig" diff --git a/arch/mips/pistachio/Kconfig b/arch/mips/pistachio/Kconfig new file mode 100644 index 000..97731ea --- /dev/null +++ b/arch/mips/pistachio/Kconfig @@ -0,0 +1,13 @@ +config PISTACHIO_GPTIMER_CLKSRC + bool "Enable General Purpose Timer based clocksource" + depends on MACH_PISTACHIO + select CLKSRC_PISTACHIO + select MIPS_EXTERNAL_TIMER + help + This option enables a clocksource driver based on a Pistachio + SoC General Purpose external timer. + + If you want to enable the CPUFreq, you need to enable + this option. + + If you don't want to enable CPUFreq, you can leave this disabled. -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] clocksource: mips-gic: Update clockevent frequency on clock rate changes
This commit introduces the clockevent frequency update, using
a clock notifier. It will be used to support CPUFreq on platforms
using MIPS GIC based clockevents.
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index 22a4daf..a155bec 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -79,6 +79,13 @@ static void gic_clockevent_cpu_exit(struct
clock_event_device *cd)
disable_percpu_irq(gic_timer_irq);
}
+static void gic_update_frequency(void *data)
+{
+ unsigned long rate = (unsigned long)data;
+
+ clockevents_update_freq(this_cpu_ptr(&gic_clockevent_device), rate);
+}
+
static int gic_cpu_notifier(struct notifier_block *nb, unsigned long action,
void *data)
{
@@ -94,10 +101,26 @@ static int gic_cpu_notifier(struct notifier_block *nb,
unsigned long action,
return NOTIFY_OK;
}
+static int gic_clk_notifier(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct clk_notifier_data *cnd = data;
+
+ if (action == POST_RATE_CHANGE)
+ on_each_cpu(gic_update_frequency, (void *)cnd->new_rate, 1);
+
+ return NOTIFY_OK;
+}
+
+
static struct notifier_block gic_cpu_nb = {
.notifier_call = gic_cpu_notifier,
};
+static struct notifier_block gic_clk_nb = {
+ .notifier_call = gic_clk_notifier,
+};
+
static int gic_clockevent_init(void)
{
int ret;
@@ -160,6 +183,7 @@ void __init gic_clocksource_init(unsigned int frequency)
static void __init gic_clocksource_of_init(struct device_node *node)
{
struct clk *clk;
+ int ret;
if (WARN_ON(!gic_present || !node->parent ||
!of_device_is_compatible(node->parent, "mti,gic")))
@@ -186,7 +210,12 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
}
__gic_clocksource_init();
- gic_clockevent_init();
+
+ ret = gic_clockevent_init();
+ if (!ret && !IS_ERR(clk)) {
+ if (clk_notifier_register(clk, &gic_clk_nb) < 0)
+ pr_warn("GIC: Unable to register clock notifier\n");
+ }
/* And finally start the counter */
gic_start_count();
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] clocksource: Add Pistachio clocksource-only driver
The Pistachio SoC provides four general purpose timers, and allow
to implement a clocksource driver.
This driver can be used as a replacement for the MIPS GIC and MIPS R4K
clocksources and sched clocks, which are clocked from the CPU clock.
Given the general purpose timers are clocked from an independent clock,
this new clocksource driver will be useful to introduce CPUFreq support
for Pistachio machines.
Signed-off-by: Govindraj Raja
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/Kconfig | 4 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/time-pistachio.c | 194 +++
3 files changed, 199 insertions(+)
create mode 100644 drivers/clocksource/time-pistachio.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 51d7865f..faa16ae 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -106,6 +106,10 @@ config CLKSRC_EFM32
Support to use the timers of EFM32 SoCs as clock source and clock
event device.
+config CLKSRC_PISTACHIO
+ bool
+ select CLKSRC_OF
+
config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5b85f6a..9415def 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_FSL_FTM_TIMER) += fsl_ftm_timer.o
obj-$(CONFIG_VF_PIT_TIMER) += vf_pit_timer.o
obj-$(CONFIG_CLKSRC_QCOM) += qcom-timer.o
obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
+obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/time-pistachio.c
b/drivers/clocksource/time-pistachio.c
new file mode 100644
index 000..d461bd1
--- /dev/null
+++ b/drivers/clocksource/time-pistachio.c
@@ -0,0 +1,194 @@
+/*
+ * Pistachio clocksource based on general-purpose timers
+ *
+ * Copyright (C) 2015 Imagination Technologies
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Top level reg */
+#define CR_TIMER_CTRL_CFG 0x00
+#define TIMER_ME_GLOBAL BIT(0)
+#define CR_TIMER_REV 0x10
+
+/* Timer specific registers */
+#define TIMER_CFG 0x20
+#define TIMER_ME_LOCALBIT(0)
+#define TIMER_RELOAD_VALUE 0x24
+#define TIMER_CURRENT_VALUE0x28
+#define TIMER_CURRENT_OVERFLOW_VALUE 0x2C
+#define TIMER_IRQ_STATUS 0x30
+#define TIMER_IRQ_CLEAR0x34
+#define TIMER_IRQ_MASK 0x38
+
+#define PERIP_TIMER_CONTROL0x90
+
+/* Timer specific configuration Values */
+#define RELOAD_VALUE 0x
+
+static void __iomem *timer_base;
+static DEFINE_RAW_SPINLOCK(lock);
+
+static inline u32 gpt_readl(u32 offset, u32 gpt_id)
+{
+ return readl(timer_base + 0x20 * gpt_id + offset);
+}
+
+static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
+{
+ writel(value, timer_base + 0x20 * gpt_id + offset);
+}
+
+static cycle_t pistachio_clocksource_read_cycles(struct clocksource *cs)
+{
+ u32 counter, overflw;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&lock, flags);
+ overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
+ counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
+ raw_spin_unlock_irqrestore(&lock, flags);
+
+ return ~(cycle_t)counter;
+}
+
+static u64 notrace pistachio_read_sched_clock(void)
+{
+ return pistachio_clocksource_read_cycles(NULL);
+}
+
+static void pistachio_clksrc_enable(int timeridx)
+{
+ u32 val;
+
+ /* Disable GPT local before loading reload value */
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val &= ~TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+
+ gpt_writel(RELOAD_VALUE, TIMER_RELOAD_VALUE, timeridx);
+
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val |= TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+}
+
+static void pistachio_clksrc_disable(int timeridx)
+{
+ u32 val;
+
+ /* Disable GPT local */
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val &= ~TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+}
+
+static int pistachio_clocksource_enable(struct clocksource *cs)
+{
+ pistachio_clksrc_enable(0);
+ return 0;
+}
+
+static void pistachio_clocksource_disable(struct clocksource *cs)
+{
+ pistachio_clksrc_disable(0);
+}
+
+/* Desirable clock source for
[PATCH v2 5/7] clocksource: Add Pistachio SoC general purpose timer binding document
Add a device-tree binding document for the clocksource driver provided
by Pistachio SoC general purpose timers.
Reviewed-by: Andrew Bresticker
Signed-off-by: Ezequiel Garcia
---
.../bindings/timer/img,pistachio-gptimer.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
diff --git a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
new file mode 100644
index 000..418379f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
@@ -0,0 +1,28 @@
+* Pistachio general-purpose timer based clocksource
+
+Required properties:
+ - compatible: "img,pistachio-gptimer".
+ - reg: Address range of the timer registers.
+ - interrupts: An interrupt for each of the four timers
+ - clocks : Should contain a clock specifier for each entry in clock-names
+ - clock-names : Should contain the following entries:
+"sys", interface clock
+"slow", slow counter clock
+"fast", fast counter clock
+ - img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node.
+
+Example:
+ timer: timer@18102000 {
+ compatible = "img,pistachio-gptimer";
+ reg = <0x18102000 0x100>;
+ interrupts = ,
+,
+,
+;
+ clocks = <&clk_periph PERIPH_CLK_COUNTER_FAST>,
+<&clk_periph PERIPH_CLK_COUNTER_SLOW>,
+<&cr_periph SYS_CLK_TIMER>;
+ clock-names = "fast", "slow", "sys";
+ img,cr-periph = <&cr_periph>;
+ };
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] clocksource: mips-gic: Enable the clock before using it
For the clock to be used (e.g. get its rate through clk_get_rate)
it should be prepared and enabled first.
Also, while the clock is enabled the driver must hold a reference to it,
so let's remove the call to clk_put.
Reviewed-by: Andrew Bresticker
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index b81ed1a..913585d 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -158,8 +158,13 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
clk = of_clk_get(node, 0);
if (!IS_ERR(clk)) {
+ if (clk_prepare_enable(clk) < 0) {
+ pr_err("GIC failed to enable clock\n");
+ clk_put(clk);
+ return;
+ }
+
gic_frequency = clk_get_rate(clk);
- clk_put(clk);
} else if (of_property_read_u32(node, "clock-frequency",
&gic_frequency)) {
pr_err("GIC frequency not specified.\n");
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Clocksource changes for Pistachio CPUFreq
The purpose of this patchset is to support CPUFreq on Pistachio SoC. However, given Pistachio uses the MIPS GIC clocksource and clockevent drivers (clocked from the CPU), adding CPUFreq support needs some work. This patchset changes the MIPS GIC clockevent driver to update the frequency of the per-cpu clockevents using a clock notifier. Then, we add a clocksource driver for IMG Pistachio SoC, based on the general purpose timers. The SoC only provides four timers, so we can't use them to implement the four clockevents and the clocksource. However, we can use one of these timers to provide a clocksource and a sched clock. Given the general purpose timers are clocked from the peripheral system clock tree, they are not affected by CPU rate changes. Patches 1 to 3 are just style cleaning and preparation work. Patch 4 adds the clockevent frequency update. Patches 5 and 6 add the new clocksource driver. Patch 7 introduces an option to enable the timer based clocksource on Pistachio. For CPUFreq to really work, clk driver changes are needed to support MIPS PLL clock rate change. Patches for this will be posted soon. This series apply on v4.1-rc5. As always, comments and feedback are welcome! Changes since v1 Addressed review comments by Andrew: * Fix typo * Fix style issues * Use readl/writel accessors instead of raw variants * Drop spurious comment and of_device_id table * Add a pistachio_ prefix to clocksource functions Ezequiel Garcia (7): clocksource: mips-gic: Enable the clock before using it clocksource: mips-gic: Add missing error returns checks clocksource: mips-gic: Split clocksource and clockevent initialization clocksource: mips-gic: Update clockevent frequency on clock rate changes clocksource: Add Pistachio SoC general purpose timer binding document clocksource: Add Pistachio clocksource-only driver mips: pistachio: Allow to enable the external timer based clocksource .../bindings/timer/img,pistachio-gptimer.txt | 28 +++ arch/mips/Kconfig | 1 + arch/mips/pistachio/Kconfig| 13 ++ drivers/clocksource/Kconfig| 4 + drivers/clocksource/Makefile | 1 + drivers/clocksource/mips-gic-timer.c | 65 ++- drivers/clocksource/time-pistachio.c | 194 + 7 files changed, 297 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt create mode 100644 arch/mips/pistachio/Kconfig create mode 100644 drivers/clocksource/time-pistachio.c -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization
This is preparation work for the introduction of clockevent frequency
update with a clock notifier. This is only possible when the device
is passed a clk struct, so let's split the legacy and devicetree
initialization.
Reviewed-by: Andrew Bresticker
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index c4352f0..22a4daf 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
ret = clocksource_register_hz(&gic_clocksource, gic_frequency);
if (ret < 0)
pr_warn("GIC: Unable to register clocksource\n");
-
- gic_clockevent_init();
-
- /* And finally start the counter */
- gic_start_count();
}
void __init gic_clocksource_init(unsigned int frequency)
@@ -156,6 +151,10 @@ void __init gic_clocksource_init(unsigned int frequency)
GIC_LOCAL_TO_HWIRQ(GIC_LOCAL_INT_COMPARE);
__gic_clocksource_init();
+ gic_clockevent_init();
+
+ /* And finally start the counter */
+ gic_start_count();
}
static void __init gic_clocksource_of_init(struct device_node *node)
@@ -187,6 +186,10 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
}
__gic_clocksource_init();
+ gic_clockevent_init();
+
+ /* And finally start the counter */
+ gic_start_count();
}
CLOCKSOURCE_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
gic_clocksource_of_init);
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] clocksource: mips-gic: Add missing error returns checks
This commit adds the required checks on the functions that return
an error. Some of them are not critical, so only a warning is
printed.
Reviewed-by: Andrew Bresticker
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index 913585d..c4352f0 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -100,12 +100,18 @@ static struct notifier_block gic_cpu_nb = {
static int gic_clockevent_init(void)
{
+ int ret;
+
if (!cpu_has_counter || !gic_frequency)
return -ENXIO;
- setup_percpu_irq(gic_timer_irq, &gic_compare_irqaction);
+ ret = setup_percpu_irq(gic_timer_irq, &gic_compare_irqaction);
+ if (ret < 0)
+ return ret;
- register_cpu_notifier(&gic_cpu_nb);
+ ret = register_cpu_notifier(&gic_cpu_nb);
+ if (ret < 0)
+ pr_warn("GIC: Unable to register CPU notifier\n");
gic_clockevent_cpu_init(this_cpu_ptr(&gic_clockevent_device));
@@ -125,13 +131,17 @@ static struct clocksource gic_clocksource = {
static void __init __gic_clocksource_init(void)
{
+ int ret;
+
/* Set clocksource mask. */
gic_clocksource.mask = CLOCKSOURCE_MASK(gic_get_count_width());
/* Calculate a somewhat reasonable rating value. */
gic_clocksource.rating = 200 + gic_frequency / 1000;
- clocksource_register_hz(&gic_clocksource, gic_frequency);
+ ret = clocksource_register_hz(&gic_clocksource, gic_frequency);
+ if (ret < 0)
+ pr_warn("GIC: Unable to register clocksource\n");
gic_clockevent_init();
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] clocksource: Add Pistachio clocksource-only driver
On 05/22/2015 01:48 PM, Andrew Bresticker wrote:
> On Thu, May 21, 2015 at 2:41 PM, Ezequiel Garcia
> wrote:
>> The Pistachio SoC provides four general purpose timers, and allow
>> to implement a clocksource driver.
>>
>> This driver can be used as a replacement for the MIPS GIC and MIPS R4K
>> clocksources and sched clocks, which are clocked from the CPU clock.
>>
>> Given the general purpose timers are clocked from an independent clock,
>> this new clocksource driver will be useful to introduce CPUFreq support
>> for Pistachio machines.
>>
>> Signed-off-by: Govindraj Raja
>> Signed-off-by: Ezequiel Garcia
>
>> --- /dev/null
>> +++ b/drivers/clocksource/time-pistachio.c
>
>> @@ -0,0 +1,202 @@
>> +/*
>> + * Pistachio clocksource based on general-purpose timers
>> + *
>> + * Copyright (C) 2015 Imagination Technologies
>> + *
>> + * This file is subject to the terms and conditions of the GNU General
>> Public
>> + * License. See the file "COPYING" in the main directory of this archive
>> + * for more details.
>> + */
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/* Top level reg */
>> +#defineCR_TIMER_CTRL_CFG 0x00
>> + #define TIMER_ME_GLOBAL BIT(0)
>> +#defineCR_TIMER_REV0x10
>> +
>> +/* Timer specific registers */
>> +#define TIMER_CFG 0x20
>> + #define TIMER_ME_LOCAL BIT(0)
>> +#define TIMER_RELOAD_VALUE 0x24
>> +#define TIMER_CURRENT_VALUE0x28
>> +#define TIMER_CURRENT_OVERFLOW_VALUE 0x2C
>> +#define TIMER_IRQ_STATUS 0x30
>> +#define TIMER_IRQ_CLEAR0x34
>> +#define TIMER_IRQ_MASK 0x38
>
> nit: the spacing in these two sets of #defines is inconsistent and the
> space at the beginning of the line looks a little weird to me, maybe
> just do something like this:
>
> #define REGISTER ...
> #define REGISTER_FIELD ...
>
Done.
>> +
>> +#define PERIP_TIMER_CONTROL0x90
>> +
>> +/* Timer specific configuration Values */
>> +#define RELOAD_VALUE 0x
>> +
>> +static void __iomem *timer_base;
>> +static DEFINE_RAW_SPINLOCK(lock);
>> +
>> +static inline u32 gpt_readl(u32 offset, u32 gpt_id)
>> +{
>> + return __raw_readl(timer_base + 0x20 * gpt_id + offset);
>> +}
>> +
>> +static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
>> +{
>> + __raw_writel(value, timer_base + 0x20 * gpt_id + offset);
>> +}
>
> Why raw iomem accessors?
>
For no good reason, it was a blind copy-paste. I'll change that to
standard accessors.
>> +static cycle_t clocksource_read_cycles(struct clocksource *cs)
>> +{
>> + u32 counter, overflw;
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&lock, flags);
>> + overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
>> + counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
>> + raw_spin_unlock_irqrestore(&lock, flags);
>> +
>> + return ~(cycle_t)counter;
>> +}
>> +
>> +static u64 notrace pistachio_read_sched_clock(void)
>> +{
>> + return clocksource_read_cycles(NULL);
>> +}
>> +
>> +static void pistachio_clksrc_enable(int timeridx)
>> +{
>> + u32 val;
>> +
>> + /* Disable GPT local before loading reload value */
>> + val = gpt_readl(TIMER_CFG, timeridx);
>> + val &= ~TIMER_ME_LOCAL;
>> + gpt_writel(val, TIMER_CFG, timeridx);
>> +
>> + gpt_writel(RELOAD_VALUE, TIMER_RELOAD_VALUE, timeridx);
>> +
>> + val = gpt_readl(TIMER_CFG, timeridx);
>> + val |= TIMER_ME_LOCAL;
>> + gpt_writel(val, TIMER_CFG, timeridx);
>> +}
>> +
>> +static void pistachio_clksrc_disable(int timeridx)
>> +{
>> + u32 val;
>> +
>> + /* Disable GPT local */
>> + val = gpt_readl(TIMER_CFG, timeridx);
>> + val &= ~TIMER_ME_LOCAL;
>> + gpt_writel(val, TIMER_CFG, timeridx);
>> +}
>> +
>> +static int clocksource_enable(struct clocksource *cs)
>> +{
>&
Re: [PATCH 7/7] mips: pistachio: Allow to enable the external timer based clocksource
On 05/22/2015 01:58 PM, James Hartley wrote: > > >> -Original Message- >> From: abres...@google.com [mailto:abres...@google.com] On Behalf Of >> Andrew Bresticker >> Sent: 22 May 2015 17:50 >> To: Ezequiel Garcia >> Cc: linux-ker...@vger.kernel.org; Linux-MIPS; Daniel Lezcano; >> devicetree@vger.kernel.org; James Hartley; James Hogan; Thomas Gleixner; >> Damien Horsley; Govindraj Raja >> Subject: Re: [PATCH 7/7] mips: pistachio: Allow to enable the external timer >> based clocksource >> >> On Thu, May 21, 2015 at 2:43 PM, Ezequiel Garcia >> wrote: >>> This commit introduces a new config, so the user can choose to enable >>> the General Purpose Timer based clocksource. This option is required >>> to have CPUFreq support. >>> >>> Signed-off-by: Ezequiel Garcia >>> --- >>> arch/mips/Kconfig | 1 + >>> arch/mips/pistachio/Kconfig | 13 + >>> 2 files changed, 14 insertions(+) >>> create mode 100644 arch/mips/pistachio/Kconfig >>> >>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index >>> f501665..91f6ca0 100644 >>> --- a/arch/mips/Kconfig >>> +++ b/arch/mips/Kconfig >>> @@ -934,6 +934,7 @@ source "arch/mips/jazz/Kconfig" >>> source "arch/mips/jz4740/Kconfig" >>> source "arch/mips/lantiq/Kconfig" >>> source "arch/mips/lasat/Kconfig" >>> +source "arch/mips/pistachio/Kconfig" >>> source "arch/mips/pmcs-msp71xx/Kconfig" >>> source "arch/mips/ralink/Kconfig" >>> source "arch/mips/sgi-ip27/Kconfig" >>> diff --git a/arch/mips/pistachio/Kconfig b/arch/mips/pistachio/Kconfig >>> new file mode 100644 index 000..97731ea >>> --- /dev/null >>> +++ b/arch/mips/pistachio/Kconfig >>> @@ -0,0 +1,13 @@ >>> +config PISTACHIO_GPTIMER_CLKSRC >>> + bool "Enable General Purpose Timer based clocksource" >>> + depends on MACH_PISTACHIO >>> + select CLKSRC_PISTACHIO >>> + select MIPS_EXTERNAL_TIMER >> >> Why not just select these in the MACH_PISTACHIO Kconfig entry? Is there any >> harm in always having the Pistachio GPT enabled? > > It does mean that there are less GPT's available for other users, and whilst > I'm not aware of any use cases that currently require all 4, perhaps having > the flexibility is worth it. > And also, this is only useful if the user wants CPUFreq. Otherwise we have MIPS GIC and R4K for clockevents and clocksource. Not sure why we'd want another one. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] clocksource: mips-gic: Update clockevent frequency on clock rate changes
On 05/21/2015 07:32 PM, Andrew Bresticker wrote:
> On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
> wrote:
>> This commit introduces the clockevent frequency update, using
>> a clock notifier. It will be used to support CPUFreq on platforms
>> using MIPS GIC based clockevents.
>>
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/clocksource/mips-gic-timer.c | 31 ++-
>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/mips-gic-timer.c
>> b/drivers/clocksource/mips-gic-timer.c
>> index 22a4daf..71bbd42 100644
>> --- a/drivers/clocksource/mips-gic-timer.c
>> +++ b/drivers/clocksource/mips-gic-timer.c
>> @@ -79,6 +79,13 @@ static void gic_clockevent_cpu_exit(struct
>> clock_event_device *cd)
>> disable_percpu_irq(gic_timer_irq);
>> }
>>
>> +static void gic_update_frequency(void *data)
>> +{
>> + unsigned long rate = (unsigned long)data;
>> +
>> + clockevents_update_freq(this_cpu_ptr(&gic_clockevent_device), rate);
>> +}
>> +
>> static int gic_cpu_notifier(struct notifier_block *nb, unsigned long action,
>> void *data)
>> {
>> @@ -94,10 +101,26 @@ static int gic_cpu_notifier(struct notifier_block *nb,
>> unsigned long action,
>> return NOTIFY_OK;
>> }
>>
>> +static int gic_clk_notifier(struct notifier_block *nb, unsigned long action,
>> + void *data)
>> +{
>> + struct clk_notifier_data *cnd = data;
>> +
>> + if (action == POST_RATE_CHANGE)
>> + on_each_cpu(gic_update_frequency, (void *)cnd->new_rate, 1);
>> +
>> + return NOTIFY_OK;
>> +}
>> +
>> +
>> static struct notifier_block gic_cpu_nb = {
>> .notifier_call = gic_cpu_notifier,
>> };
>>
>> +static struct notifier_block gic_clk_nb = {
>> + .notifier_call = gic_clk_notifier,
>> +};
>> +
>> static int gic_clockevent_init(void)
>> {
>> int ret;
>> @@ -160,6 +183,7 @@ void __init gic_clocksource_init(unsigned int frequency)
>> static void __init gic_clocksource_of_init(struct device_node *node)
>> {
>> struct clk *clk;
>> + int ret;
>>
>> if (WARN_ON(!gic_present || !node->parent ||
>> !of_device_is_compatible(node->parent, "mti,gic")))
>> @@ -186,7 +210,12 @@ static void __init gic_clocksource_of_init(struct
>> device_node *node)
>> }
>>
>> __gic_clocksource_init();
>> - gic_clockevent_init();
>> +
>> + ret = gic_clockevent_init();
>> + if (ret < 0 && !IS_ERR(clk)) {
>
> I think you mean ret == 0 here?
>
>> + if (clk_notifier_register(clk, &gic_clk_nb) < 0)
>> + pr_warn("GIC: Unable to register clock notifier\n");
>> + }
Ouch, certainly.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization
On 05/21/2015 07:24 PM, Andrew Bresticker wrote:
> On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
> wrote:
>> This is preparation work for the introduction of clockevent frequency
>> update with a clock notifier. This is only possible when the device
>> is passed a clk struct, so let's split the legacy and devicetree
>> initialization.
>>
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/clocksource/mips-gic-timer.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clocksource/mips-gic-timer.c
>> b/drivers/clocksource/mips-gic-timer.c
>> index c4352f0..22a4daf 100644
>> --- a/drivers/clocksource/mips-gic-timer.c
>> +++ b/drivers/clocksource/mips-gic-timer.c
>> @@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
>> ret = clocksource_register_hz(&gic_clocksource, gic_frequency);
>> if (ret < 0)
>> pr_warn("GIC: Unable to register clocksource\n");
>> -
>> - gic_clockevent_init();
>> -
>> - /* And finally start the counter */
>> - gic_start_count();
>> }
>
> Instead of duplicating this bit in both the OF and non-OF paths, maybe
> it would be better to do the notifier registration in
> gic_clockevent_init(), either by passing around the struct clk or
> making it a global?
>
Yeah, I had something like that first, but somehow it looked ugly to have:
gic_clockevent_init(IS_ERR(clk) ? NULL : clk);
Don't have a strong opinion though.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] clocksource: Add Pistachio clocksource-only driver
On 05/21/2015 07:00 PM, Thomas Gleixner wrote:
> On Thu, 21 May 2015, Ezequiel Garcia wrote:
>> +static cycle_t clocksource_read_cycles(struct clocksource *cs)
>> +{
>> +u32 counter, overflw;
>> +unsigned long flags;
>> +
>> +raw_spin_lock_irqsave(&lock, flags);
>
> Hmm. Is that lock really necessary to read that counter? The
> clocksource is global. And if its actually used for timekeeping, the
> lock can get heavy contended.
>
Yup, it is really (and sadly) necessary. The kernel hangs up completely
without it when the counter is accesed by more than one CPU.
Apparently, those two timer registers overflow and counter must be read
atomically.
>> +overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
>> +counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
>> +raw_spin_unlock_irqrestore(&lock, flags);
>> +
>> +return ~(cycle_t)counter;
>> +}
>
> Thanks,
>
> tglx
>
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] mips: pistachio: Allow to enable the external timer based clocksource
This commit introduces a new config, so the user can choose to enable the General Purpose Timer based clocksource. This option is required to have CPUFreq support. Signed-off-by: Ezequiel Garcia --- arch/mips/Kconfig | 1 + arch/mips/pistachio/Kconfig | 13 + 2 files changed, 14 insertions(+) create mode 100644 arch/mips/pistachio/Kconfig diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f501665..91f6ca0 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -934,6 +934,7 @@ source "arch/mips/jazz/Kconfig" source "arch/mips/jz4740/Kconfig" source "arch/mips/lantiq/Kconfig" source "arch/mips/lasat/Kconfig" +source "arch/mips/pistachio/Kconfig" source "arch/mips/pmcs-msp71xx/Kconfig" source "arch/mips/ralink/Kconfig" source "arch/mips/sgi-ip27/Kconfig" diff --git a/arch/mips/pistachio/Kconfig b/arch/mips/pistachio/Kconfig new file mode 100644 index 000..97731ea --- /dev/null +++ b/arch/mips/pistachio/Kconfig @@ -0,0 +1,13 @@ +config PISTACHIO_GPTIMER_CLKSRC + bool "Enable General Purpose Timer based clocksource" + depends on MACH_PISTACHIO + select CLKSRC_PISTACHIO + select MIPS_EXTERNAL_TIMER + help + This option enables a clocksource driver based on a Pistachio + SoC General Purpose external timer. + + If you want to enable the CPUFreq, you need to enable + this option. + + If you don't want to enable CPUFreq, you can leave this disabled. -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] clocksource: Add Pistachio SoC general purpose timer binding document
Add a device-tree binding document for the clocksource driver provided
by Pistachio SoC general purpose timers.
Signed-off-by: Ezequiel Garcia
---
.../bindings/timer/img,pistachio-gptimer.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
diff --git a/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
new file mode 100644
index 000..f1b7c08
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt
@@ -0,0 +1,29 @@
+* Pistachio general-purpose timer based clocksource
+
+Required properties:
+ - compatible: "img,pistachio-gptimer".
+ - reg: Address range of the timer registers.
+ - interrupts: An interrupt for each of the four timers
+ - clocks : Should contain a clock specifier for each entry in clock-names
+ - clock-names : Should contain the following entries:
+"sys", interface clock
+"slow", slow counter clock
+"fast", fast counter clock
+ - img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node.
+
+Example:
+ timer: timer@18102000 {
+ compatible = "img,pistachio-gptimer";
+ reg = <0x18102000 0x100>;
+ interrupts = ,
+,
+,
+;
+ clocks = <&clk_periph PERIPH_CLK_COUNTER_FAST>,
+<&clk_periph PERIPH_CLK_COUNTER_SLOW>,
+<&cr_periph SYS_CLK_TIMER>;
+ clock-names = "fast", "slow", "sys";
+ img,cr-periph = <&cr_periph>;
+ };
+
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] clocksource: Add Pistachio clocksource-only driver
The Pistachio SoC provides four general purpose timers, and allow
to implement a clocksource driver.
This driver can be used as a replacement for the MIPS GIC and MIPS R4K
clocksources and sched clocks, which are clocked from the CPU clock.
Given the general purpose timers are clocked from an independent clock,
this new clocksource driver will be useful to introduce CPUFreq support
for Pistachio machines.
Signed-off-by: Govindraj Raja
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/Kconfig | 4 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/time-pistachio.c | 202 +++
3 files changed, 207 insertions(+)
create mode 100644 drivers/clocksource/time-pistachio.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 51d7865f..faa16ae 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -106,6 +106,10 @@ config CLKSRC_EFM32
Support to use the timers of EFM32 SoCs as clock source and clock
event device.
+config CLKSRC_PISTACHIO
+ bool
+ select CLKSRC_OF
+
config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5b85f6a..9415def 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_FSL_FTM_TIMER) += fsl_ftm_timer.o
obj-$(CONFIG_VF_PIT_TIMER) += vf_pit_timer.o
obj-$(CONFIG_CLKSRC_QCOM) += qcom-timer.o
obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
+obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/time-pistachio.c
b/drivers/clocksource/time-pistachio.c
new file mode 100644
index 000..952d8e6
--- /dev/null
+++ b/drivers/clocksource/time-pistachio.c
@@ -0,0 +1,202 @@
+/*
+ * Pistachio clocksource based on general-purpose timers
+ *
+ * Copyright (C) 2015 Imagination Technologies
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Top level reg */
+#defineCR_TIMER_CTRL_CFG 0x00
+ #define TIMER_ME_GLOBAL BIT(0)
+#defineCR_TIMER_REV0x10
+
+/* Timer specific registers */
+#define TIMER_CFG 0x20
+ #define TIMER_ME_LOCAL BIT(0)
+#define TIMER_RELOAD_VALUE 0x24
+#define TIMER_CURRENT_VALUE0x28
+#define TIMER_CURRENT_OVERFLOW_VALUE 0x2C
+#define TIMER_IRQ_STATUS 0x30
+#define TIMER_IRQ_CLEAR0x34
+#define TIMER_IRQ_MASK 0x38
+
+#define PERIP_TIMER_CONTROL0x90
+
+/* Timer specific configuration Values */
+#define RELOAD_VALUE 0x
+
+static void __iomem *timer_base;
+static DEFINE_RAW_SPINLOCK(lock);
+
+static inline u32 gpt_readl(u32 offset, u32 gpt_id)
+{
+ return __raw_readl(timer_base + 0x20 * gpt_id + offset);
+}
+
+static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
+{
+ __raw_writel(value, timer_base + 0x20 * gpt_id + offset);
+}
+
+static cycle_t clocksource_read_cycles(struct clocksource *cs)
+{
+ u32 counter, overflw;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&lock, flags);
+ overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
+ counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
+ raw_spin_unlock_irqrestore(&lock, flags);
+
+ return ~(cycle_t)counter;
+}
+
+static u64 notrace pistachio_read_sched_clock(void)
+{
+ return clocksource_read_cycles(NULL);
+}
+
+static void pistachio_clksrc_enable(int timeridx)
+{
+ u32 val;
+
+ /* Disable GPT local before loading reload value */
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val &= ~TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+
+ gpt_writel(RELOAD_VALUE, TIMER_RELOAD_VALUE, timeridx);
+
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val |= TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+}
+
+static void pistachio_clksrc_disable(int timeridx)
+{
+ u32 val;
+
+ /* Disable GPT local */
+ val = gpt_readl(TIMER_CFG, timeridx);
+ val &= ~TIMER_ME_LOCAL;
+ gpt_writel(val, TIMER_CFG, timeridx);
+}
+
+static int clocksource_enable(struct clocksource *cs)
+{
+ pistachio_clksrc_enable(0);
+ return 0;
+}
+
+static void clocksource_disable(struct clocksource *cs)
+{
+ pistachio_clksrc_disable(0);
+}
+
+/* Desirable clock source for pistachio pl
[PATCH 2/7] clocksource: mips-gic: Add missing error returns checks
This commit adds the required checks on the functions that return
an error. Some of them are not critical, so only a warning is
printed.
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index 913585d..c4352f0 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -100,12 +100,18 @@ static struct notifier_block gic_cpu_nb = {
static int gic_clockevent_init(void)
{
+ int ret;
+
if (!cpu_has_counter || !gic_frequency)
return -ENXIO;
- setup_percpu_irq(gic_timer_irq, &gic_compare_irqaction);
+ ret = setup_percpu_irq(gic_timer_irq, &gic_compare_irqaction);
+ if (ret < 0)
+ return ret;
- register_cpu_notifier(&gic_cpu_nb);
+ ret = register_cpu_notifier(&gic_cpu_nb);
+ if (ret < 0)
+ pr_warn("GIC: Unable to register CPU notifier\n");
gic_clockevent_cpu_init(this_cpu_ptr(&gic_clockevent_device));
@@ -125,13 +131,17 @@ static struct clocksource gic_clocksource = {
static void __init __gic_clocksource_init(void)
{
+ int ret;
+
/* Set clocksource mask. */
gic_clocksource.mask = CLOCKSOURCE_MASK(gic_get_count_width());
/* Calculate a somewhat reasonable rating value. */
gic_clocksource.rating = 200 + gic_frequency / 1000;
- clocksource_register_hz(&gic_clocksource, gic_frequency);
+ ret = clocksource_register_hz(&gic_clocksource, gic_frequency);
+ if (ret < 0)
+ pr_warn("GIC: Unable to register clocksource\n");
gic_clockevent_init();
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] clocksource: mips-gic: Update clockevent frequency on clock rate changes
This commit introduces the clockevent frequency update, using
a clock notifier. It will be used to support CPUFreq on platforms
using MIPS GIC based clockevents.
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index 22a4daf..71bbd42 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -79,6 +79,13 @@ static void gic_clockevent_cpu_exit(struct
clock_event_device *cd)
disable_percpu_irq(gic_timer_irq);
}
+static void gic_update_frequency(void *data)
+{
+ unsigned long rate = (unsigned long)data;
+
+ clockevents_update_freq(this_cpu_ptr(&gic_clockevent_device), rate);
+}
+
static int gic_cpu_notifier(struct notifier_block *nb, unsigned long action,
void *data)
{
@@ -94,10 +101,26 @@ static int gic_cpu_notifier(struct notifier_block *nb,
unsigned long action,
return NOTIFY_OK;
}
+static int gic_clk_notifier(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct clk_notifier_data *cnd = data;
+
+ if (action == POST_RATE_CHANGE)
+ on_each_cpu(gic_update_frequency, (void *)cnd->new_rate, 1);
+
+ return NOTIFY_OK;
+}
+
+
static struct notifier_block gic_cpu_nb = {
.notifier_call = gic_cpu_notifier,
};
+static struct notifier_block gic_clk_nb = {
+ .notifier_call = gic_clk_notifier,
+};
+
static int gic_clockevent_init(void)
{
int ret;
@@ -160,6 +183,7 @@ void __init gic_clocksource_init(unsigned int frequency)
static void __init gic_clocksource_of_init(struct device_node *node)
{
struct clk *clk;
+ int ret;
if (WARN_ON(!gic_present || !node->parent ||
!of_device_is_compatible(node->parent, "mti,gic")))
@@ -186,7 +210,12 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
}
__gic_clocksource_init();
- gic_clockevent_init();
+
+ ret = gic_clockevent_init();
+ if (ret < 0 && !IS_ERR(clk)) {
+ if (clk_notifier_register(clk, &gic_clk_nb) < 0)
+ pr_warn("GIC: Unable to register clock notifier\n");
+ }
/* And finally start the counter */
gic_start_count();
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] clocksource: mips-gic: Enable the clock before using it
For the clock to be used (e.g. get its rate through clk_get_rate)
it should be prepared and enabled first.
Also, while the clock is enabled the driver must hold a reference to it,
so let's remove the call to clk_put.
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index b81ed1a..913585d 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -158,8 +158,13 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
clk = of_clk_get(node, 0);
if (!IS_ERR(clk)) {
+ if (clk_prepare_enable(clk) < 0) {
+ pr_err("GIC failed to enable clock\n");
+ clk_put(clk);
+ return;
+ }
+
gic_frequency = clk_get_rate(clk);
- clk_put(clk);
} else if (of_property_read_u32(node, "clock-frequency",
&gic_frequency)) {
pr_err("GIC frequency not specified.\n");
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization
This is preparation work for the introduction of clockevent frequency
update with a clock notifier. This is only possible when the device
is passed a clk struct, so let's split the legacy and devicetree
initialization.
Signed-off-by: Ezequiel Garcia
---
drivers/clocksource/mips-gic-timer.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index c4352f0..22a4daf 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
ret = clocksource_register_hz(&gic_clocksource, gic_frequency);
if (ret < 0)
pr_warn("GIC: Unable to register clocksource\n");
-
- gic_clockevent_init();
-
- /* And finally start the counter */
- gic_start_count();
}
void __init gic_clocksource_init(unsigned int frequency)
@@ -156,6 +151,10 @@ void __init gic_clocksource_init(unsigned int frequency)
GIC_LOCAL_TO_HWIRQ(GIC_LOCAL_INT_COMPARE);
__gic_clocksource_init();
+ gic_clockevent_init();
+
+ /* And finally start the counter */
+ gic_start_count();
}
static void __init gic_clocksource_of_init(struct device_node *node)
@@ -187,6 +186,10 @@ static void __init gic_clocksource_of_init(struct
device_node *node)
}
__gic_clocksource_init();
+ gic_clockevent_init();
+
+ /* And finally start the counter */
+ gic_start_count();
}
CLOCKSOURCE_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
gic_clocksource_of_init);
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Clocksource changes for Pistachio CPUFreq
The purpose of this patchset is to support CPUFreq on Pistachio SoC. However, given Pistachio uses the MIPS GIC clocksource and clockevent drivers (clocked from the CPU), adding CPUFreq support needs some work. This patchset changes the MIPS GIC clockevent driver to update the frequency of the per-cpu clockevents using a clock notifier. Then, we add a clocksource driver for IMG Pistachio SoC, based on the general purpose timers. The SoC only provides four timers, so we can't use them to implement the four clockevents and the clocksource. However, we can use one of these timers to provide a clocksource and a sched clock. Given the general purpose timers are clocked from the peripheral system clock tree, they are not affected by CPU rate changes. Patches 1 to 3 are just style cleaning and preparation work. Patch 4 adds the clockevent frequency update. Patches 5 and 6 add the new clocksource driver. Patch 7 introduces an option to enable the timer based clocksource on Pistachio. For CPUFreq to really work, clk driver changes are needed to support MIPS PLL clock rate change. Patches for this will be posted soon. This series apply on v4.1-rc4. As always, comments and feedback are welcome! Ezequiel Garcia (7): clocksource: mips-gic: Enable the clock before using it clocksource: mips-gic: Add missing error returns checks clocksource: mips-gic: Split clocksource and clockevent initialization clocksource: mips-gic: Update clockevent frequency on clock rate changes clocksource: Add Pistachio SoC general purpose timer binding document clocksource: Add Pistachio clocksource-only driver mips: pistachio: Allow to enable the external timer based clocksource .../bindings/timer/img,pistachio-gptimer.txt | 29 +++ arch/mips/Kconfig | 1 + arch/mips/pistachio/Kconfig| 13 ++ drivers/clocksource/Kconfig| 4 + drivers/clocksource/Makefile | 1 + drivers/clocksource/mips-gic-timer.c | 65 ++- drivers/clocksource/time-pistachio.c | 202 + 7 files changed, 306 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/timer/img,pistachio-gptimer.txt create mode 100644 arch/mips/pistachio/Kconfig create mode 100644 drivers/clocksource/time-pistachio.c -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] pinctrl: Add Pistachio SoC pin control driver
Andrew,
On 04/07/2015 04:44 PM, Andrew Bresticker wrote:
[..]
> +static int pistachio_pinmux_enable(struct pinctrl_dev *pctldev,
> +unsigned func, unsigned group)
> +{
> + struct pistachio_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
> + const struct pistachio_pin_group *pg = &pctl->groups[group];
> + const struct pistachio_function *pf = &pctl->functions[func];
> + struct pinctrl_gpio_range *range;
> + unsigned int i;
> + u32 val;
> +
> + if (pg->mux_reg > 0) {
> + for (i = 0; i < ARRAY_SIZE(pg->mux_option); i++) {
> + if (pg->mux_option[i] == func)
> + break;
> + }
> + if (i == ARRAY_SIZE(pg->mux_option)) {
> + dev_err(pctl->dev, "Cannot mux pin %u to function %u\n",
> + group, func);
> + return -EINVAL;
> + }
> +
> + val = pctl_readl(pctl, pg->mux_reg);
> + val &= ~(pg->mux_mask << pg->mux_shift);
> + val |= i << pg->mux_shift;
> + pctl_writel(pctl, val, pg->mux_reg);
> +
> + if (pf->scenarios) {
> + for (i = 0; i < pf->nscenarios; i++) {
> + if (pf->scenarios[i] == group)
> + break;
> + }
> + if (WARN_ON(i == pf->nscenarios))
> + return -EINVAL;
> +
> + val = pctl_readl(pctl, pf->scenario_reg);
> + val &= ~(pf->scenario_mask << pf->scenario_shift);
> + val |= i << pf->scenario_shift;
> + pctl_writel(pctl, val, pf->scenario_reg);
> + }
> + }
> +
> + range = pinctrl_find_gpio_range_from_pin(pctl->pctldev, group);
> + if (range)
> + gpio_disable(gc_to_bank(range->gc), group - range->pin_base);
> +
If you plan to submit a v4, how about using "pg->pins" here instead of "group"?
Using "group" relies on having the same numberspace for the group and the pin,
and it'll break when introducing the RPU pinctrl.
Thanks!
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] pinctrl: Add Pistachio SoC pin control driver
Just a silly comment.
On 04/07/2015 04:44 PM, Andrew Bresticker wrote:
[..]
> +
> +static const struct pinmux_ops pistachio_pinmux_ops = {
> + .get_functions_count = pistachio_pinmux_get_functions_count,
> + .get_function_name = pistachio_pinmux_get_function_name,
> + .get_function_groups = pistachio_pinmux_get_function_groups,
> + .set_mux = pistachio_pinmux_enable,
> +};
> +
> +static int pistachio_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
> + unsigned long *config)
> +{
> + struct pistachio_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
> + enum pin_config_param param = pinconf_to_config_param(*config);
> + u32 val, arg;
> +
> + switch (param) {
> + case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> + val = pctl_readl(pctl, PADS_SCHMITT_EN_REG(pin));
> + arg = !!(val & PADS_SCHMITT_EN_BIT(pin));
> + break;
> + case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
> + val = pctl_readl(pctl, PADS_PU_PD_REG(pin)) >>
> + PADS_PU_PD_SHIFT(pin);
> + arg = (val & PADS_PU_PD_MASK) == PADS_PU_PD_HIGHZ;
> + break;
> + case PIN_CONFIG_BIAS_PULL_UP:
> + val = pctl_readl(pctl, PADS_PU_PD_REG(pin)) >>
> + PADS_PU_PD_SHIFT(pin);
> + arg = (val & PADS_PU_PD_MASK) == PADS_PU_PD_UP;
> + break;
> + case PIN_CONFIG_BIAS_PULL_DOWN:
> + val = pctl_readl(pctl, PADS_PU_PD_REG(pin)) >>
> + PADS_PU_PD_SHIFT(pin);
> + arg = (val & PADS_PU_PD_MASK) == PADS_PU_PD_DOWN;
> + break;
> + case PIN_CONFIG_BIAS_BUS_HOLD:
> + val = pctl_readl(pctl, PADS_PU_PD_REG(pin)) >>
> + PADS_PU_PD_SHIFT(pin);
> + arg = (val & PADS_PU_PD_MASK) == PADS_PU_PD_BUS;
> + break;
> + case PIN_CONFIG_SLEW_RATE:
> + val = pctl_readl(pctl, PADS_SLEW_RATE_REG(pin));
> + arg = !!(val & PADS_SLEW_RATE_BIT(pin));
> + break;
> + case PIN_CONFIG_DRIVE_STRENGTH:
> + val = pctl_readl(pctl, PADS_DRIVE_STRENGTH_REG(pin)) >>
> + PADS_DRIVE_STRENGTH_SHIFT(pin);
> + switch (val & PADS_DRIVE_STRENGTH_MASK) {
> + case PADS_DRIVE_STRENGTH_2MA:
> + arg = 2;
> + break;
> + case PADS_DRIVE_STRENGTH_4MA:
> + arg = 4;
> + break;
> + case PADS_DRIVE_STRENGTH_8MA:
> + arg = 8;
> + break;
> + case PADS_DRIVE_STRENGTH_12MA:
> + default:
> + arg = 12;
> + break;
> + }
> + break;
> + default:
> + dev_err(pctl->dev, "Property %u not supported\n", param);
Probably just a nitpick, but maybe this should be dev_dbg. Otherwise,
we'll get a ton of these errors when cat'ing pinconf-pins in debugfs.
> + return -EINVAL;
And this should be -ENOTSUPP. I guess it doesn't matter much.
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/12] MIPS: ath79: Add OF support and DTS for TL-WR1043ND
On 04/24/2015 08:41 AM, Alban Bedel wrote: > This series add OF bindings and code support for the interrupt > controllers, clocks and GPIOs. However it was only tested on a > TL-WR1043ND with an AR9132, others SoCs are untested, and a few are > not supported at all. > > Most code changes base on the previous bug fix series: > [PATCH v2 0/5] MIPS: ath79: Various small fix to prepare OF support > > The requested patch to move the GPIO driver to drivers/gpio is ready and > will follow once it is clearer if this serie get merged. > > ChangeLog: > v2: * Fixed the OF bindings and DTS to use ePAPR standardized names > * Fixed the typos in the OF bindings > * Added an ngpios property to the GPIO binding and driver > * Removed all the soc_is_xxx() calls out of the GPIO driver probe() > * Updated the DTS patches to the new directory structure and merged both > in one. Having 3 patches to add Makefile, SoC dtsi and board DTS seemed > a bit overkill. > * Moved the patch to use the common clk API to the bug fix serie to keep > this one cleaner. > > v3: * Moved the builtin DTB menu to the patch adding the TL-WR1043ND DTS > * Made the builtin DTB menu optional > * Fixed more typos > * Really fixed the DDR controller binding example to use ePAPR names > * Fixed the qca9550 compatible string in the PLL bindings and driver > * Fixed the example in the GPIO controller binding > * Moved the new vendor entry to the correct place > > Alban Bedel (12): > devicetree: Add bindings for the SoC of the ATH79 family > MIPS: ath79: Add basic device tree support > devicetree: Add bindings for the ATH79 DDR controllers > devicetree: Add bindings for the ATH79 interrupt controllers > devicetree: Add bindings for the ATH79 MISC interrupt controllers > MIPS: ath79: Add OF support to the IRQ controllers > devicetree: Add bindings for the ATH79 PLL controllers > MIPS: ath79: Add OF support to the clocks > devicetree: Add bindings for the ATH79 GPIO controllers > MIPS: ath79: Add OF support to the GPIO driver > of: Add vendor prefix for TP-Link Technologies Co. Ltd > MIPS: Add basic support for the TL-WR1043ND version 1 > Hi Alban, I've booted a Carambola2 using this (plus a custom devicetree and some small changes): Tested-by: Ezequiel Garcia Just a small comment/question: Shouldn't we allow to build all the devicetree files, instead of just the one that will be built-in? I.e., something like this: dtb-$(CONFIG_MATCH_ATH79_DT) += ar9132_tl_wr1043nd_v1.dtb dtb-$(CONFIG_MACH_ATH79_DT)+= ar9331_carambola2.dtb It should be useful to catch errors, but also in general, as the devicetree is supposed to be independent of the kernel and should be built separate from it. PS: This series depends on a previous patchset. It's usually useful to mention this in the cover letter and make a poor tester's life easier :) Thanks for the work, -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] pinctrl: Add Pistachio SoC pin control driver
Hi Andrew,
On 04/07/2015 04:44 PM, Andrew Bresticker wrote:
[..]
> +static int pistachio_gpio_register(struct pistachio_pinctrl *pctl)
> +{
> + struct device_node *node = pctl->dev->of_node;
> + struct pistachio_gpio_bank *bank;
> + unsigned int i;
> + int irq, ret = 0;
> +
> + for (i = 0; i < pctl->nbanks; i++) {
> + char child_name[sizeof("gpioXX")];
> + struct device_node *child;
The first submission used for_each_child_of_node, and I can't find
any review comments explaining why you've changed it to a regular for
loop.
> +
> + snprintf(child_name, sizeof(child_name), "gpio%d", i);
This assumes the GPIO bank nodes are called gpio0, gpio1, ... and so on.
Do we really want to assume that?
Thanks,
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: armada: read stable temp on Armada XP
On 02/25/2015 02:04 PM, Gregory CLEMENT wrote: >> >> My conclusions about these registers are based on experimental data. The >> documentation is very sparse, but the Thermal Manager Control and Status >> Register looks like the preferred register given the way it is laid out in >> the >> public spec. > > Ezequiel, > > as you worked on this do you know why we used the Thermal Sensor Status > Register > instead of the Thermal Manager Control and Status Register ? > My first guess is that the giving the name of the registers the 1st one made > more sens to use for a thermal sensor. > Actually, we based this driver in the vendor bootloader. The specs weren't of much use back then. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Thierry, On 01/30/2015 06:18 AM, Thierry Reding wrote: > On Thu, Jan 29, 2015 at 01:32:09PM -0300, Ezequiel Garcia wrote: >> On 01/20/2015 07:52 AM, Ezequiel Garcia wrote: >>> >>> >>> On 01/09/2015 02:54 PM, Ezequiel Garcia wrote: >>>> A new round for the IMG PWM driver. >>>> >>>> The IMG PWM controller is muxed with a PDM controller, >>>> through a shared so-called periph register bit, which sets >>>> the output as PWM or PDM. Because this register is not part >>>> of the pin controller block, but rather PWM/PDM specific, and >>>> because the register is also used to set the PDM value, it is >>>> simpler to use a regmap-based syscon to deal with it. >>>> >>>> This time, I'm removing the PDM driver from the submission >>>> and submitting the PWM alone. The PDM was written as a misc >>>> driver, but had some design issues, so for now I'm proposing >>>> to merge the PWM only. >>>> >>>> The series is based on v3.19-rc3. If at all possible I'd like >>>> to see this merged for v3.20. >>>> >>> >>> Thierry, >>> >>> Any comments on this? Any chance we merge it in time for >>> v3.20? It's -rc5 already and I've started to worry. >>> >> >> Thierry, >> >> I'm very sorry to be so bothering, but I got no news from you and >> it's -rc6 already. I'd say I'll resend this series to Andrew >> Morton, hoping we can merge this for v3.20. >> >> Please let me know if you'll be able to pick this. > > I can pick it up if you make up your mind about the license. The > header comment says GPL v2 or later, but MODULE_LICENSE has "GPL > v2", which does not include the "or later" part. > License should be GPL v2, sorry about that. Need me to fix it and resend or can you amend it before pushing this? > Also you're making it especially difficult to build-test by not > providing even the basic bits of your SoC support first. All even > linux-next seems to have for the Pistachio SoC is the addition of > a compatible string to the dw-mmc driver. > Well, we've added COMPILE_TEST for precisely this reason, so you only need to select COMPILE_TEST on any arch and you'll be able to build test the driver. > I'll take the PWM driver, but I'll assume that you'll eventually > have more pieces available, in which case I'd appreciate a note so > I can update my build scripts. > If you can pick it, it would be great. I understand it's hard to accept patches for drivers, when there's little testing possibilities. But on the other side, isn't it a positive thing that a vendor is pushing drivers this early? Thanks a lot, - -- Ezequiel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJUy2RhAAoJEIOKbhOEIHKiWB0QAKc4h+YLjxLLa7y0/NfoEiqV gwipBbrfO4leAB6RUiDOGil53Ir0Pxg87IbCHV5A0Gzxahv47GG41DYPVzbU3lHm DGkGqyXDf0BNQqJkCXmDWV9/8pnjFfUMDlSrs15pxXTaRjZ7m6CrxCoZof5UVt91 4cmeDYHg4lr+YzT3oXuyiKFlrIRrT5heD3gfyL5IB9qQypR2KPnpDrCwMcmT6+ag zI6sg6OAi8de7ZvSWEZSK7WkymhgduR9Rt0WRQBC3EKF2dCsUxhmZt14RJsDcpEK LWn5z1FxImtJq8vWOq/E2F9AWtQ/o9gUeII2myNDaL2SIrVoggUP+yKV51J8bidl G2HXU8NEIHCaqcKl5sdbeEbB4diXVqGJu+d9SOM2lrW2PlwWN63jgnGfyYc2RadH 60adajBgNjs9Ujfo5nFy+aYXJtJZk+4b1M0UMI+2qKV4G9PBfDrrpUMBRCRt8il4 A15lUoHTwTeLQp8m7YmNuoKLhLmeVrBgbzBagFLUZgpJs7TEYIWefrh/jos37n2s aNlVW55c5CXDMDX9Bef4ar6Ch95TOxPqiED70e2/lNM0ckRzd7viQandUxquvc9q mSWhSxYuT62/B6innSbuWLdifKtCsqX+QQIo2NBC3AB+NVybEmC89gB8jx+Py7pX YS0wpCGXivYm3AIWhhyT =qi1N -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
On 01/29/2015 03:12 PM, Jonathan Cameron wrote: > On 29/01/15 16:29, Ezequiel Garcia wrote: >> Hi Jonathan, >> >> On 01/20/2015 05:37 PM, Jonathan Cameron wrote: >> [..] >>> >>> Hi, I'm afraid that I'm a little stalled on sending it on because Greg >>> hasn't yet picked up my last pull request. In the mean time I've applied >>> it to the branch that will get rebased once he's taken that and pushed it >>> out as testing. >>> >> >> I can't find your second pull anywhere. Any chance we can get this >> driver in v3.20? > I've not sent it yet. Had a bit of a backlog of review to catch up with. > + in theory should be fine for a pull in the next day or two... Great, thanks! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
On 01/20/2015 07:52 AM, Ezequiel Garcia wrote: > > > On 01/09/2015 02:54 PM, Ezequiel Garcia wrote: >> A new round for the IMG PWM driver. >> >> The IMG PWM controller is muxed with a PDM controller, through a shared >> so-called periph register bit, which sets the output as PWM or PDM. >> Because this register is not part of the pin controller block, but rather >> PWM/PDM specific, and because the register is also used to set the PDM value, >> it is simpler to use a regmap-based syscon to deal with it. >> >> This time, I'm removing the PDM driver from the submission and submitting >> the PWM >> alone. The PDM was written as a misc driver, but had some design issues, so >> for >> now I'm proposing to merge the PWM only. >> >> The series is based on v3.19-rc3. If at all possible I'd like to see this >> merged >> for v3.20. >> > > Thierry, > > Any comments on this? Any chance we merge it in time for v3.20? > It's -rc5 already and I've started to worry. > Thierry, I'm very sorry to be so bothering, but I got no news from you and it's -rc6 already. I'd say I'll resend this series to Andrew Morton, hoping we can merge this for v3.20. Please let me know if you'll be able to pick this. Thanks, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
Hi Jonathan, On 01/20/2015 05:37 PM, Jonathan Cameron wrote: [..] > > Hi, I'm afraid that I'm a little stalled on sending it on because Greg > hasn't yet picked up my last pull request. In the mean time I've applied > it to the branch that will get rebased once he's taken that and pushed it > out as testing. > I can't find your second pull anywhere. Any chance we can get this driver in v3.20? Also, I can't find the driver anywhere in your testing branch here: https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/ Seems like patches 2 and 3 are there, but not patch 1/3 of the series: "iio: adc: Cosmic Circuits 10001 ADC driver". Please let me know if you need anything at all from me! Thanks a lot, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver
On 01/20/2015 10:59 AM, Guenter Roeck wrote: > On 01/20/2015 03:13 AM, Ezequiel Garcia wrote: >> Hi Wim, >> >> On 01/06/2015 10:19 AM, Ezequiel Garcia wrote: >>> Here's the seventh round for IMG PDC Watchdog driver. >>> The series is based on v3.19-rc3. >>> >> >> Guenter has reviewed both patches. Do you think you can review this >> soonishly and let me know if you have more comments? >> > > I'll send a pull request to Wim either this or next week. > Guenter, I hate to be so spammy here. Do you still plan to send a pull request? Next week is -rc7, so I'm wondering if there's any way we can be on time for v3.20. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver
On 01/28/2015 03:57 PM, Guenter Roeck wrote: > On Wed, Jan 28, 2015 at 03:39:22PM -0300, Ezequiel Garcia wrote: >> On 01/20/2015 10:59 AM, Guenter Roeck wrote: >>> On 01/20/2015 03:13 AM, Ezequiel Garcia wrote: >>>> Hi Wim, >>>> >>>> On 01/06/2015 10:19 AM, Ezequiel Garcia wrote: >>>>> Here's the seventh round for IMG PDC Watchdog driver. >>>>> The series is based on v3.19-rc3. >>>>> >>>> >>>> Guenter has reviewed both patches. Do you think you can review this >>>> soonishly and let me know if you have more comments? >>>> >>> >>> I'll send a pull request to Wim either this or next week. >>> >> >> Guenter, >> >> I hate to be so spammy here. Do you still plan to send a pull request? >> > Yes. Sorry for the delay. > OK, no problem, was just checking. Thanks a lot for taking care of this! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
On 01/20/2015 05:37 PM, Jonathan Cameron wrote: > On 20/01/15 10:54, Ezequiel Garcia wrote: >> >> >> On 01/10/2015 11:15 AM, Jonathan Cameron wrote: >>> On 06/01/15 20:47, Ezequiel Garcia wrote: >>>> This series add the support for an ADC IP block from Cosmic Circuits. >>>> The patchset is based on v3.19-rc3. >>>> >>>> As agreed with Rob, this series drops the vendor prefix in the >>>> adc-reserved-channels DT property. This property is generic enough to >>>> be used in other drivers (at91 is a potential candidate). >>>> >>>> A follow-up patch can use the property in at91 and add it to the >>>> IIO generic bindings. >>> I'm happy - will let this sit for a little while to let Harmut say >>> if wants to take another look (or give a reviewed-by or similar). >>> >> >> Hi Jonathan, >> >> As Harmut gave a Reviewed-by, I'm wondering if you can pick this sooner >> than later, so we don't miss next window. >> >> Thanks a lot! >> > Hi, I'm afraid that I'm a little stalled on sending it on because Greg > hasn't yet picked up my last pull request. In the mean time I've applied > it to the branch that will get rebased once he's taken that and pushed it > out as testing. > OK, thanks a lot for the heads up. Cheers, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver
On 01/20/2015 10:59 AM, Guenter Roeck wrote: > On 01/20/2015 03:13 AM, Ezequiel Garcia wrote: >> Hi Wim, >> >> On 01/06/2015 10:19 AM, Ezequiel Garcia wrote: >>> Here's the seventh round for IMG PDC Watchdog driver. >>> The series is based on v3.19-rc3. >>> >> >> Guenter has reviewed both patches. Do you think you can review this >> soonishly and let me know if you have more comments? >> > > I'll send a pull request to Wim either this or next week. > Great. Let me know if you need anything from me. Thanks a lot, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver
Hi Wim, On 01/06/2015 10:19 AM, Ezequiel Garcia wrote: > Here's the seventh round for IMG PDC Watchdog driver. > The series is based on v3.19-rc3. > Guenter has reviewed both patches. Do you think you can review this soonishly and let me know if you have more comments? We are near the merge window and I wouldn't like to miss it this time. Thanks a lot! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding
On 01/11/2015 10:57 PM, Peter Pan 潘栋 (peterpandong) wrote: >> On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote: > This commit adds the devicetree binding document that specifies the > spi nand devices support. > > Signed-off-by: Peter Pan > --- > Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 ++ > 1 file changed, 22 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/spi- nand.txt > > diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt > new file mode 100644 > index 000..9dd3efd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt > @@ -0,0 +1,22 @@ > +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips > + > +Required properties: > +- #address-cells, #size-cells : Must be present if the device has sub-nodes > + representing partitions. > +- compatible : Should be the manufacturer and the name of the chip. Bear in mind > Unless I'm mistaken, we don't need the chip ID here, as SPI NAND >> allows to autodetect the device. Any reason why we can't just use a generic compatible "spi-nand" here? -- Ezequiel >>> >>> In fact, I don't know how to autodetect the SPI NAND device. Micron >> device and >>> Gigadevice device have different read ID functions. The Chip ID here >> is used to >>> determine which function to use. >>> >> >> Isn't the difference between the Read ID very minor? One of the vendor >> needs a 2-byte ID read, and the other one needs a 3-byte ID read. >> >> So you can just try with 2-byte, and if that fails (no vendor ID is >> found on the first byte), you can try with the 3-byte command. >> >> It's not the most elegant solution, but it's not super awful either. >> -- >> Ezequiel > > I agree with your idea about try different ways to read ID. It is a better way > to detect the chip if it can work properly. > > The difference between the Read ID is that some chips need to send a dummy > byte > or address after opcode then read 2 byte, some chips needn't send any data > after > opcode but read 3 byte. > > I'm concerned maybe chip will get into unknown or vendor specified state if we > send the wrong sequence. > Have you seen this happpening? Or this a potential/future problem? For the latter, we can always fix it when the issue appears. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
On 01/10/2015 11:15 AM, Jonathan Cameron wrote: > On 06/01/15 20:47, Ezequiel Garcia wrote: >> This series add the support for an ADC IP block from Cosmic Circuits. >> The patchset is based on v3.19-rc3. >> >> As agreed with Rob, this series drops the vendor prefix in the >> adc-reserved-channels DT property. This property is generic enough to >> be used in other drivers (at91 is a potential candidate). >> >> A follow-up patch can use the property in at91 and add it to the >> IIO generic bindings. > I'm happy - will let this sit for a little while to let Harmut say > if wants to take another look (or give a reviewed-by or similar). > Hi Jonathan, As Harmut gave a Reviewed-by, I'm wondering if you can pick this sooner than later, so we don't miss next window. Thanks a lot! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
On 01/09/2015 02:54 PM, Ezequiel Garcia wrote: > A new round for the IMG PWM driver. > > The IMG PWM controller is muxed with a PDM controller, through a shared > so-called periph register bit, which sets the output as PWM or PDM. > Because this register is not part of the pin controller block, but rather > PWM/PDM specific, and because the register is also used to set the PDM value, > it is simpler to use a regmap-based syscon to deal with it. > > This time, I'm removing the PDM driver from the submission and submitting the > PWM > alone. The PDM was written as a misc driver, but had some design issues, so > for > now I'm proposing to merge the PWM only. > > The series is based on v3.19-rc3. If at all possible I'd like to see this > merged > for v3.20. > Thierry, Any comments on this? Any chance we merge it in time for v3.20? It's -rc5 already and I've started to worry. Thanks! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/2] Imagination Technologies PWM support
A new round for the IMG PWM driver. The IMG PWM controller is muxed with a PDM controller, through a shared so-called periph register bit, which sets the output as PWM or PDM. Because this register is not part of the pin controller block, but rather PWM/PDM specific, and because the register is also used to set the PDM value, it is simpler to use a regmap-based syscon to deal with it. This time, I'm removing the PDM driver from the submission and submitting the PWM alone. The PDM was written as a misc driver, but had some design issues, so for now I'm proposing to merge the PWM only. The series is based on v3.19-rc3. If at all possible I'd like to see this merged for v3.20. Comments welcome! Naidu Tellapati (2): pwm: Imagination Technologies PWM DAC driver DT: pwm: Add binding document for IMG PWM DAC Documentation/devicetree/bindings/pwm/img-pwm.txt | 24 +++ drivers/pwm/Kconfig | 13 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-img.c | 250 ++ 4 files changed, 288 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/img-pwm.txt create mode 100644 drivers/pwm/pwm-img.c -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/2] pwm: Imagination Technologies PWM DAC driver
From: Naidu Tellapati
The Pistachio SOC from Imagination Technologies includes a Pulse Width
Modulation DAC which produces 1 to 4 digital bit-outputs which represent
digital waveforms. These PWM outputs are primarily in charge of controlling
backlight LED devices.
Reviewed-by: Andrew Bresticker
Signed-off-by: Naidu Tellapati
Signed-off-by: Sai Masarapu
Signed-off-by: Ezequiel Garcia
---
drivers/pwm/Kconfig | 13 +++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-img.c | 250 ++
3 files changed, 264 insertions(+)
create mode 100644 drivers/pwm/pwm-img.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a3ecf58..1681cd0 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -130,6 +130,19 @@ config PWM_FSL_FTM
To compile this driver as a module, choose M here: the module
will be called pwm-fsl-ftm.
+config PWM_IMG
+ tristate "Imagination Technologies PWM driver"
+ depends on HAS_IOMEM
+ depends on MFD_SYSCON
+ depends on COMMON_CLK
+ depends on MIPS || COMPILE_TEST
+ help
+ Generic PWM framework driver for Imagination Technologies
+ PWM block which supports 4 channels.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-img
+
config PWM_IMX
tristate "i.MX PWM support"
depends on ARCH_MXC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 65259ac..85381e4 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
+obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
diff --git a/drivers/pwm/pwm-img.c b/drivers/pwm/pwm-img.c
new file mode 100644
index 000..0cf9a74
--- /dev/null
+++ b/drivers/pwm/pwm-img.c
@@ -0,0 +1,250 @@
+/*
+ * Imagination Technologies Pulse Width Modulator driver
+ *
+ * Copyright (c) 2014-2015, Imagination Technologies
+ *
+ * Based on drivers/pwm/pwm-tegra.c, Copyright (c) 2010, NVIDIA Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PWM registers */
+#define PWM_CTRL_CFG 0x
+#define PWM_CTRL_CFG_NO_SUB_DIV0
+#define PWM_CTRL_CFG_SUB_DIV0 1
+#define PWM_CTRL_CFG_SUB_DIV1 2
+#define PWM_CTRL_CFG_SUB_DIV0_DIV1 3
+#define PWM_CTRL_CFG_DIV_SHIFT(ch) ((ch) * 2 + 4)
+#define PWM_CTRL_CFG_DIV_MASK 0x3
+
+#define PWM_CH_CFG(ch) (0x4 + (ch) * 4)
+#define PWM_CH_CFG_TMBASE_SHIFT0
+#define PWM_CH_CFG_DUTY_SHIFT 16
+
+#define PERIP_PWM_PDM_CONTROL 0x0140
+#define PERIP_PWM_PDM_CONTROL_CH_MASK 0x1
+#define PERIP_PWM_PDM_CONTROL_CH_SHIFT(ch) ((ch) * 4)
+
+#define MAX_TMBASE_STEPS 65536
+
+struct img_pwm_chip {
+ struct device *dev;
+ struct pwm_chip chip;
+ struct clk *pwm_clk;
+ struct clk *sys_clk;
+ void __iomem*base;
+ struct regmap *periph_regs;
+};
+
+static inline struct img_pwm_chip *to_img_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct img_pwm_chip, chip);
+}
+
+static inline void img_pwm_writel(struct img_pwm_chip *chip,
+ u32 reg, u32 val)
+{
+ writel(val, chip->base + reg);
+}
+
+static inline u32 img_pwm_readl(struct img_pwm_chip *chip,
+u32 reg)
+{
+ return readl(chip->base + reg);
+}
+
+static int img_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ u32 val, div, duty, timebase;
+ unsigned long mul, output_clk_hz, input_clk_hz;
+ struct img_pwm_chip *pwm_chip = to_img_pwm_chip(chip);
+
+ input_clk_hz = clk_get_rate(pwm_chip->pwm_clk);
+ output_clk_hz = DIV_ROUND_UP(NSEC_PER_SEC, period_ns);
+
+ mul = DIV_ROUND_UP(input_clk_hz, output_clk_hz);
+ if (mul <= MAX_TMBASE_STEPS) {
+ div = PWM_CTRL_CFG_NO_SUB_DIV;
+ timebase = DIV_ROUND_UP(mul, 1);
+ } else if (mul <= MAX_TMBASE_STEPS * 8) {
+ div = PWM_CTRL_CFG_SUB_DIV0;
+ timebase = DIV_ROUND_UP(mul, 8);
+ } el
[PATCH v8 2/2] DT: pwm: Add binding document for IMG PWM DAC
From: Naidu Tellapati
Add binding document for IMG Pulse Width Modulator (PWM) DAC present on the
Pistachio SOC. The PWM DAC has four channels.
Signed-off-by: Naidu Tellapati
Signed-off-by: Sai Masarapu
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/pwm/img-pwm.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/img-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/img-pwm.txt
b/Documentation/devicetree/bindings/pwm/img-pwm.txt
new file mode 100644
index 000..fade5f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/img-pwm.txt
@@ -0,0 +1,24 @@
+*Imagination Technologies PWM DAC driver
+
+Required properties:
+ - compatible: Should be "img,pistachio-pwm"
+ - reg: Should contain physical base address and length of pwm registers.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries.
+- pwm: PWM operating clock.
+- sys: PWM system interface clock.
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for the
+ description of the cells format.
+ - img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node which contains PWM control registers.
+
+Example:
+ pwm: pwm@18101300 {
+ compatible = "img,pistachio-pwm";
+ reg = <0x18101300 0x100>;
+ clocks = <&pwm_clk>, <&system_clk>;
+ clock-names = "pwm", "sys";
+ #pwm-cells = <2>;
+ img,cr-periph = <&cr_periph>;
+ };
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] pwm: Imagination Technologies PWM DAC driver
On 01/08/2015 12:49 PM, Vladimir Zapolskiy wrote:
> Hi Ezequiel,
>
> On 07.01.2015 19:20, Ezequiel Garcia wrote:
>> From: Naidu Tellapati
>>
>> The Pistachio SOC from Imagination Technologies includes a Pulse Width
>> Modulation DAC which produces 1 to 4 digital bit-outputs which represent
>> digital waveforms. These PWM outputs are primarily in charge of controlling
>> backlight LED devices.
>>
>> Reviewed-by: Andrew Bresticker
>> Signed-off-by: Naidu Tellapati
>> Signed-off-by: Sai Masarapu
>> Signed-off-by: Ezequiel Garcia
>> ---
>> drivers/pwm/Kconfig | 13 +++
>> drivers/pwm/Makefile | 1 +
>> drivers/pwm/pwm-img.c | 250
>> ++
>> 3 files changed, 264 insertions(+)
>> create mode 100644 drivers/pwm/pwm-img.c
>>
>
> [snip]
>
>> +static int img_pwm_probe(struct platform_device *pdev)
>> +{
>> +int ret;
>> +struct resource *res;
>> +struct img_pwm_chip *pwm;
>> +
>> +pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>> +if (!pwm)
>> +return -ENOMEM;
>> +
>> +pwm->dev = &pdev->dev;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +pwm->base = devm_ioremap_resource(&pdev->dev, res);
>> +if (IS_ERR(pwm->base))
>> +return PTR_ERR(pwm->base);
>> +
>> +pwm->periph_regs = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
>> + "img,cr-periph");
>> +if (IS_ERR(pwm->periph_regs))
>> +return PTR_ERR(pwm->periph_regs);
>> +
>> +pwm->sys_clk = devm_clk_get(&pdev->dev, "sys");
>> +if (IS_ERR(pwm->sys_clk)) {
>> +dev_err(&pdev->dev, "failed to get system clock\n");
>> +return PTR_ERR(pwm->sys_clk);
>> +}
>> +
>> +pwm->pwm_clk = devm_clk_get(&pdev->dev, "pwm");
>> +if (IS_ERR(pwm->pwm_clk)) {
>> +dev_err(&pdev->dev, "failed to get pwm clock\n");
>> +return PTR_ERR(pwm->pwm_clk);
>> +}
>> +
>> +ret = clk_prepare_enable(pwm->sys_clk);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "could not prepare or enable sys clock\n");
>> +return ret;
>> +}
>> +
>> +ret = clk_prepare_enable(pwm->pwm_clk);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "could not prepare or enable pwm clock\n");
>> +goto disable_sysclk;
>> +}
>> +
>> +pwm->chip.dev = &pdev->dev;
>> +pwm->chip.ops = &img_pwm_ops;
>> +pwm->chip.base = -1;
>> +pwm->chip.npwm = 4;
>> +
>> +ret = pwmchip_add(&pwm->chip);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "pwmchip_add failed: %d\n", ret);
>> +goto disable_pwmclk;
>> +}
>> +
>> +platform_set_drvdata(pdev, pwm);
>> +
>> +disable_pwmclk:
>> +clk_disable_unprepare(pwm->pwm_clk);
>> +disable_sysclk:
>> +clk_disable_unprepare(pwm->sys_clk);
>> +
>> +return 0;
>
> return ret on error paths?
>
> Also should you reenable sys and pwm clocks after successful driver
> registration?
>
Argh, that's definitely bogus. I must have missed it.
Thanks for the catch!
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding
On 01/08/2015 02:04 AM, Peter Pan 潘栋 (peterpandong) wrote: >>> This commit adds the devicetree binding document that specifies the >>> spi nand devices support. >>> >>> Signed-off-by: Peter Pan >>> --- >>> Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 >> ++ >>> 1 file changed, 22 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/mtd/spi- >> nand.txt >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt >> b/Documentation/devicetree/bindings/mtd/spi-nand.txt >>> new file mode 100644 >>> index 000..9dd3efd >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt >>> @@ -0,0 +1,22 @@ >>> +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips >>> + >>> +Required properties: >>> +- #address-cells, #size-cells : Must be present if the device has >> sub-nodes >>> + representing partitions. >>> +- compatible : Should be the manufacturer and the name of the chip. >> Bear in mind >>> >> >> Unless I'm mistaken, we don't need the chip ID here, as SPI NAND allows >> to autodetect the device. Any reason why we can't just use a generic >> compatible "spi-nand" here? >> -- >> Ezequiel > > In fact, I don't know how to autodetect the SPI NAND device. Micron device and > Gigadevice device have different read ID functions. The Chip ID here is used > to > determine which function to use. > Isn't the difference between the Read ID very minor? One of the vendor needs a 2-byte ID read, and the other one needs a 3-byte ID read. So you can just try with 2-byte, and if that fails (no vendor ID is found on the first byte), you can try with the 3-byte command. It's not the most elegant solution, but it's not super awful either. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 3/4] pdm: Imagination Technologies PDM DAC driver
Hi, On 01/08/2015 11:21 AM, One Thousand Gnomes wrote: [..] > > and - you get the idea 8) > Thanks for all the comments. Before preparing a new patchset fixing them, I'd like to check with the maintainers (Thierry on PWM, and Greg on misc) about the validity of the general approach. Thierry had concerns about the syscon usage, and I'd like to make sure we settle that. Guys, any feedback? Thanks a lot! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mtd: spi-nand: add devicetree binding
On 01/07/2015 09:52 PM, Peter Pan 潘栋 (peterpandong) wrote: > This commit adds the devicetree binding document that specifies the > spi nand devices support. > > Signed-off-by: Peter Pan > --- > Documentation/devicetree/bindings/mtd/spi-nand.txt | 22 > ++ > 1 file changed, 22 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/spi-nand.txt > > diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt > b/Documentation/devicetree/bindings/mtd/spi-nand.txt > new file mode 100644 > index 000..9dd3efd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt > @@ -0,0 +1,22 @@ > +* NAND driver for MT29F, GD5F and similar SPI NAND flash chips > + > +Required properties: > +- #address-cells, #size-cells : Must be present if the device has sub-nodes > + representing partitions. > +- compatible : Should be the manufacturer and the name of the chip. Bear in > mind > Unless I'm mistaken, we don't need the chip ID here, as SPI NAND allows to autodetect the device. Any reason why we can't just use a generic compatible "spi-nand" here? -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/4] DT: pwm: Add binding document for IMG PWM DAC
From: Naidu Tellapati
Add binding document for IMG Pulse Width Modulator (PWM) DAC present on the
Pistachio SOC. The PWM DAC has four channels.
Signed-off-by: Naidu Tellapati
Signed-off-by: Sai Masarapu
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/pwm/img-pwm.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/img-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/img-pwm.txt
b/Documentation/devicetree/bindings/pwm/img-pwm.txt
new file mode 100644
index 000..fade5f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/img-pwm.txt
@@ -0,0 +1,24 @@
+*Imagination Technologies PWM DAC driver
+
+Required properties:
+ - compatible: Should be "img,pistachio-pwm"
+ - reg: Should contain physical base address and length of pwm registers.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries.
+- pwm: PWM operating clock.
+- sys: PWM system interface clock.
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for the
+ description of the cells format.
+ - img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node which contains PWM control registers.
+
+Example:
+ pwm: pwm@18101300 {
+ compatible = "img,pistachio-pwm";
+ reg = <0x18101300 0x100>;
+ clocks = <&pwm_clk>, <&system_clk>;
+ clock-names = "pwm", "sys";
+ #pwm-cells = <2>;
+ img,cr-periph = <&cr_periph>;
+ };
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/4] Imagination Technologies PWM and PDM DACs support
This patchset is the seventh round for the IMG PWM and PDM DAC drivers. The PWM driver is a typical PWM, and I don't think there's anything controversial there. The PDM driver -on the other side- is a bit ackward. At first, we tried to support it as a PWM, but after some lengthy discussions, we came to the conclusion the controller couldn't be configured with duty and period, so it was agreed [1] to write a misc driver for it. Given there won't be any framework (the controller is too rare to justify a new framework), an internal API is needed. We've tried to keep this API as simple as possible. Also, we've tried to follow a devicetree binding similar to the PWM one. Users of the PDM can call a couple functions to request a channel and release the resource: struct img_pdm_channel *img_pdm_channel_get(struct device *dev); void img_pdm_channel_put(struct device *dev); After requesting a PDM channel, users can enable or configure it: int img_pdm_channel_enable(struct img_pdm_channel *chan, bool state); int img_pdm_channel_config(struct img_pdm_channel *chan, unsigned int val); Where 'val' is a hardware-specific quantity, namely, a 12-bit value that is added to the PDM counter: counter [12:0] = counter [11:0] + value [11:0] PDM output = counter [12] Hence, by changing the 'value' it's possible to control the pulse density (lower values, correspond to lower densities). Given this looks like very platform-specific, I feel the misc driver is a good solution, but I'm open to discussion about it. The reason why these two drivers are being sent together is because of the peripheral register that is used to enable an output, and mux it as PWM or PDM. Because this register is not part of the pin controller block, but rather PWM/PDM specific, and because the register is also used to set the PDM value, it is simpler to use a regmap-based syscon to deal with it. The series is based on v3.19-rc3. My goal is to merge at least the PWM driver for v3.20, if we fail to agree on the PDM driver. [1] http://www.spinics.net/lists/linux-pwm/msg01990.html Naidu Tellapati (4): pwm: Imagination Technologies PWM DAC driver DT: pwm: Add binding document for IMG PWM DAC pdm: Imagination Technologies PDM DAC driver DT: pdm: Add binding document for IMG PDM DAC Documentation/devicetree/bindings/misc/img-pdm.txt | 54 ++ Documentation/devicetree/bindings/pwm/img-pwm.txt | 24 + drivers/misc/Kconfig | 13 + drivers/misc/Makefile | 1 + drivers/misc/img-pdm.c | 608 + drivers/pwm/Kconfig| 13 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-img.c | 250 + include/linux/img_pdm.h| 27 + 9 files changed, 991 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/img-pdm.txt create mode 100644 Documentation/devicetree/bindings/pwm/img-pwm.txt create mode 100644 drivers/misc/img-pdm.c create mode 100644 drivers/pwm/pwm-img.c create mode 100644 include/linux/img_pdm.h -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/4] DT: pdm: Add binding document for IMG PDM DAC
From: Naidu Tellapati
Add binding document for the Pulse Density Modulator (PDM) DAC present on the
Pistachio SOC.
Signed-off-by: Naidu Tellapati
Signed-off-by: Arul Ramasamy
Signed-off-by: Ezequiel Garcia
---
Documentation/devicetree/bindings/misc/img-pdm.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/img-pdm.txt
diff --git a/Documentation/devicetree/bindings/misc/img-pdm.txt
b/Documentation/devicetree/bindings/misc/img-pdm.txt
new file mode 100644
index 000..96fde23
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/img-pdm.txt
@@ -0,0 +1,54 @@
+Imagination Technologies Pulse Density Modulator (PDM) DAC.
+
+Required properties:
+- compatible: Must be "img,pistachio-pdm"
+- clocks: phandle to input PDM clock
+- clock-names: Must include the following entry:
+ - pdm: input clock to pdm block.
+- img,cr-periph: Must contain a phandle to the peripheral control
+ syscon node which contains PDM control registers.
+- #pdm-cells: Must be 2.
+- The first cell is the PDM channel number (valid values: 0, 1, 2, 3)
+- The second cell is 12-bit pulse-in value
+
+Specifying PDM information for devices
+==
+
+1. PDM User nodes
+
+PDM properties should be named "pdms". The exact meaning of each pdms property
+is described above.
+
+ pdm-specifier : array of #pdm-cells specifying the given PDM
+ (controller specific)
+
+The following example could be used to describe a PDM-based backlight device:
+
+ pdm: pdm {
+ #pdm-cells = <2>;
+ };
+
+ [...]
+
+ bl: backlight {
+ pdms = <&pdm 2 0>;
+ };
+
+pdm-specifier typically encodes the chip-relative PDM channel number and the
+12-bit pulse-in value.
+
+2. PDM Controller nodes
+
+PDM controller nodes must specify the number of cells used for the specifier
+using the '#pdm-cells' property.
+
+An example PDM controller might look like this:
+
+Example:
+ pdm: pdm@18148000 {
+ compatible = "img,pistachio-pdm";
+ clocks = <&pdm_clk>;
+ clk-names = "pdm";
+ img,cr-periph = <&cr_periph>;
+ #pdm-cells = <2>;
+ };
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/4] pdm: Imagination Technologies PDM DAC driver
From: Naidu Tellapati
The Pistachio SOC from Imagination Technologies includes a Pulse Density
Modulation DAC which produces a form of analogue output according to the
relative density of output pulses to the intended analogue signal amplitude.
Four PDM outputs are provided that can be used to control targets such as LCD
backlight.
Signed-off-by: Naidu Tellapati
Signed-off-by: Arul Ramasamy
Signed-off-by: Ezequiel Garcia
---
drivers/misc/Kconfig| 13 ++
drivers/misc/Makefile | 1 +
drivers/misc/img-pdm.c | 608
include/linux/img_pdm.h | 27 +++
4 files changed, 649 insertions(+)
create mode 100644 drivers/misc/img-pdm.c
create mode 100644 include/linux/img_pdm.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 006242c..5ec7263 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config IMG_PDM
+ tristate "Imagination Technologies PDM driver"
+ depends on HAS_IOMEM
+ depends on MFD_SYSCON
+ depends on COMMON_CLK
+ depends on MIPS || COMPILE_TEST
+ help
+ PDM driver for Imagination Technologies PDM block which supports 4
+ channels.
+
+ To compile this driver as a module, choose M here: the module will
+ be called img-pdm.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7d5c4cd..d8c7d55 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_IMG_PDM) += img-pdm.o
diff --git a/drivers/misc/img-pdm.c b/drivers/misc/img-pdm.c
new file mode 100644
index 000..6cdde51
--- /dev/null
+++ b/drivers/misc/img-pdm.c
@@ -0,0 +1,608 @@
+/**
+ * Imagination Technologies Pulse Density Modulator driver
+ *
+ * Copyright (C) 2014-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers */
+#define PERIP_PWM_PDM_CONTROL 0x0140
+#define PERIP_PWM_PDM_CONTROL_CH_MASK 0x1
+#define PERIP_PWM_PDM_CONTROL_CH_SHIFT(ch) ((ch) * 4)
+
+#define PERIP_PDM0_VAL 0x0144
+#define PERIP_PDM_CH_ADDR_SHIFT(ch)((ch) * 4)
+#define PERIP_PDM_SRC_DATA_MASK0xfff
+
+#define IMG_NUM_PDM4
+#define PDM_CHANNEL_REQUESTED 1
+#define PDM_CHANNEL_ENABLED2
+
+struct img_pdm_device {
+ struct clk *clk;
+ struct kobject **pdm_kobj;
+ struct regmap *periph_regs;
+ struct platform_device *pdev;
+};
+
+static struct img_pdm_channel *pdm_channels;
+static DEFINE_MUTEX(pdm_lock);
+
+int img_pdm_channel_config(struct img_pdm_channel *chan, unsigned int val)
+{
+ struct img_pdm_device *pdm_dev;
+
+ if (!chan)
+ return -EINVAL;
+
+ pdm_dev = chan->pdm_dev;
+ if (!test_bit(PDM_CHANNEL_REQUESTED, &chan->flags)) {
+ dev_err(&pdm_dev->pdev->dev, "channel not requested\n");
+ return -EINVAL;
+ }
+
+ val &= PERIP_PDM_SRC_DATA_MASK;
+ regmap_write(pdm_dev->periph_regs,
+PERIP_PDM0_VAL + PERIP_PDM_CH_ADDR_SHIFT(chan->pdm_id),
+val);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(img_pdm_channel_config);
+
+static int img_pdm_channel_free(struct img_pdm_channel *chan)
+{
+ unsigned int i;
+ struct img_pdm_device *pdm_dev;
+
+ mutex_lock(&pdm_lock);
+
+ if (!pdm_channels || !chan) {
+ mutex_unlock(&pdm_lock);
+ return -EINVAL;
+ }
+
+ pdm_dev = pdm_channels[0].pdm_dev;
+ if (!pdm_dev) {
+ mutex_unlock(&pdm_lock);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < IMG_NUM_PDM; i++) {
+ if (&pdm_channels[i] && (&pdm_channels[i] == chan))
+ break;
+ }
+
+ if (i == IMG_NUM_PDM) {
+ mutex_unlock(&pdm_lock);
+ return -EINVAL;
+ }
+
+ if (test_bit(PDM_CHANNEL_ENABLED, &chan->flags)) {
+ dev_err(
[PATCH v7 1/4] pwm: Imagination Technologies PWM DAC driver
From: Naidu Tellapati
The Pistachio SOC from Imagination Technologies includes a Pulse Width
Modulation DAC which produces 1 to 4 digital bit-outputs which represent
digital waveforms. These PWM outputs are primarily in charge of controlling
backlight LED devices.
Reviewed-by: Andrew Bresticker
Signed-off-by: Naidu Tellapati
Signed-off-by: Sai Masarapu
Signed-off-by: Ezequiel Garcia
---
drivers/pwm/Kconfig | 13 +++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-img.c | 250 ++
3 files changed, 264 insertions(+)
create mode 100644 drivers/pwm/pwm-img.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a3ecf58..1681cd0 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -130,6 +130,19 @@ config PWM_FSL_FTM
To compile this driver as a module, choose M here: the module
will be called pwm-fsl-ftm.
+config PWM_IMG
+ tristate "Imagination Technologies PWM driver"
+ depends on HAS_IOMEM
+ depends on MFD_SYSCON
+ depends on COMMON_CLK
+ depends on MIPS || COMPILE_TEST
+ help
+ Generic PWM framework driver for Imagination Technologies
+ PWM block which supports 4 channels.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-img
+
config PWM_IMX
tristate "i.MX PWM support"
depends on ARCH_MXC
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 65259ac..85381e4 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
obj-$(CONFIG_PWM_FSL_FTM) += pwm-fsl-ftm.o
+obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
diff --git a/drivers/pwm/pwm-img.c b/drivers/pwm/pwm-img.c
new file mode 100644
index 000..ad32539
--- /dev/null
+++ b/drivers/pwm/pwm-img.c
@@ -0,0 +1,250 @@
+/*
+ * Imagination Technologies Pulse Width Modulator driver
+ *
+ * Copyright (c) 2014-2015, Imagination Technologies
+ *
+ * Based on drivers/pwm/pwm-tegra.c, Copyright (c) 2010, NVIDIA Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PWM registers */
+#define PWM_CTRL_CFG 0x
+#define PWM_CTRL_CFG_NO_SUB_DIV0
+#define PWM_CTRL_CFG_SUB_DIV0 1
+#define PWM_CTRL_CFG_SUB_DIV1 2
+#define PWM_CTRL_CFG_SUB_DIV0_DIV1 3
+#define PWM_CTRL_CFG_DIV_SHIFT(ch) ((ch) * 2 + 4)
+#define PWM_CTRL_CFG_DIV_MASK 0x3
+
+#define PWM_CH_CFG(ch) (0x4 + (ch) * 4)
+#define PWM_CH_CFG_TMBASE_SHIFT0
+#define PWM_CH_CFG_DUTY_SHIFT 16
+
+#define PERIP_PWM_PDM_CONTROL 0x0140
+#define PERIP_PWM_PDM_CONTROL_CH_MASK 0x1
+#define PERIP_PWM_PDM_CONTROL_CH_SHIFT(ch) ((ch) * 4)
+
+#define MAX_TMBASE_STEPS 65536
+
+struct img_pwm_chip {
+ struct device *dev;
+ struct pwm_chip chip;
+ struct clk *pwm_clk;
+ struct clk *sys_clk;
+ void __iomem*base;
+ struct regmap *periph_regs;
+};
+
+static inline struct img_pwm_chip *to_img_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct img_pwm_chip, chip);
+}
+
+static inline void img_pwm_writel(struct img_pwm_chip *chip,
+ u32 reg, u32 val)
+{
+ writel(val, chip->base + reg);
+}
+
+static inline u32 img_pwm_readl(struct img_pwm_chip *chip,
+u32 reg)
+{
+ return readl(chip->base + reg);
+}
+
+static int img_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ u32 val, div, duty, timebase;
+ unsigned long mul, output_clk_hz, input_clk_hz;
+ struct img_pwm_chip *pwm_chip = to_img_pwm_chip(chip);
+
+ input_clk_hz = clk_get_rate(pwm_chip->pwm_clk);
+ output_clk_hz = DIV_ROUND_UP(NSEC_PER_SEC, period_ns);
+
+ mul = DIV_ROUND_UP(input_clk_hz, output_clk_hz);
+ if (mul <= MAX_TMBASE_STEPS) {
+ div = PWM_CTRL_CFG_NO_SUB_DIV;
+ timebase = DIV_ROUND_UP(mul, 1);
+ } else if (mul <= MAX_TMBASE_STEPS * 8) {
+ div = PWM_CTRL_CFG_SUB_DIV0;
+ timebase = DIV_ROUND_UP(mul, 8);
+ } el
Re: [PATCH V2 2/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver.
(CCing DT mailing list and DT binding maintainers)
On 01/06/2015 02:08 PM, Graham Moore wrote:
> Signed-off-by: Graham Moore
> ---
> .../devicetree/bindings/mtd/cadence_quadspi.txt| 50
>
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> new file mode 100644
> index 000..3a8ea1c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/cadence_quadspi.txt
> @@ -0,0 +1,50 @@
> +* Cadence Quad SPI controller
> +
> +Required properties:
> +- compatible : Should be "cdns,qspi-nor".
> +- reg : Contains two entries, each of which is a tuple consisting of a
> + physical address and length. The first entry is the address and
> + length of the controller register set. The second entry is the
> + address and length of the QSPI Controller data area.
> +- interrupts : Unit interrupt specifier for the controller interrupt.
> +- clocks : phandle to the Quad SPI clock.
> +- ext-decoder : Value of 0 means no external chipselect decoder is
> + connected, 1 means there is an external chipselect decoder connected.
As I already said in the driver patch, I think this property should be
boolean and have a vendor prefix.
> +- fifo-depth : Size of the data FIFO in words.
This one looks generic enough to leave it as it is, without any vendor
prefix.
> +- bus-num : Number of the SPI bus to which the controller is connected.
> +
I think you forgot to remove bus-num here.
> +Optional subnodes:
> +Subnodes of the Cadence Quad SPI controller are spi slave nodes with
> additional
> +custom properties:
> +- cdns,page-size : Size, in bytes, of the device's write page
> +- cdns,block-size : Size of the device's erase block
> +- cdns,read-delay : Selay for read capture logic, in clock cycles
> +- cdns,tshsl-ns : Delay in master reference clocks for the length that the
> master mode chip select outputs are de-asserted between transactions.
> +- cdns,tsd2d-ns : Delay in master reference clocks between one chip select
> being de-activated and the activation of another.
> +- cdns,tchsh-ns : Delay in master reference clocks between last bit of
> current transaction and deasserting the device chip select (qspi_n_ss_out).
> +- cdns,tslch-ns : Delay in master reference clocks between setting
> qspi_n_ss_out low and first bit transfer.
> +
> +Example:
> +
> + qspi: spi@ff705000 {
> + compatible = "cdns,qspi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0xff705000 0x1000>,
> + <0xffa0 0x1000>;
> + interrupts = <0 151 4>;
> + clocks = <&qspi_clk>;
> + ext-decoder = <0>;
> + fifo-depth = <128>;
> +
> + flash0: n25q00@0 {
> + ...
> + cdns,page-size = <256>;
> + cdns,block-size = <16>;
> + cdns,read-delay = <4>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> + }
> + }
>
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: orion: Add multiple chip select support for Armada 370 and 375
On 01/06/2015 06:30 PM, Ken Wilson wrote: > Create a new dt binding for the Armada 375 that supports up to > 3 chip selects but uses the same prescaler values and algorithm > as the basic orion binding. > > Update the Armada 370 so that it supports up to 4 chip selects. > > This has been tested on the Armada 375 with multiple SPI-NOR chips. > > Signed-off-by: Ken Wilson > --- > .../devicetree/bindings/spi/spi-orion.txt | 3 ++- > arch/arm/boot/dts/armada-375.dtsi | 4 +-- > drivers/spi/spi-orion.c| 29 > +++--- You will have to split this changeset in three patches, given these three files carry different kind of changes: 1. The driver change itself 2. The devicetree binding documentation change 3. The devicetree dtsi change Regards, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/3] DT: iio: adc: Add CC_10001 binding documentation
From: Phani Movva
Add the devicetree binding document for Cosmic Circuits 10001 ADC device.
Reviewed-by: Andrew Bresticker
Acked-by: Rob Herring
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
new file mode 100644
index 000..904f76d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
@@ -0,0 +1,22 @@
+* Cosmic Circuits - Analog to Digital Converter (CC-10001-ADC)
+
+Required properties:
+ - compatible: Should be "cosmic,10001-adc"
+ - reg: Should contain adc registers location and length.
+ - clock-names: Should contain "adc".
+ - clocks: Should contain a clock specifier for each entry in clock-names
+ - vref-supply: The regulator supply ADC reference voltage.
+
+Optional properties:
+ - adc-reserved-channels: Bitmask of reserved channels,
+i.e. channels that cannot be used by the OS.
+
+Example:
+adc: adc@18101600 {
+ compatible = "cosmic,10001-adc";
+ reg = <0x18101600 0x24>;
+ adc-reserved-channels = <0x2>;
+ clocks = <&adc_clk>;
+ clock-names = "adc";
+ vref-supply = <®_1v8>;
+};
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
From: Phani Movva
This commit adds support for Cosmic Circuits 10001 10-bit ADC device.
Reviewed-by: Andrew Bresticker
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
[ezequiel: code style cleaning]
Signed-off-by: Ezequiel Garcia
---
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/cc10001_adc.c | 423 ++
3 files changed, 435 insertions(+)
create mode 100644 drivers/iio/adc/cc10001_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 0f79e47..9cb8543 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -135,6 +135,17 @@ config AXP288_ADC
device. Depending on platform configuration, this general purpose ADC
can
be used for sampling sensors such as thermal resistors.
+config CC10001_ADC
+ tristate "Cosmic Circuits 10001 ADC driver"
+ depends on HAS_IOMEM || HAVE_CLK || REGULATOR
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Cosmic Circuits 10001 ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called cc10001_adc.
+
config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF &&
COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 701fdb7..ce60fe9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
+obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
diff --git a/drivers/iio/adc/cc10001_adc.c b/drivers/iio/adc/cc10001_adc.c
new file mode 100644
index 000..47f638b
--- /dev/null
+++ b/drivers/iio/adc/cc10001_adc.c
@@ -0,0 +1,423 @@
+/*
+ * Copyright (c) 2014-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers */
+#define CC10001_ADC_CONFIG 0x00
+#define CC10001_ADC_START_CONV BIT(4)
+#define CC10001_ADC_MODE_SINGLE_CONV BIT(5)
+
+#define CC10001_ADC_DDATA_OUT 0x04
+#define CC10001_ADC_EOC0x08
+#define CC10001_ADC_EOC_SETBIT(0)
+
+#define CC10001_ADC_CHSEL_SAMPLED 0x0c
+#define CC10001_ADC_POWER_UP 0x10
+#define CC10001_ADC_POWER_UP_SET BIT(0)
+#define CC10001_ADC_DEBUG 0x14
+#define CC10001_ADC_DATA_COUNT 0x20
+
+#define CC10001_ADC_DATA_MASK GENMASK(9, 0)
+#define CC10001_ADC_NUM_CHANNELS 8
+#define CC10001_ADC_CH_MASKGENMASK(2, 0)
+
+#define CC10001_INVALID_SAMPLED0x
+#define CC10001_MAX_POLL_COUNT 20
+
+/*
+ * As per device specification, wait six clock cycles after power-up to
+ * activate START. Since adding two more clock cycles delay does not
+ * impact the performance too much, we are adding two additional cycles delay
+ * intentionally here.
+ */
+#defineCC10001_WAIT_CYCLES 8
+
+struct cc10001_adc_device {
+ void __iomem *reg_base;
+ struct clk *adc_clk;
+ struct regulator *reg;
+ u16 *buf;
+
+ struct mutex lock;
+ unsigned long channel_map;
+ unsigned int start_delay_ns;
+ unsigned int eoc_delay_ns;
+};
+
+static inline void cc10001_adc_write_reg(struct cc10001_adc_device *adc_dev,
+u32 reg, u32 val)
+{
+ writel(val, adc_dev->reg_base + reg);
+}
+
+static inline u32 cc10001_adc_read_reg(struct cc10001_adc_device *adc_dev,
+ u32 reg)
+{
+ return readl(adc_dev->reg_base + reg);
+}
+
+static void cc10001_adc_start(struct cc10001_adc_device *adc_dev,
+ unsigned int channel)
+{
+ u32 val;
+
+ /* Channel selection and mode of operation */
+ val = (channel & CC10001_ADC_CH_MASK) | CC10001_ADC_MODE_SINGLE_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+
+ val = cc10001_adc_read_reg(adc_dev, CC10001_ADC_CONFIG);
+ val = val | CC10001_ADC_START_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+}
+
+static u16 cc10001_adc_poll_done(struct iio_dev *indio_dev,
+unsigned int channel,
+unsigned int delay)
+{
+ struct cc10001_ad
[PATCH v7 3/3] DT: Add a vendor prefix for Cosmic Circuits
Reviewed-by: Andrew Bresticker Acked-by: Rob Herring Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b1df0ad..014770f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -36,6 +36,7 @@ chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. cnmChips&Media, Inc. cortinaCortina Systems, Inc. +cosmic Cosmic Circuits crystalfontz Crystalfontz America, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
This series add the support for an ADC IP block from Cosmic Circuits. The patchset is based on v3.19-rc3. As agreed with Rob, this series drops the vendor prefix in the adc-reserved-channels DT property. This property is generic enough to be used in other drivers (at91 is a potential candidate). A follow-up patch can use the property in at91 and add it to the IIO generic bindings. Changes from v6: * Dropped the vendor prefix in the adc-reserved-channels property, as suggested by Rob. * Added Andrew's Reviewed-by tags. Andrew reviewed v3, and the driver changed little since then. http://www.spinics.net/lists/linux-iio/msg15630.html. Changes from v5: * Fixed CC10001_ADC_CH_MASK macro definition, to separate the channel number from the channel map, as noted by Hartmut. * Return the real error code in devm_regulator_get failure. Changes from v4: * Added a compile-time dependency on REGULATOR and HAVE_CLK. * Replaced the silly XOR operation for a proper mask out of the available channels. Changes from v3: * Fixed a few style nitpicks as per Hartmut's feedback. * Used GENMASK() to build the channel mask, which fixes a very nasty bug. Also found by Hartmut. Changes from v2: * Changed a devicetree property from adc-available-channels to adc-reserved-channels, so it can be made optional. * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's consistent with the rest of the kernel style. * Some more minor cosmetic fixes. Changes from v1: * Removed unneeded header includes. * Changed all the names and macros prefix: s/CC_10001_/CC10001_. * Used .update_scan_mode callback to preallocate the buffer. * Used indio_dev for the struct iio_dev. * Only read the regulator voltage when needed. * Fixed probe() error handling. * Used for_each_set_bit() instead of open-coding it. * Name the power-down register as _POWER_UP, to make the code less silly. * Error out when no valid sample can be read (i.e. when end-of-conversion poll times out). * ... plus some assorted code cleaning based on the feedback. Ezequiel Garcia (1): DT: Add a vendor prefix for Cosmic Circuits Phani Movva (2): iio: adc: Cosmic Circuits 10001 ADC driver DT: iio: adc: Add CC_10001 binding documentation .../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/cc10001_adc.c | 423 + 5 files changed, 458 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt create mode 100644 drivers/iio/adc/cc10001_adc.c -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mtd: nand: add NVIDIA Tegra NAND Flash controller driver
clk);
> + if (err)
> + return err;
> +
> + reset_control_assert(nand->rst);
> + udelay(2);
> + reset_control_deassert(nand->rst);
> +
> + if (gpio_is_valid(nand->wp_gpio)) {
> + err = devm_gpio_request_one(&pdev->dev, nand->wp_gpio,
> + GPIOF_OUT_INIT_HIGH, "tegra-nand-wp");
> + if (err)
> + return err;
> + }
> +
> + value = HWSTATUS_RDSTATUS_MASK(1) | HWSTATUS_RDSTATUS_VALUE(0) |
> + HWSTATUS_RBSY_MASK(NAND_STATUS_READY) |
> + HWSTATUS_RBSY_VALUE(NAND_STATUS_READY);
> + writel(NAND_CMD_STATUS, nand->regs + HWSTATUS_CMD);
> + writel(value, nand->regs + HWSTATUS_MASK);
> +
> + init_completion(&nand->command_complete);
> + init_completion(&nand->dma_complete);
> +
> + mtd = &nand->mtd;
> + mtd->name = dev_name(&pdev->dev);
> + mtd->owner = THIS_MODULE;
> + mtd->priv = &nand->chip;
> +
> + mtd->type = MTD_NANDFLASH;
> + mtd->flags = MTD_CAP_NANDFLASH;
> +
> + /* clear interrupts */
> + value = readl(nand->regs + ISR);
> + writel(value, nand->regs + ISR);
> +
> + writel(DMA_CTRL_IS_DONE, nand->regs + DMA_CTRL);
> +
> + /* enable interrupts */
> + value = IER_UND | IER_OVR | IER_CMD_DONE | IER_ECC_ERR | IER_GIE;
> + writel(value, nand->regs + IER);
> +
> + chip = &nand->chip;
> + chip->cmdfunc = tegra_nand_command;
> + chip->select_chip = tegra_nand_select_chip;
> + chip->read_byte = tegra_nand_read_byte;
> + chip->read_buf = tegra_nand_read_buf;
> + chip->write_buf = tegra_nand_write_buf;
> +
> + tegra_nand_setup_timing(nand, 0);
> +
> + err = nand_scan_ident(mtd, 1, NULL);
> + if (err)
> + return err;
> +
> + nand->data_buf = dmam_alloc_coherent(&pdev->dev, mtd->writesize,
> + &nand->data_dma, GFP_KERNEL);
> + if (!nand->data_buf)
> + return -ENOMEM;
> +
> + nand->oob_buf = dmam_alloc_coherent(&pdev->dev, mtd->oobsize,
> + &nand->oob_dma, GFP_KERNEL);
> + if (!nand->oob_buf)
> + return -ENOMEM;
> +
> + chip->ecc.mode = NAND_ECC_HW;
> + chip->ecc.size = 512;
> + chip->ecc.bytes = mtd->oobsize;
> + chip->ecc.read_page = tegra_nand_read_page;
> + chip->ecc.write_page = tegra_nand_write_page;
> +
> + value = CFG_HW_ECC | CFG_ECC_SEL | CFG_ERR_COR | CFG_PIPE_EN |
> + CFG_TVAL_8 | CFG_SKIP_SPARE | CFG_SKIP_SPARE_SIZE_4;
> +
> + switch (mtd->oobsize) {
> + case 16:
> + chip->ecc.layout = &tegra_nand_oob_16;
> + chip->ecc.strength = 1;
> + value |= CFG_TAG_BYTE_SIZE(4);
> + break;
> + case 64:
> + chip->ecc.layout = &tegra_nand_oob_64;
> + chip->ecc.strength = 8;
> + value |= CFG_TAG_BYTE_SIZE(36);
> + break;
> + case 128:
> + chip->ecc.layout = &tegra_nand_oob_128;
> + chip->ecc.strength = 8;
> + value |= CFG_TAG_BYTE_SIZE(72);
> + break;
> + case 224:
> + chip->ecc.layout = &tegra_nand_oob_224;
> + chip->ecc.strength = 8;
> + value |= CFG_TAG_BYTE_SIZE(144);
> + break;
> + default:
> + dev_err(&pdev->dev, "unhandled OOB size %d\n", mtd->oobsize);
> + return -ENODEV;
> + }
> +
> + switch (mtd->writesize) {
> + case 256:
> + value |= CFG_PS_256;
> + break;
> + case 512:
> + value |= CFG_PS_512;
> + break;
> + case 1024:
> + value |= CFG_PS_1024;
> + break;
> + case 2048:
> + value |= CFG_PS_2048;
> + break;
> + case 4096:
Nit: we have macros for these values (SZ_256, ..., SZ_4K).
> + value |= CFG_PS_4096;
> + break;
> + default:
> + dev_err(&pdev->dev, "unhandled writesize %d\n", mtd->writesize);
> + return -ENODEV;
> + }
> +
> + if (nand->buswidth == 16)
> + value |= CFG_BUS_WIDTH_16;
> +
> + writel(value, nand->regs + CFG);
> +
> + tegra_nand_setup_chiptiming(nand);
> +
> + err = nand_scan_tail(mtd);
> + if (err)
> + return err;
> +
> + mtd_device_parse_register(mtd, NULL,
> + &(struct mtd_part_parser_data) {
> + .of_node = pdev->dev.of_node,
> + },
> + NULL, 0);
> +
> + platform_set_drvdata(pdev, nand);
> +
> + return 0;
> +}
> +
> +static int tegra_nand_remove(struct platform_device *pdev)
> +{
> + struct tegra_nand *nand = platform_get_drvdata(pdev);
> +
> + nand_release(&nand->mtd);
> +
> + clk_disable_unprepare(nand->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id tegra_nand_of_match[] = {
> + { .compatible = "nvidia,tegra20-nand" },
> + { .compatible = "nvidia,tegra30-nand" },
AFAIK, having two compatible strings, but making no distinction between
them is typically frowned upon by devicetree maintainers.
Is the controller any different in tegra20 and tegra30?
If you are not sure about the controllers being different, you can
try the following approach. The devicetree is written like this:
nand@foo {
compatible = "nvidia,tegra20-nand", "nvidia,tegra-nand";
};
So you only deal with "nvidia,tegra-nand" in the driver, yet the
devicetree files are prepared to deal with a difference.
> + { }
> +};
> +
> +static struct platform_driver tegra_nand_driver = {
> + .driver = {
> + .name = "tegra-nand",
> + .of_match_table = tegra_nand_of_match,
> + },
> + .probe = tegra_nand_probe,
> + .remove = tegra_nand_remove,
> +};
> +module_platform_driver(tegra_nand_driver);
> +
> +MODULE_DESCRIPTION("NVIDIA Tegra NAND driver");
> +MODULE_AUTHOR("Thierry Reding +MODULE_AUTHOR("Lucas Stach +MODULE_LICENSE("GPL v2");
> +MODULE_DEVICE_TABLE(of, tegra_nand_of_match);
>
Regards,
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/3] DT: iio: adc: Add CC_10001 binding documentation
Hi Rob, Thanks a lot for the comments. On 01/06/2015 01:30 PM, Rob Herring wrote: > On Tue, Jan 6, 2015 at 9:29 AM, Ezequiel Garcia > wrote: >> From: Phani Movva >> >> Add the devicetree binding document for Cosmic Circuits 10001 ADC device. >> >> Signed-off-by: Phani Movva >> Signed-off-by: Naidu Tellapati >> [Ezequiel: minor style cleaning] >> Signed-off-by: Ezequiel Garcia >> --- >> .../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 >> ++ >> 1 file changed, 22 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt >> >> diff --git a/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt >> b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt >> new file mode 100644 >> index 000..b7ba558 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt >> @@ -0,0 +1,22 @@ >> +* Cosmic Circuits - Analog to Digital Converter (CC-10001-ADC) >> + >> +Required properties: >> + - compatible: Should be "cosmic,10001-adc" >> + - reg: Should contain adc registers location and length. >> + - clock-names: Should contain "adc". >> + - clocks: Should contain a clock specifier for each entry in clock-names >> + - vref-supply: The regulator supply ADC reference voltage. >> + >> +Optional properties: >> + - cosmic,adc-reserved-channels: Bitmask of reserved channels, >> +i.e. channels that cannot be used by the OS. > > Seems like this could be pretty common for any ADC as well as having > the number of channels, so you can drop the vendor prefix. Do we have > any similar properties already in other drivers? Well, it seems the AT91 ADC has a similar property called adc-channels-used. Not sure if it means the same as here. We are not using it to model a hardware availability but the channels being reserved for another core or OS. See [1]. > I'd reverse the > polarity to be enabled channels, then the number of available channels > is the top set bit plus 1. You could count channels as is, but then > people have to remember to set the high bits on non-existent channels. Hm, isn't this too cumbersome? If we really need to pass the number of channels, shouldn't we have a separate property for that? Note that no driver currently needs it. > Absence of the property could still mean you know how many channels > and all are enabled. > This property was originally proposed to be "called cosmic,adc-available-channels". Andrew suggested to reverse the polarity, and be explicit about absence of property meaning no reserved channels (also in [1]). I'm fine either way. [1] http://www.spinics.net/lists/linux-iio/msg15578.html -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/3] DT: Add a vendor prefix for Cosmic Circuits
Acked-by: Rob Herring Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b1df0ad..014770f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -36,6 +36,7 @@ chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. cnmChips&Media, Inc. cortinaCortina Systems, Inc. +cosmic Cosmic Circuits crystalfontz Crystalfontz America, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
From: Phani Movva
This commit adds support for Cosmic Circuits 10001 10-bit ADC device.
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
[ezequiel: code style cleaning]
Signed-off-by: Ezequiel Garcia
---
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/cc10001_adc.c | 424 ++
3 files changed, 436 insertions(+)
create mode 100644 drivers/iio/adc/cc10001_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 0f79e47..9cb8543 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -135,6 +135,17 @@ config AXP288_ADC
device. Depending on platform configuration, this general purpose ADC
can
be used for sampling sensors such as thermal resistors.
+config CC10001_ADC
+ tristate "Cosmic Circuits 10001 ADC driver"
+ depends on HAS_IOMEM || HAVE_CLK || REGULATOR
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Cosmic Circuits 10001 ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called cc10001_adc.
+
config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF &&
COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 701fdb7..ce60fe9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
+obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
diff --git a/drivers/iio/adc/cc10001_adc.c b/drivers/iio/adc/cc10001_adc.c
new file mode 100644
index 000..1ef4329
--- /dev/null
+++ b/drivers/iio/adc/cc10001_adc.c
@@ -0,0 +1,424 @@
+/*
+ * Copyright (c) 2014-2015 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers */
+#define CC10001_ADC_CONFIG 0x00
+#define CC10001_ADC_START_CONV BIT(4)
+#define CC10001_ADC_MODE_SINGLE_CONV BIT(5)
+
+#define CC10001_ADC_DDATA_OUT 0x04
+#define CC10001_ADC_EOC0x08
+#define CC10001_ADC_EOC_SETBIT(0)
+
+#define CC10001_ADC_CHSEL_SAMPLED 0x0c
+#define CC10001_ADC_POWER_UP 0x10
+#define CC10001_ADC_POWER_UP_SET BIT(0)
+#define CC10001_ADC_DEBUG 0x14
+#define CC10001_ADC_DATA_COUNT 0x20
+
+#define CC10001_ADC_DATA_MASK GENMASK(9, 0)
+#define CC10001_ADC_NUM_CHANNELS 8
+#define CC10001_ADC_CH_MASKGENMASK(2, 0)
+
+#define CC10001_INVALID_SAMPLED0x
+#define CC10001_MAX_POLL_COUNT 20
+
+/*
+ * As per device specification, wait six clock cycles after power-up to
+ * activate START. Since adding two more clock cycles delay does not
+ * impact the performance too much, we are adding two additional cycles delay
+ * intentionally here.
+ */
+#defineCC10001_WAIT_CYCLES 8
+
+struct cc10001_adc_device {
+ void __iomem *reg_base;
+ struct clk *adc_clk;
+ struct regulator *reg;
+ u16 *buf;
+
+ struct mutex lock;
+ unsigned long channel_map;
+ unsigned int start_delay_ns;
+ unsigned int eoc_delay_ns;
+};
+
+static inline void cc10001_adc_write_reg(struct cc10001_adc_device *adc_dev,
+u32 reg, u32 val)
+{
+ writel(val, adc_dev->reg_base + reg);
+}
+
+static inline u32 cc10001_adc_read_reg(struct cc10001_adc_device *adc_dev,
+ u32 reg)
+{
+ return readl(adc_dev->reg_base + reg);
+}
+
+static void cc10001_adc_start(struct cc10001_adc_device *adc_dev,
+ unsigned int channel)
+{
+ u32 val;
+
+ /* Channel selection and mode of operation */
+ val = (channel & CC10001_ADC_CH_MASK) | CC10001_ADC_MODE_SINGLE_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+
+ val = cc10001_adc_read_reg(adc_dev, CC10001_ADC_CONFIG);
+ val = val | CC10001_ADC_START_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+}
+
+static u16 cc10001_adc_poll_done(struct iio_dev *indio_dev,
+unsigned int channel,
+unsigned int delay)
+{
+ struct cc10001_adc_device *adc_dev = iio
[PATCH v6 2/3] DT: iio: adc: Add CC_10001 binding documentation
From: Phani Movva
Add the devicetree binding document for Cosmic Circuits 10001 ADC device.
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
[Ezequiel: minor style cleaning]
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
new file mode 100644
index 000..b7ba558
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
@@ -0,0 +1,22 @@
+* Cosmic Circuits - Analog to Digital Converter (CC-10001-ADC)
+
+Required properties:
+ - compatible: Should be "cosmic,10001-adc"
+ - reg: Should contain adc registers location and length.
+ - clock-names: Should contain "adc".
+ - clocks: Should contain a clock specifier for each entry in clock-names
+ - vref-supply: The regulator supply ADC reference voltage.
+
+Optional properties:
+ - cosmic,adc-reserved-channels: Bitmask of reserved channels,
+i.e. channels that cannot be used by the OS.
+
+Example:
+adc: adc@18101600 {
+ compatible = "cosmic,10001-adc";
+ reg = <0x18101600 0x24>;
+ cosmic,adc-reserved-channels = <0x2>;
+ clocks = <&adc_clk>;
+ clock-names = "adc";
+ vref-supply = <®_1v8>;
+};
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/3] iio: Add Cosmic Circuits ADC support
This series add the support for an ADC IP block from Cosmic Circuits. The patchset is based on v3.19-rc3. Rob/Mark: Jonathan has asked for an ack of the devicetree binding. Do you think you can take a look to that? Thanks a lot! -- Changes from v5: * Fixed CC10001_ADC_CH_MASK macro definition, to separate the channel number from the channel map, as noted by Hartmut. * Return the real error code in devm_regulator_get failure. Changes from v4: * Added a compile-time dependency on REGULATOR and HAVE_CLK. * Replaced the silly XOR operation for a proper mask out of the available channels. Changes from v3: * Fixed a few style nitpicks as per Hartmut's feedback. * Used GENMASK() to build the channel mask, which fixes a very nasty bug. Also found by Hartmut. Changes from v2: * Changed a devicetree property from adc-available-channels to adc-reserved-channels, so it can be made optional. * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's consistent with the rest of the kernel style. * Some more minor cosmetic fixes. Changes from v1: * Removed unneeded header includes. * Changed all the names and macros prefix: s/CC_10001_/CC10001_. * Used .update_scan_mode callback to preallocate the buffer. * Used indio_dev for the struct iio_dev. * Only read the regulator voltage when needed. * Fixed probe() error handling. * Used for_each_set_bit() instead of open-coding it. * Name the power-down register as _POWER_UP, to make the code less silly. * Error out when no valid sample can be read (i.e. when end-of-conversion poll times out). * ... plus some assorted code cleaning based on the feedback. Ezequiel Garcia (1): DT: Add a vendor prefix for Cosmic Circuits Phani Movva (2): iio: adc: Cosmic Circuits 10001 ADC driver DT: iio: adc: Add CC_10001 binding documentation .../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/cc10001_adc.c | 424 + 5 files changed, 459 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt create mode 100644 drivers/iio/adc/cc10001_adc.c -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/2] DT: watchdog: Add ImgTec PDC Watchdog Timer binding documentation
From: Naidu Tellapati
Add the devicetree binding document for ImgTec PDC Watchdog Timer.
Reviewed-by: Andrew Bresticker
Signed-off-by: Naidu Tellapati
Signed-off-by: Jude Abraham
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/watchdog/imgpdc-wdt.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
b/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
new file mode 100644
index 000..b2fa11f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt
@@ -0,0 +1,19 @@
+*ImgTec PowerDown Controller (PDC) Watchdog Timer (WDT)
+
+Required properties:
+- compatible : Should be "img,pdc-wdt"
+- reg : Should contain WDT registers location and length
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Should contain "wdt" and "sys"; the watchdog counter
+ clock and register interface clock respectively.
+- interrupts : Should contain WDT interrupt
+
+Examples:
+
+watchdog@18102100 {
+ compatible = "img,pdc-wdt";
+ reg = <0x18102100 0x100>;
+ clocks = <&pdc_wdt_clk>, <&sys_clk>;
+ clock-names = "wdt", "sys";
+ interrupts = <0 52 IRQ_TYPE_LEVEL_HIGH>;
+};
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/2] watchdog: ImgTec PDC Watchdog Timer Driver
From: Naidu Tellapati
This commit adds support for ImgTec PowerDown Controller Watchdog Timer.
Reviewed-by: Andrew Bresticker
Signed-off-by: Naidu Tellapati
Signed-off-by: Jude Abraham
[ezequiel: Minor style fixes]
Signed-off-by: Ezequiel Garcia
---
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imgpdc_wdt.c | 289 ++
3 files changed, 301 insertions(+)
create mode 100644 drivers/watchdog/imgpdc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 08f41ad..0a1396b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1235,6 +1235,17 @@ config BCM_KONA_WDT_DEBUG
If in doubt, say 'N'.
+config IMGPDC_WDT
+ tristate "Imagination Technologies PDC Watchdog Timer"
+ depends on HAS_IOMEM
+ depends on METAG || MIPS || COMPILE_TEST
+ help
+ Driver for Imagination Technologies PowerDown Controller
+ Watchdog Timer.
+
+ To compile this driver as a loadable module, choose M here.
+ The module will be called imgpdc_wdt.
+
config LANTIQ_WDT
tristate "Lantiq SoC watchdog"
depends on LANTIQ
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index c569ec8..d4dfbb4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_OCTEON_WDT) += octeon-wdt.o
octeon-wdt-y := octeon-wdt-main.o octeon-wdt-nmi.o
obj-$(CONFIG_LANTIQ_WDT) += lantiq_wdt.o
obj-$(CONFIG_RALINK_WDT) += rt2880_wdt.o
+obj-$(CONFIG_IMGPDC_WDT) += imgpdc_wdt.o
# PARISC Architecture
diff --git a/drivers/watchdog/imgpdc_wdt.c b/drivers/watchdog/imgpdc_wdt.c
new file mode 100644
index 000..c8def68
--- /dev/null
+++ b/drivers/watchdog/imgpdc_wdt.c
@@ -0,0 +1,289 @@
+/*
+ * Imagination Technologies PowerDown Controller Watchdog Timer.
+ *
+ * Copyright (c) 2014 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ * Based on drivers/watchdog/sunxi_wdt.c Copyright (c) 2013 Carlo Caione
+ * 2012 Henrik Nordstrom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* registers */
+#define PDC_WDT_SOFT_RESET 0x00
+#define PDC_WDT_CONFIG 0x04
+ #define PDC_WDT_CONFIG_ENABLEBIT(31)
+ #define PDC_WDT_CONFIG_DELAY_MASK0x1f
+
+#define PDC_WDT_TICKLE10x08
+#define PDC_WDT_TICKLE1_MAGIC 0xabcd1234
+#define PDC_WDT_TICKLE20x0c
+#define PDC_WDT_TICKLE2_MAGIC 0x4321dcba
+
+#define PDC_WDT_TICKLE_STATUS_MASK 0x7
+#define PDC_WDT_TICKLE_STATUS_SHIFT0
+#define PDC_WDT_TICKLE_STATUS_HRESET 0x0 /* Hard reset */
+#define PDC_WDT_TICKLE_STATUS_TIMEOUT 0x1 /* Timeout */
+#define PDC_WDT_TICKLE_STATUS_TICKLE 0x2 /* Tickled incorrectly */
+#define PDC_WDT_TICKLE_STATUS_SRESET 0x3 /* Soft reset */
+#define PDC_WDT_TICKLE_STATUS_USER 0x4 /* User reset */
+
+/* Timeout values are in seconds */
+#define PDC_WDT_MIN_TIMEOUT1
+#define PDC_WDT_DEF_TIMEOUT64
+
+static int heartbeat;
+module_param(heartbeat, int, 0);
+MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. "
+ "(default = " __MODULE_STRING(PDC_WDT_DEF_TIMEOUT) ")");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+ "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct pdc_wdt_dev {
+ struct watchdog_device wdt_dev;
+ struct clk *wdt_clk;
+ struct clk *sys_clk;
+ void __iomem *base;
+};
+
+static int pdc_wdt_keepalive(struct watchdog_device *wdt_dev)
+{
+ struct pdc_wdt_dev *wdt = watchdog_get_drvdata(wdt_dev);
+
+ writel(PDC_WDT_TICKLE1_MAGIC, wdt->base + PDC_WDT_TICKLE1);
+ writel(PDC_WDT_TICKLE2_MAGIC, wdt->base + PDC_WDT_TICKLE2);
+
+ return 0;
+}
+
+static int pdc_wdt_stop(struct watchdog_device *wdt_dev)
+{
+ unsigned int val;
+ struct pdc_wdt_dev *wdt = watchdog_get_drvdata(wdt_dev);
+
+ val = readl(wdt->base + PDC_WDT_CONFIG);
+ val &= ~PDC_WDT_CONFIG_ENABLE;
+ writel(val, wdt->base + PDC_WDT_CONFIG);
+
+ /* Must tickle to finish the stop */
+ pdc_wdt_keepalive(wdt_dev);
+
+ return 0;
+}
+
+static int pdc_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int new_timeout)
+{
+ unsigned int val;
+ struct pdc_wdt_dev *wdt = watchdog_get_drvdata(wdt_dev);
+ unsigned long clk_rate = clk_get_rate(wdt->wdt_clk);
+
+ wdt-&
[PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver
Here's the seventh round for IMG PDC Watchdog driver. The series is based on v3.19-rc3. Thanks! Changes from v6: * Reworked set_timeout function to get rid of the min_delay field. * Addressed a few comments made by Guenter Roeck. * Added a description of the clocks to the devicetree binding doc. Changes from v5: * Removed unused struct pdc_wdt_dev variables. * Removed out_wdt label in probe function. Changes from v4: * Added warning message if initial timeout value exceeds maximum timeout. Changes from v3: * Removed PDC_WD_MAX_DELAY. * Removed spinlock. * Removed timeout check inside pdc_wdt_set_timeout function. * Changed identity to IMG PDC Watchdog. * Removed pdc_wdt_set_timeout call from the probe function. * Removed pdc_wdt_shutdown function call from pdc_wdt_remove function and added pdc_wdt_stop function call instead. Changes from v2: * Removed interrupt.h header file. Changes from v1: * Arranged all include files in alphabetical order. * Arranged register field masks/shifts defines next to their corresponding register * Registered clock rate-change notifier callback. * Removed all references to 32 kHz fixed clock rate. Now the clock rate is read dynamically using clk_get_rate(). * Defined a macro PDC_WD_CONFIG_ENABLE. * Added code for getting system clock. * Moved module_param stuffs next to the corresponding variable defines. * Added code in the function pdc_wdt_remove for stopping watchdog. * Removed MODULE_ALIAS. * Removed few unwanted spaces and unwanted blank lines. Naidu Tellapati (2): watchdog: ImgTec PDC Watchdog Timer Driver DT: watchdog: Add ImgTec PDC Watchdog Timer binding documentation .../devicetree/bindings/watchdog/imgpdc-wdt.txt| 19 ++ drivers/watchdog/Kconfig | 11 + drivers/watchdog/Makefile | 1 + drivers/watchdog/imgpdc_wdt.c | 289 + 4 files changed, 320 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/imgpdc-wdt.txt create mode 100644 drivers/watchdog/imgpdc_wdt.c -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
Hi Hartmut,
On 12/10/2014 08:43 PM, Hartmut Knaack wrote:
> Ezequiel Garcia schrieb am 27.11.2014 um 16:39:
>> From: Phani Movva
>>
>> This commit adds support for Cosmic Circuits 10001 10-bit ADC device.
> Still some issues left, unfortunately things I pointed out in my last review.
Ouch, sorry about that.
[..]
>> +
>> +#define CC10001_ADC_DATA_MASK GENMASK(9, 0)
>> +#define CC10001_ADC_NUM_CHANNELS8
>> +#define CC10001_ADC_CH_MASK GENMASK(CC10001_ADC_NUM_CHANNELS - 1, 0)
> This is only valid for one of the cases you make (wrong) use of
> CC10001_ADC_CH_MASK.
> As you seem to use this mask to separate channel selection values (0 - 7) in
> register
> CC10001_ADC_CONFIG, a GENMASK(2, 0) would be appropriate.
> In case of the indio_dev->channel_mask, you would actually need this
> GENMASK(CC10001_ADC_NUM_CHANNELS - 1, 0).
Right.
[..]
>> +static int cc10001_adc_probe(struct platform_device *pdev)
>> +{
>> +struct device_node *node = pdev->dev.of_node;
>> +struct cc10001_adc_device *adc_dev;
>> +unsigned long adc_clk_rate;
>> +struct resource *res;
>> +struct iio_dev *indio_dev;
>> +int ret;
>> +
>> +indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*adc_dev));
>> +if (indio_dev == NULL)
>> +return -ENOMEM;
>> +
>> +adc_dev = iio_priv(indio_dev);
>> +
>> +adc_dev->channel_map = CC10001_ADC_CH_MASK;
> So, here you need a GENMASK(CC10001_ADC_NUM_CHANNELS - 1, 0).
Right.
>> +if (!of_property_read_u32(node, "cosmic,reserved-adc-channels", &ret))
>> +adc_dev->channel_map &= ~ret;
>> +
>> +adc_dev->reg = devm_regulator_get(&pdev->dev, "vref");
>> +if (IS_ERR(adc_dev->reg))
>> +return -EINVAL;
> Preferably pass up the real error code with PTR_ERR(adc_dev->reg).
OK.
Thanks for all your reviews!
--
Ezequiel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] iio: Add Cosmic Circuits ADC support
On 12/05/2014 10:25 AM, Jonathan Cameron wrote: > On 05/12/14 13:12, Jonathan Cameron wrote: >> >> >> On December 5, 2014 11:55:40 AM GMT+00:00, Ezequiel Garcia >> wrote: >>> Hi Jonathan, >>> >>> On 11/27/2014 12:39 PM, Ezequiel Garcia wrote: >>>> Changes from v4: >>>> >>>> * Added a compile-time dependency on REGULATOR and HAVE_CLK. >>>> >>>> * Replaced the silly XOR operation for a proper mask out of the >>>> available channels. >>>> >>>> Changes from v3: >>>> >>>> * Fixed a few style nitpicks as per Hartmut's feedback. >>>> >>>> * Used GENMASK() to build the channel mask, which fixes a very >>> nasty >>>> bug. Also found by Hartmut. >>>> >>>> Changes from v2: >>>> >>>> * Changed a devicetree property from adc-available-channels to >>>> adc-reserved-channels, so it can be made optional. >>>> >>>> * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's >>> consistent >>>> with the rest of the kernel style. >>>> >>>> * Some more minor cosmetic fixes. >>>> >>>> Changes from v1: >>>> >>>> * Removed unneeded header includes. >>>> >>>> * Changed all the names and macros prefix: s/CC_10001_/CC10001_. >>>> >>>> * Used .update_scan_mode callback to preallocate the buffer. >>>> >>>> * Used indio_dev for the struct iio_dev. >>>> >>>> * Only read the regulator voltage when needed. >>>> >>>> * Fixed probe() error handling. >>>> >>>> * Used for_each_set_bit() instead of open-coding it. >>>> >>>> * Name the power-down register as _POWER_UP, to make the code >>>> less silly. >>>> >>>> * Error out when no valid sample can be read (i.e. when >>> end-of-conversion >>>> poll times out). >>>> >>>> * ... plus some assorted code cleaning based on the feedback. >>>> >>>> >>>> Ezequiel Garcia (1): >>>> DT: Add a vendor prefix for Cosmic Circuits >>>> >>>> Phani Movva (2): >>>> iio: adc: Cosmic Circuits 10001 ADC driver >>>> DT: iio: adc: Add CC_10001 binding documentation >>>> >>> >>> Unless there are any outstanding issues with this series, it'd be great >>> to merge it for v3.19. >>> >>> Thanks! >> Sorry too late unfortunately. Merge window opens on Sunday and stuff needs >> to have >> been in Greg KH's tree for a week before that. Going to be 3.20 now. >> Oh, shoot. I was hoping to be in time for the merge. Being a new driver there wasn't much harm in taking it earlier. > Also, the DT patch could really do with an Ack from Rob. If Hartmut/Lars > want to give a reviewed-by that would be good given they done the legwork > on reviewing your driver. > > Looks good to me btw. Just taken a quick look, but little gets past those > guys anyway :) > If at all possible, do you think you area able to pick the patches now (but you don't include them in your pull request to Linus) so they are linux-next? It'd be good to know they start getting build-test coverage soon. Thanks! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] iio: Add Cosmic Circuits ADC support
Hi Jonathan, On 11/27/2014 12:39 PM, Ezequiel Garcia wrote: > Changes from v4: > > * Added a compile-time dependency on REGULATOR and HAVE_CLK. > > * Replaced the silly XOR operation for a proper mask out of the > available channels. > > Changes from v3: > > * Fixed a few style nitpicks as per Hartmut's feedback. > > * Used GENMASK() to build the channel mask, which fixes a very nasty > bug. Also found by Hartmut. > > Changes from v2: > > * Changed a devicetree property from adc-available-channels to > adc-reserved-channels, so it can be made optional. > > * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's consistent > with the rest of the kernel style. > > * Some more minor cosmetic fixes. > > Changes from v1: > > * Removed unneeded header includes. > > * Changed all the names and macros prefix: s/CC_10001_/CC10001_. > > * Used .update_scan_mode callback to preallocate the buffer. > > * Used indio_dev for the struct iio_dev. > > * Only read the regulator voltage when needed. > > * Fixed probe() error handling. > > * Used for_each_set_bit() instead of open-coding it. > > * Name the power-down register as _POWER_UP, to make the code > less silly. > > * Error out when no valid sample can be read (i.e. when end-of-conversion > poll times out). > > * ... plus some assorted code cleaning based on the feedback. > > > Ezequiel Garcia (1): > DT: Add a vendor prefix for Cosmic Circuits > > Phani Movva (2): > iio: adc: Cosmic Circuits 10001 ADC driver > DT: iio: adc: Add CC_10001 binding documentation > Unless there are any outstanding issues with this series, it'd be great to merge it for v3.19. Thanks! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v6 0/2] watchdog: Add support for ImgTec PowerDown Controller Watchdog Timer
Wim, On 11/27/2014 01:54 AM, Naidu Tellapati wrote: > This patchset provides support for the PowerDown Controller (PDC) Watchdog > Timer > found on Pistachio SOC from Imagination Technologies (ImgTec). > > The series is based on 3.18-rc5. > > I am re-sending the series with correct Signed-off-by headers. > > Changes from v5: > > * Removed unused struct pdc_wdt_dev variables. > > * Removed out_wdt label in probe function. > > Changes from v4: > > * Added warning message if initial timeout value exceeds maximum timeout. > > Changes from v3: > > * Removed PDC_WD_MAX_DELAY. > > * Removed spinlock. > > * Removed timeout check inside pdc_wdt_set_timeout function. > > * Changed identity to IMG PDC Watchdog. > > * Removed pdc_wdt_set_timeout call from the probe function. > > * Removed pdc_wdt_shutdown function call from pdc_wdt_remove function >and added pdc_wdt_stop function call instead. > > Changes from v2: > > * Removed interrupt.h header file. > > * Removed clock rate-change notifier callback. > > Changes from v1: > > * Arranged all include files in alphabetical order. > > * Arranged register field masks/shifts defines next to their >corresponding register > > * Registered clock rate-change notifier callback. > > * Removed all references to 32 kHz fixed clock rate. >Now the clock rate is read dynamically using clk_get_rate(). > > * Defined a macro PDC_WD_CONFIG_ENABLE. > > * Added code for getting system clock. > > * Moved module_param stuffs next to the corresponding variable defines. > > * Added code in the function pdc_wdt_remove for stopping watchdog. > > * Removed MODULE_ALIAS. > > * Removed few unwanted spaces and unwanted blank lines. > > Naidu Tellapati (2): > watchdog: ImgTec PDC Watchdog Timer Driver > DT: watchdog: Add ImgTec PDC Watchdog Timer binding documentation > Do you think it's possible to merge this series in time for v3.19? Thanks! -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/4] Initial support for ImgTec PWM DAC and PDM DAC
Hi Thierry, On 11/28/2014 03:12 PM, Naidu Tellapati wrote: > The Pistachio SOC from Imagination Technologies includes – 4x PDM blocks > and 1x “basic PWM� block with four output channels. These share 4 MFIO > pins, > each PWM channel being muxed with each PDM block output (0-3 muxed with 0-3) > using the CR_PERIP_PWM_PDM_CONTROL register in the peripheral wrapper > register bank (offset 0x140). The PDM and PWM outputs are used to control > targets such as LCD backlight. > > The PWM driver uses Linux PWM framework. Since the PDM does not fit into PWM > framework we have implemented it as a MISC driver. > > The series is based on v3.18-rc5. > > Changes from v5: > > * Used syscon for accessing PWM & PDM control register. > > Changes from v4: > > * Removed CR_prefix from the defined macros. > > * Folded same data type varibles in one line. > > * Removed cr-periph property from PWM DT binding document. > > * Removed regmap_update_bits from img_pwm_enable and img_pwm_disable > functions. > > * Addressed few more comments given in v4. > > Changes from v3: > > * Addressed couple of comments given in v3. > > Changes from v2: > > * Added depends on MIPS || COMPILE_TEST. > > * Corrected the logic while calculating time base steps. > > * Addressed few other minor comments given in v2. > > Changes from v1: > > * Used regmap_update_bits at some places in the driver. > > * Placed some #defines next to their register. > > * Added depends on HAS_IOMEM in Kconfig. > > * Removed unnecessary paragraph from file header. > > * Defined register masks in a readable way. > > * Renamed clk-names with clock-names. > > * Added system interface clock in DT binding document. > > * Addressed few other minor review comments given in v1. > > Naidu Tellapati (4): > pwm: Imagination Technologies PWM DAC driver > DT: pwm: Add binding document for IMG PWM DAC > pdm: Imagination Technologies PDM DAC driver > DT: pdm: Add binding document for IMG PDM DAC > Any comments on this series? I was aiming at merging this for v3.19, hope it's not too late already! Thanks, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] DT: Add a vendor prefix for Cosmic Circuits
Acked-by: Rob Herring Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..1bfa13a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -35,6 +35,7 @@ chrp Common Hardware Reference Platform chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. cortinaCortina Systems, Inc. +cosmic Cosmic Circuits crystalfontz Crystalfontz America, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] DT: iio: adc: Add CC_10001 binding documentation
From: Phani Movva
Add the devicetree binding document for Cosmic Circuits 10001 ADC device.
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
[Ezequiel: minor style cleaning]
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
new file mode 100644
index 000..b7ba558
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt
@@ -0,0 +1,22 @@
+* Cosmic Circuits - Analog to Digital Converter (CC-10001-ADC)
+
+Required properties:
+ - compatible: Should be "cosmic,10001-adc"
+ - reg: Should contain adc registers location and length.
+ - clock-names: Should contain "adc".
+ - clocks: Should contain a clock specifier for each entry in clock-names
+ - vref-supply: The regulator supply ADC reference voltage.
+
+Optional properties:
+ - cosmic,adc-reserved-channels: Bitmask of reserved channels,
+i.e. channels that cannot be used by the OS.
+
+Example:
+adc: adc@18101600 {
+ compatible = "cosmic,10001-adc";
+ reg = <0x18101600 0x24>;
+ cosmic,adc-reserved-channels = <0x2>;
+ clocks = <&adc_clk>;
+ clock-names = "adc";
+ vref-supply = <®_1v8>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] iio: Add Cosmic Circuits ADC support
Changes from v4: * Added a compile-time dependency on REGULATOR and HAVE_CLK. * Replaced the silly XOR operation for a proper mask out of the available channels. Changes from v3: * Fixed a few style nitpicks as per Hartmut's feedback. * Used GENMASK() to build the channel mask, which fixes a very nasty bug. Also found by Hartmut. Changes from v2: * Changed a devicetree property from adc-available-channels to adc-reserved-channels, so it can be made optional. * Renamed the driver from cc_10001_xxx to cc10001_xxx so it's consistent with the rest of the kernel style. * Some more minor cosmetic fixes. Changes from v1: * Removed unneeded header includes. * Changed all the names and macros prefix: s/CC_10001_/CC10001_. * Used .update_scan_mode callback to preallocate the buffer. * Used indio_dev for the struct iio_dev. * Only read the regulator voltage when needed. * Fixed probe() error handling. * Used for_each_set_bit() instead of open-coding it. * Name the power-down register as _POWER_UP, to make the code less silly. * Error out when no valid sample can be read (i.e. when end-of-conversion poll times out). * ... plus some assorted code cleaning based on the feedback. Ezequiel Garcia (1): DT: Add a vendor prefix for Cosmic Circuits Phani Movva (2): iio: adc: Cosmic Circuits 10001 ADC driver DT: iio: adc: Add CC_10001 binding documentation .../devicetree/bindings/iio/adc/cc10001_adc.txt| 22 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/adc/Kconfig| 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/cc10001_adc.c | 424 + 5 files changed, 459 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/cc10001_adc.txt create mode 100644 drivers/iio/adc/cc10001_adc.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
From: Phani Movva
This commit adds support for Cosmic Circuits 10001 10-bit ADC device.
Signed-off-by: Phani Movva
Signed-off-by: Naidu Tellapati
[Ezequiel: code style cleaning]
Signed-off-by: Ezequiel Garcia
---
drivers/iio/adc/Kconfig | 11 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/cc10001_adc.c | 424 ++
3 files changed, 436 insertions(+)
create mode 100644 drivers/iio/adc/cc10001_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 88bdc8f..15bb1ae 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -127,6 +127,17 @@ config AT91_ADC
help
Say yes here to build support for Atmel AT91 ADC.
+config CC10001_ADC
+ tristate "Cosmic Circuits 10001 ADC driver"
+ depends on HAS_IOMEM || HAVE_CLK || REGULATOR
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Cosmic Circuits 10001 ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called cc10001_adc.
+
config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF &&
COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index cb88a6a..9286c59 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_AD7793) += ad7793.o
obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
diff --git a/drivers/iio/adc/cc10001_adc.c b/drivers/iio/adc/cc10001_adc.c
new file mode 100644
index 000..a079ee0
--- /dev/null
+++ b/drivers/iio/adc/cc10001_adc.c
@@ -0,0 +1,424 @@
+/*
+ * Copyright (c) 2014 Imagination Technologies Ltd.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Registers */
+#define CC10001_ADC_CONFIG 0x00
+#define CC10001_ADC_START_CONV BIT(4)
+#define CC10001_ADC_MODE_SINGLE_CONV BIT(5)
+
+#define CC10001_ADC_DDATA_OUT 0x04
+#define CC10001_ADC_EOC0x08
+#define CC10001_ADC_EOC_SETBIT(0)
+
+#define CC10001_ADC_CHSEL_SAMPLED 0x0c
+#define CC10001_ADC_POWER_UP 0x10
+#define CC10001_ADC_POWER_UP_SET BIT(0)
+#define CC10001_ADC_DEBUG 0x14
+#define CC10001_ADC_DATA_COUNT 0x20
+
+#define CC10001_ADC_DATA_MASK GENMASK(9, 0)
+#define CC10001_ADC_NUM_CHANNELS 8
+#define CC10001_ADC_CH_MASKGENMASK(CC10001_ADC_NUM_CHANNELS - 1, 0)
+
+#define CC10001_INVALID_SAMPLED0x
+#define CC10001_MAX_POLL_COUNT 20
+
+/*
+ * As per device specification, wait six clock cycles after power-up to
+ * activate START. Since adding two more clock cycles delay does not
+ * impact the performance too much, we are adding two additional cycles delay
+ * intentionally here.
+ */
+#defineCC10001_WAIT_CYCLES 8
+
+struct cc10001_adc_device {
+ void __iomem *reg_base;
+ struct clk *adc_clk;
+ struct regulator *reg;
+ u16 *buf;
+
+ struct mutex lock;
+ unsigned long channel_map;
+ unsigned int start_delay_ns;
+ unsigned int eoc_delay_ns;
+};
+
+static inline void cc10001_adc_write_reg(struct cc10001_adc_device *adc_dev,
+u32 reg, u32 val)
+{
+ writel(val, adc_dev->reg_base + reg);
+}
+
+static inline u32 cc10001_adc_read_reg(struct cc10001_adc_device *adc_dev,
+ u32 reg)
+{
+ return readl(adc_dev->reg_base + reg);
+}
+
+static void cc10001_adc_start(struct cc10001_adc_device *adc_dev,
+ unsigned int channel)
+{
+ u32 val;
+
+ /* Channel selection and mode of operation */
+ val = (channel & CC10001_ADC_CH_MASK) | CC10001_ADC_MODE_SINGLE_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+
+ val = cc10001_adc_read_reg(adc_dev, CC10001_ADC_CONFIG);
+ val = val | CC10001_ADC_START_CONV;
+ cc10001_adc_write_reg(adc_dev, CC10001_ADC_CONFIG, val);
+}
+
+static u16 cc10001_adc_poll_done(struct iio_dev *indio_dev,
+unsigned int channel,
+unsigned int delay)
+{
+ struct cc10001_adc_device *adc_dev = iio_priv(indio_dev);
+ unsigned int poll_count = 0;
+
+
Re: [PATCH v3 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
On 11/27/2014 12:16 PM, Lars-Peter Clausen wrote: > [...] + +adc_dev->reg = devm_regulator_get(&pdev->dev, "vref"); +if (IS_ERR_OR_NULL(adc_dev->reg)) +return -EINVAL; >>> if (IS_ERR(adc_dev->reg)) >>> return PTR_ERR(adc_dev->reg); >> >> Are you sure? What if devm_regulator_get() returns NULL? >> > I had a look at it, but couldn't figure out a condition in which it > would return NULL. But I'd be happy to be informed of anything > different. If CONFIG_REGULATOR=n you get NULL there (although I added a select REGULATOR on the v4 I just posted). >>> Indeed, thanks. Now I'm thinking if it would make sense to handle >>> this special case in a special way (as it would be caused by an >>> invalid kernel config). Well, I guess, I leave it up to you. >> >> Well, adding the select REGULATOR that shouldn't happen, so let's better >> drop the NULL check entirely. > > Doing a 'select REGULATOR' can (and probably will sooner or later) > create nasty dependency loops. User selectable config items should not > be selected by another config item. If the driver really has a hard > dependency on the regulator framework then 'depends on REGULATOR' is the > right thing to do. > Fine, then. 'depends on REGULATOR' it is. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] iio: adc: Cosmic Circuits 10001 ADC driver
On 11/25/2014 07:53 PM, Hartmut Knaack wrote: > Ezequiel Garcia schrieb am 25.11.2014 23:03: >> >> >> On 11/25/2014 06:41 PM, Hartmut Knaack wrote: >>>> >>>> Unless I'm missing something, that's exactly what XOR does. >>>> >>>> Example: >>>> >>>> reserved_channels = 0x2; >>>> channel_map = 0x7 ^ reserved_channels -> 0x5 >>>> >>> You miss to check ret for a valid range, which you don't need to do when >>> masking out channels. >>> Example: >>> reserved_channels = 0x8; >>> channel_map = 0x7 ^ reserved_channels -> 0xf >>> And this is actually happening in the current revision (with the wrong >>> channel_map assignment), that a reserved channel in DT would become usable. >> >> Right, definitely a check is needed. > No, that's not needed when using AND, as it can not add bits in the channel > map. The following will do the job: > adc_dev->channel_map &= ~ret; Gah, of course, that's way much better. >> >>>>>> + >>>>>> +adc_dev->reg = devm_regulator_get(&pdev->dev, "vref"); >>>>>> +if (IS_ERR_OR_NULL(adc_dev->reg)) >>>>>> +return -EINVAL; >>>>> if (IS_ERR(adc_dev->reg)) >>>>> return PTR_ERR(adc_dev->reg); >>>> >>>> Are you sure? What if devm_regulator_get() returns NULL? >>>> >>> I had a look at it, but couldn't figure out a condition in which it would >>> return NULL. But I'd be happy to be informed of anything different. >> >> If CONFIG_REGULATOR=n you get NULL there (although I added a select REGULATOR >> on the v4 I just posted). >> > Indeed, thanks. Now I'm thinking if it would make sense to handle this > special case in a special way (as it would be caused by an invalid kernel > config). Well, I guess, I leave it up to you. Well, adding the select REGULATOR that shouldn't happen, so let's better drop the NULL check entirely. -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
