On 17 July 2013 19:36, wrote:
> 3. Added Acks from Viresh and Shawn
Add it for the new cpufreq drivers included in this patchset too..
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-
On 17 July 2013 20:13, Andrew Lunn wrote:
> Are we not going a bit backwards here? You are replacing two lines
> with 10 lines.
>
> How about putting these 10 lines into some helper,
> of_get_cpu_device()? It would be useful for spear, kirkwood and
> imx6q, and maybe others.
+1
_
arch/arm/boot/dts/spear1310.dtsi | 1 -
> arch/arm/boot/dts/spear1340.dtsi | 1 -
> arch/arm/boot/dts/spear310.dtsi | 1 -
> arch/arm/boot/dts/spear320.dtsi | 2 --
> 4 files changed, 5 deletions(-)
Acked-by: Viresh Kumar
___
devicetree-
sk, filter,
> pdata->write_dma_priv);
> if (!host->write_dma_chan) {
> + ret = -ENODEV;
> dev_err(&pdev->dev, "Unable to get write dma
> channel\n");
> goto err
On 13 May 2013 12:25, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENODEV in the dma channel request error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/mtd/nand/fsmc_nand.c | 1 +
> 1 file changed, 1 insertion(+)
>
tsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Viresh Kumar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
elow function dt_get_transition_latency() too.
Thanks Francesco.
Below fixes this (I will send it separately to Rafael):
Subject: [PATCH 1/2] cpufreq: ARM big LITTLE: put DT nodes after using them
DT nodes should be put using of_node_put() to balance their usage counts. This
i
On 26 March 2013 18:47, Rob Herring wrote:
> On 03/26/2013 04:51 AM, Viresh Kumar wrote:
> I fail to see anything bL specific here. This is just multi-cluster, but
> even for that I don't see anything new other than simply allowing per
> cpu or per cluster opp's. The fact th
This patch adds in a generic glue driver which would extract information from
Device Tree.
Future SoC's can either reuse the DT glue or write their own depending on the
need.
Signed-off-by: Sudeep KarkadaNagesha
Signed-off-by: Viresh Kumar
---
V1->V2:
- It was reviewed here earlier: htt
On 22 March 2013 05:20, Rafael J. Wysocki wrote:
> Please post a complete update patch if you want me to take it. I'd also would
> like it to be ACKed by someone involved in the big-LITTLE work on the arch
> side.
Okay.
___
devicetree-discuss mailing l
anth Menon
> ---
> MAINTAINERS|1 -
> drivers/cpufreq/Kconfig.arm|6 -
> drivers/cpufreq/Makefile |1 -
> drivers/cpufreq/omap-cpufreq.c | 291
>
> 4 files changed, 299 deletions(
On 10 March 2013 23:58, Francesco Lavra wrote:
> On 03/07/2013 06:14 PM, Viresh Kumar wrote:
>> +void bL_cpufreq_unregister(struct cpufreq_arm_bL_ops *ops)
>> +{
>> + if (arm_bL_ops != ops) {
>> + pr_info("%s: Registered with:
On 8 March 2013 14:11, Guennadi Liakhovetski wrote:
> Also in your driver you're doing
>
> cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> ...
> cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
>
> So, theoretically you could install su
On 8 March 2013 05:56, Guennadi Liakhovetski wrote:
> I like generic drivers :)
Me too :)
> cpufreq-cpu0 is yet another such generic
> (cpufreq) driver. Now, comparing the functionality of the two:
Great!!
> we see, that this driver "only" switches CPU clock frequencies. Whereas
> the cpufreq-
This patch adds in a generic glue driver which would extract information from
Device Tree.
Future SoC's can either reuse the DT glue or write their own depending on the
need.
Signed-off-by: Sudeep KarkadaNagesha
Signed-off-by: Viresh Kumar
---
V1->V2:
- s/IS_ERR_OR_NULL/IS_ERR for retur
ve now updated my earlier patch
> based on the feedback and rebased on your tree without any
> of the arm-soc patches mixed in.
Acked-by: Viresh Kumar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.
On 15 February 2013 23:51, Arnd Bergmann wrote:
> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
> b/Documentation/devicetree/bindings/dma/snps-dma.txt
> +- #dma-cells: must be <3>
> +DMA clients connected to the Designware DMA controller must use the format
> +described in the
On 30 January 2013 15:38, Arnd Bergmann wrote:
> I meant the spear13xx data sheet, which has to list the request lines
> for its integrated components. There may be other SoCs using the
> same dw_dmac, but this is the main one that is upstream now, and it's
> probably as good as any other one. I j
On Wed, Jan 30, 2013 at 3:11 PM, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Viresh Kumar wrote:
>> I knew you will come to this :)
>> So, the hardware is like: there are 16 request line slots per master, a
>> platform can choose to connect same or separate devic
On 29 January 2013 21:51, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Viresh Kumar wrote:
>> On 29 January 2013 19:01, Arnd Bergmann wrote:
>> > Ah, good. So I guess the "dma-requests" property should actually
>> > be "16" then.
&g
On 29 January 2013 19:01, Arnd Bergmann wrote:
> Ah, good. So I guess the "dma-requests" property should actually
> be "16" then.
yes, even i was checking on that separately :)
> Does this mean that an implicit zero request line means memory?
No. 0 is also request line for a peripheral and numb
On 29 January 2013 16:24, Andy Shevchenko
wrote:
> On Tue, 2013-01-29 at 16:19 +0530, Viresh Kumar wrote:
>> if (DMA_TO_DEV)
>>// dest is periph
>>fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
>> else if (DEV_TO_DMA)
>>
On 29 January 2013 16:05, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Viresh Kumar wrote:
>> Shouldn't this be 4? Would be better to mention what fields are these,
>> right here. I have seen them below though.
>
> Correct. I changed these a couple of times
s use the generic DMA binding to find the DMA channel.
>
> The patch is untested so far and is part of a series to convert
> the spear platform over to use the generic DMA binding, so it
> should stay with the rest of the series.
Acked-by: Viresh Kumar
_
You forgot spear-devel for this series.
On 29 January 2013 03:28, Arnd Bergmann wrote:
> This replaces an earlier patch from Viresh Kumar to move
> the spear platform over to the generic DMA binding. This
> version is now based on the merged multiplatform capable
> spear platform,
On 29 January 2013 03:28, Arnd Bergmann wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This i
On 12 December 2012 14:10, Andy Shevchenko
wrote:
> Will we survive if the patch is in mainline? I mean how big the impact
> of it is?
It doesn't fail to do fulfill its purpose and even ALL DT stuff would work well.
Its just the matter of using the right API's, design and bindings :)
because of it.
Oops!! Here is a fix for that
Author: Viresh Kumar
Date: Wed Dec 12 08:28:07 2012 +0530
ARM: SPEAr1310: Fix CF DMA data
We need to pass string with device-channel name to dma controller
instead of dma
controller specific dma struct. Fix CF dma data.
Signed-off-by
Kumar Samar
Signed-off-by: Viresh Kumar
---
V6->V7:
- Minor grammer correction in stmpe.txt
- Removed comment over pdata->id = -1
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmpe.c | 22 --
2 files chang
On 6 December 2012 22:10, Lee Jones wrote:
> On Thu, 06 Dec 2012, Viresh Kumar wrote:
>> + pdata->id = -1;
>
> Perhaps PLATFORM_DEVID_AUTO would be better?
Why do we want to allocate device id's for it? Multiple devices
are already distinguished and so -1 would be
-by: Viresh Kumar
---
Hi Samuel,
I have added acked by Lee as he earlier Acked this patch, most of the part is
still the same. And nothing new added.
V5->V6:
- Removed of_devide_id tables from stmpe-i2c[spi].c
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmp
On 6 December 2012 16:42, Lee Jones wrote:
> I thought we'd be over this? The 'ID' will be represented by the
> address of the chip i.e. stmpe1601@40, where '40' will be
> distinguishing factor?
I haven't tested it but i thought we are getting i2c device name from
modalias() fn running on "st,stm
On 6 December 2012 16:05, Lee Jones wrote:
>> > Or you could not put unnecessary bindings into the Device Tree
>> > by putting two and two together and realise that using the table
>> > is the correct thing to do instead. This actually gives reason
>> > to you previous patch, but should probably b
On 6 December 2012 15:41, Lee Jones wrote:
> So then I'm back to my original question, why?
>
> What is it used for? What difference does it make?
>
> I could understand if the .data attribute was used in the driver
> to make vital decisions based on STMPE version, but it's not. So
> why are we bu
On 6 December 2012 15:20, Lee Jones wrote:
>> > But regardless, it is the responsiblity of the probe function to go and
>> > look if of_driver_match_device() matches against anything if it cares
>> > about the of_match_table entries (for instance, if there is extra data
>> > attached).
>>
>> Ok, s
On 6 December 2012 04:12, Grant Likely wrote:
> On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar
> wrote:
>> This first tries to match the table my patch added, _BUT_ the string will
>> never match as we had "st,stmpe810" in table and "stmpe810" in dev
First of all, thanks for explaining :)
On 6 December 2012 04:12, Grant Likely wrote:
> On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar
> wrote:
>> This first tries to match the table my patch added, _BUT_ the string will
>> never match as we had "st,stmpe810" in
On 5 December 2012 18:49, Lee Jones wrote:
>> Ping!!!
>
> Documentation/development-process/2.Process:
>
> - Avoid top-posting (the practice of putting your answer above the quoted
> text you are responding to). It makes your response harder to read and
> makes a poor impression.
Yes, i know
Ping!!!
On 1 December 2012 00:33, Viresh Kumar wrote:
> On 30 November 2012 21:15, Lee Jones wrote:
>> But ... I don't see how the changes in the -i2c and -spi files
>> are of benefit either. When I boot without the ID table I still
>> get "stmpe-i2c 0-0040: stm
On 1 December 2012 22:17, Linus Walleij wrote:
> If you can, try to avoid this:
> Content-Type: text/plain; charset=WINDOWS-1252
> Content-Transfer-Encoding: quoted-printable
>
> That kind om message encoding makes my life a living hell
> (but I fixed it, manually editing the whole patch) how did
On 30 November 2012 21:15, Lee Jones wrote:
> But ... I don't see how the changes in the -i2c and -spi files
> are of benefit either. When I boot without the ID table I still
> get "stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212".
>
> What is it that actually uses the IDs?
>
> Perhaps Viresh
On Nov 30, 2012 6:50 PM, "Lee Jones" wrote:
>
> On Fri, 30 Nov 2012, Viresh Kumar wrote:
>
> > On 30 November 2012 18:15, Lee Jones wrote:
> > > The patch doesn't apply for me - does it for you?
> > >
> > > Viresh, what's it based on?
On 30 November 2012 18:15, Lee Jones wrote:
> The patch doesn't apply for me - does it for you?
>
> Viresh, what's it based on?
Because this was applied 2 days back by Samuel, and i didn't
fetch it again yesterday:
commit 20d5c7defc228cdaeff3ce3442f3a4e86af293c1
Author: Randy Dunlap
Date: Mon
Kumar Samar
Signed-off-by: Viresh Kumar
---
V4->V5:
--
- 2/3 and 3/3 merged.
- irq_trigger is kept same for non-DT booti.
@Lee: I haven't added your Acked-by, because this differs from your Acked
version.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stm
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Acked-by: Lee Jones
Signed-off-by: Viresh Kumar
---
Nothing changed from last version.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b
On 29 November 2012 15:04, Lee Jones wrote:
> On Thu, 29 Nov 2012, Viresh Kumar wrote:
>
>> STMPE can confige
>
> configure?
>
>> the way the device emits interrupts and till now this
>
> until?
Ahh... Wil
On 29 November 2012 14:53, Lee Jones wrote:
>> From: Vipul Kumar Samar
>> + /*
>> + * Distinct names of same cell-type within multiple instances of stmpe
>> + * will be guaranteed by DT.
>> + */
>> + pdata->id = -1;
>
> And what if we're not booting with DT?
Then it is res
Kumar Samar
Signed-off-by: Viresh Kumar
---
V3->V4:
- Remove need to pass irq type and polarity from DT.
- Remove need to pass id from platform data.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmpe-i2c.c | 15 +++
drivers/
: irqd_get_trigger_type() routine.
So, now we don't need to pass it via platform data. This is earlier discussed
here:
https://lkml.org/lkml/2012/11/26/711
Signed-off-by: Viresh Kumar
---
@Linus/Shiraz: Can you please test this patch? You don't really need to test 1/3
and 3/3, but would be g
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Signed-off-by: Viresh Kumar
---
This is actually V1 of this patch.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index
On 29 November 2012 00:05, Viresh Kumar wrote:
> Since the very first patch, stmpe core driver is using irq_invert_polarity as
> part of platform data. But, nobody is actually using it in kernel till now.
>
> Also, this is not something part of hardware specs, but is included to
Kumar Samar
Signed-off-by: Viresh Kumar
---
V3->V4:
- Remove need to pass irq type and polarity from DT.
- Remove need to pass id from platform data.
Documentation/devicetree/bindings/mfd/stmpe.txt | 9 ++---
drivers/mfd/stmpe-i2c.c | 15 +++
drivers/
: irqd_get_trigger_type() routine.
So, now we don't need to pass it via platform data. This is earlier discussed
here:
https://lkml.org/lkml/2012/11/26/711
Signed-off-by: Viresh Kumar
---
Linus/Shiraz: Can you please test this patch? You don't really need to test 1/3
and 3/3, but would be good
earlier discussed here:
https://lkml.org/lkml/2012/11/27/636
Signed-off-by: Viresh Kumar
---
This is actually V1 of this patch.
drivers/mfd/stmpe.c | 7 ---
include/linux/mfd/stmpe.h | 2 --
2 files changed, 9 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index
On 28 November 2012 01:25, Rabin Vincent wrote:
> 2012/11/27 Viresh Kumar :
>> On 27 November 2012 14:10, Lee Jones wrote:
>> I haven't seen this in any of SPEAr boards i have worked on. Maybe Rabin
>> would have, that's why he added that part of code :)
>>
Signed-off-by: Viresh Kumar
---
Hi Rafael,
To make review easier and faster, i am sending incremental patch for SPEAr
cpufreq driver. This patch was earlier discussed here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/135088.html
.../devicetree/bindings/cpufreq/cpufreq
On 27 November 2012 17:08, Rafael J. Wysocki wrote:
> On Tuesday, November 27, 2012 09:28:01 AM Viresh Kumar wrote:
>> On 27 November 2012 09:31, Shawn Guo wrote:
>> > On Sun, Nov 25, 2012 at 01:09:28AM +0530, Viresh Kumar wrote:
>> >> +cpufreq {
>> >
On 27 November 2012 14:54, Sudeep K N wrote:
> On Sat, Nov 24, 2012 at 7:39 PM, Viresh Kumar wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-spear.txt
>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-spear.txt
>> new file mode
On 27 November 2012 14:10, Lee Jones wrote:
> On Tue, 27 Nov 2012, Viresh Kumar wrote:
>> Problem is with invert polarity, which the interrupt controller is not aware
>> of.
>> For example, suppose interrupt controller needs Rising edge interrupt, but
>> the board ha
On 27 November 2012 10:46, Shawn Guo wrote:
> Shouldn't it also be handled by cpu clock provider?
Not really sure.
--
viresh
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Hi Shawn,
Thanks for feedback.
On 27 November 2012 09:31, Shawn Guo wrote:
> On Sun, Nov 25, 2012 at 01:09:28AM +0530, Viresh Kumar wrote:
>> +cpufreq {
>> + compatible = "st,cpufreq-spear";
>
> I do not think we need a "cpufreq" node, as we alr
On 27 November 2012 08:10, Viresh Kumar wrote:
> On 27 November 2012 00:10, Grant Likely wrote:
>> It would actually be good to ask the interrupt controller driver what
>> kind of interrupt signal it expects for a given interrupt line. That
>> should also solve the problem
On 27 November 2012 00:10, Grant Likely wrote:
> Ah, so it is configuring the way the device emits interrupts; not how
> the interrupt controller processes them. Fair enough.
Finally i am able to convince somebody that stmpe is different :)
> It would actually be good to ask the interrupt contro
On 26 November 2012 18:55, Lee Jones wrote:
> Why do you need to sort them? Is there _really_ a need?
Many people & maintainers like to have their header files ordered. The
reason for that is:
If they are not ordered, there is a possibility of adding an header file
multiple times in a file. Thi
From: Vipul Kumar Samar
This patch allows the STMPE GPIO driver to be successfully probed and
initialised when Device Tree support is enabled. Bindings are mentioned in
Documentation too.
Acked-by: Lee Jones
Signed-off-by: Vipul Kumar Samar
Signed-off-by: Viresh Kumar
---
V1->V2:
- Fi
ix warning
ARM: SPEAr1310: Move 1310 specific misc register into machine
specific files
ARM: SPEAr1310: Fix AUXDATA for compact flash controller
Viresh Kumar (1):
ARM: SPEAr3xx: Shirq: Move shirq controller out of plat/
.../devicetree/bindings/arm/spear/shirq.txt| 48 +
On 26 November 2012 16:56, Lee Jones wrote:
>> From: Vipul Kumar Samar
>> +Optional properties:
>> + - norequest-mask: bitmask specifying which GPIOs should _not_ be
>> requestable
>
> You have 'norequest-mask' here and 'st,norequest-mask' in the example.
> If 'st,norequest-mask' is truly requ
On 11 November 2012 10:09, Viresh Kumar wrote:
> From: Shiraz Hashim
>
> This patch adds multiple device nodes for SPEAr machines and boards.
>
> Signed-off-by: Bhavna Yadav
> Signed-off-by: Deepak Sikri
> Signed-off-by: Rajeev Kumar
> Signed-off-by: Shiraz Hashim
On 26 November 2012 16:46, Samuel Ortiz wrote:
> Hi Viresh,
>
> On Fri, Nov 23, 2012 at 12:26:18AM +0530, Viresh Kumar wrote:
>> This helps managing them better and also reduces chances of adding an header
>> file twice.
The aim is to maintain the list of header files in a
From: Deepak Sikri
SPEAr is an ARM based family of SoCs. This patch adds in support of cpufreq
driver for SPEAr SoCs. It is supported via DT only and so bindings are present
in binding document.
Signed-off-by: Deepak Sikri
Signed-off-by: Viresh Kumar
---
.../devicetree/bindings/cpufreq
On 23 November 2012 15:11, Grant Likely wrote:
> On Fri, 23 Nov 2012 00:26:20 +0530, Viresh Kumar
> wrote:
>> + - irq-trigger : IRQ trigger to use for the interrupt
>> to the host
>> + - irq-invert-polarity : bool, IRQ line is con
From: Vipul Kumar Samar
This patch allows the STMPE GPIO driver to be successfully probed and
initialised when Device Tree support is enabled. Bindings are mentioned in
Documentation too.
Signed-off-by: Vipul Kumar Samar
Signed-off-by: Viresh Kumar
---
V1->Resend:
--
- Don
On 23 November 2012 21:13, Lee Jones wrote:
> No, in DT devices named as part of the hiearchy, so you'd have:
>
> soc-u9500/i2c@80004000/stmpe1601@40/stmpe_keypad
> soc-u9500/i2c@80004000/stmpe1601@41/stmpe_keypad
> ... etc
Obviously. How could i miss this naming :(
Okay, so i need to pass -1 an
On 23 November 2012 15:06, Lee Jones wrote:
> On Fri, 23 Nov 2012, Viresh Kumar wrote:
>> pdev = platform_device_alloc(cell->name, id + cell->id);
>>
>> This is required when we have multiple instances of MFD device present
>> on board. How do you want me to
On 23 November 2012 17:44, Lee Jones wrote:
> I'm saying, just leave it where it is.
So you are suggesting this code:
stmpe_gpio->chip.base = pdata ? pdata->gpio_base : -1;
if (pdata)
stmpe_gpio->norequest_mask = pdata->norequest_mask;
else if (np)
On 23 November 2012 16:16, Lee Jones wrote:
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
>> @@ -0,0 +1,43 @@
>> +STMPE Touchscreen
>> +
>> +
>> +Required properties:
>> + - compatible: "st,stmpe-ts"
>
> You shouldn't be specifying a compatible string in th
On 23 November 2012 16:11, Lee Jones wrote:
>> > +++ b/Documentation/devicetree/bindings/gpio/gpio-stmpe.txt
>> > @@ -0,0 +1,18 @@
>> > +STMPE gpio
>> > +--
>> > +
>> > +Required properties:
>> > + - compatible: "st,stmpe-gpio"
>
> ... but this is wrong.
>
>> > +Example:
>> > + stmpe_gpi
On 23 November 2012 16:04, Lee Jones wrote:
> On Fri, 23 Nov 2012, Viresh Kumar wrote:
>> diff --git a/drivers/gpio/gpio-stmpe.c b/drivers/gpio/gpio-stmpe.c
>> static int __devinit stmpe_gpio_probe(struct platform_device *pdev)
>> {
>> - stmpe_gpio->chip.b
On 23 November 2012 15:10, Lee Jones wrote:
> That's not how it works.
>
> Apply my Acked-by yourself and re-send the patch-set as a whole.
I don't thinks so. This patch is not doing anything with DT stuff and so
can be applied separately. Related patches should be posted together
though.
--
vir
From: Vipul Kumar Samar
This patch allows the STMPE Touchscreen driver to be successfully probed and
initialised when Device Tree support is enabled. Bindings are mentioned in
Documentation too.
Signed-off-by: Vipul Kumar Samar
Signed-off-by: Viresh Kumar
---
.../bindings/input/touchscreen
From: Vipul Kumar Samar
This patch allows the STMPE GPIO driver to be successfully probed and
initialised when Device Tree support is enabled. Bindings are mentioned in
Documentation too.
Signed-off-by: Vipul Kumar Samar
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/gpio
On 22 November 2012 16:54, Lee Jones wrote:
>> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
>> b/Documentation/devicetree/bindings/mfd/stmpe.txt
>> stmpe1601: stmpe1601@40 {
>> + id = <0>;
>
> Don't do this. Device IDs are Linux specific.
Hi Lee,
This is id of
Kumar Samar
Signed-off-by: Viresh Kumar
---
V2->V3:
--
- Removed sub-modules DT bindings from this patch
- Retain original work done by Lee Jones
Documentation/devicetree/bindings/mfd/stmpe.txt | 12
drivers/mfd/stmpe-i2c.c | 15 +++
driv
Currently, few fields in stmpe_i2c_driver are initialized as:
.driver.owner = THIS_MODULE,
Group them under {}, like:
.driver = {
.owner = THIS_MODULE,
...
},
Signed-off-by: Viresh Kumar
---
drivers/mfd/stmpe-i2c.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions
This helps managing them better and also reduces chances of adding an header
file twice.
Signed-off-by: Viresh Kumar
---
drivers/mfd/stmpe-spi.c | 2 +-
drivers/mfd/stmpe.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/stmpe-spi.c b/drivers/mfd/stmpe
On 22 November 2012 16:54, Lee Jones wrote:
>> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
>> b/Documentation/devicetree/bindings/mfd/stmpe.txt
>> +Optional properties:
>> +- irq-trigger: IRQ trigger to use for the interrupt to the host
>> +- irq-invert-polarity: bool, IRQ line i
On 22 November 2012 15:57, Lee Jones wrote:
> On Thu, 22 Nov 2012, Viresh Kumar wrote:
>
>> This patch frees stmpe driver from tension of freeing resources :)
>> devm_* derivatives of multiple routines are used while allocating resources,
>> which would be freed
On 22 November 2012 21:16, Lee Jones wrote:
>> >> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
>> >> b/Documentation/devicetree/bindings/mfd/stmpe.txt
>> >> +- irq-over-gpio: bool, true if gpio is used to get irq
>> >> +- irq-gpios: gpio number over which irq will be requested (si
On 22 November 2012 16:54, Lee Jones wrote:
> Big fat NACK.
>
> You've just overwritten the current implementation with your own.
> Please take time to understand the mechanisms in place before
> you submit any changes or additions to it.
:)
My fault. Comments on all overwritten stuff accepted
On 22 November 2012 15:57, Lee Jones wrote:
> I'm assuming you've reversed the semantics here for >80 chars reasons?
Not for 80 chars reason :)
I did it to decrease nesting level of if/else statements :)
--
viresh
___
devicetree-discuss mailing list
de
From: Vipul Kumar Samar
This patch extends existing DT support for stmpe devices. Bindings are mentioned
in binding document.
Signed-off-by: Vipul Kumar Samar
Signed-off-by: Viresh Kumar
---
V1->V2:
--
- Partial DT support was already there, which i missed earlier.
- Now, this patch is
This patch frees stmpe driver from tension of freeing resources :)
devm_* derivatives of multiple routines are used while allocating resources,
which would be freed automatically by kernel.
Signed-off-by: Viresh Kumar
---
V1->V2:
--
- Rebased over latest for-next from Samuel
- upda
out the above I'll make an attempt to apply the patches from above.
Hi Olof,
Last week i had chat with Arnd and Linus over Hangout, and following is
the status:
- Dependency patch of pinctrl is:
commit 4ddb1c295752252f61670e35c791bf16e58bbce6
Author: Viresh Kumar
Date: Sat Oct 27 15:21:39 2
On 20 November 2012 13:51, Shevchenko, Andriy
wrote:
> You could at least create macro to do a precheck if you want to.
>
> Like
> #define CHECK_PROP(prop, sz, out)
>
> {
> if (!prop)
> return -EINVAL;
> if (!prop->value)
> return -ENODATA;
> if ((sz
On 9 November 2012 21:01, Viresh Kumar wrote:
> This patch frees stmpe driver from tension of freeing resources :)
> devm_* derivatives of multiple routines are used while allocating resources,
> which would be freed automatically by kernel.
>
> Signed-off-by: Vire
ts/ 16 <0x5000 0x6000 0x7000>;
Signed-off-by: Viresh Kumar
---
V2->V3:
- Expect u8 & u16 arrays to be passed using: /bits/ 8 or 16
- remove common macro, as not much common now :(
- Tested on ARM platform.
drivers/of/base.c | 77 ++
On 19 November 2012 21:58, Stephen Warren wrote:
> Support for byte- and word- properties is relatively recent I believe
> (or at least, the /bits/ syntax is). Which dtc version are you using?
Ok, i was on a older version. I just saw this patch now:
commit cd296721a9645f9f28800a072490fa15458d1fb
On 19 November 2012 12:05, Rajanikanth HV wrote:
> On 19 November 2012 12:00, Viresh Kumar wrote:
>> Firstly you tried square braces [ ], I am not sure if that is allowed.
>> Can you point me to the specification?
> http://www.devicetree.org/Device_Tree_Usage
> "
>
On 19 November 2012 11:54, Rajanikanth HV wrote:
>> data1 = /bits/ 8 <0x50 0x60 0x70>;
> as per spec, format for data byte defines will be:
> data1 = [ 0x50 0x60 0x70 ];
> however, i see a parse error from device tree compiler when i tried.
Firstly you tried square braces [ ], I am not sure if th
On 12 November 2012 09:03, Viresh Kumar wrote:
> On 12 November 2012 01:12, Rob Herring wrote:
>> I don't think the size is stored in the dtb. It is only in the dts. You
>> need to define the size in the binding definitions and use '/bits/'
>> annotation. Wi
1 - 100 of 249 matches
Mail list logo
