On Thu, 6 Dec 2012 08:06:20 +0530, Viresh Kumar wrote:
> 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
On Thu, 6 Dec 2012 07:28:22 +0530, Viresh Kumar wrote:
> 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
> >> n
On Thu, 06 Dec 2012, Viresh Kumar wrote:
> 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
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 Thu, 06 Dec 2012, Viresh Kumar wrote:
> 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
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 Thu, 06 Dec 2012, Viresh Kumar wrote:
> 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
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 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 Thu, 06 Dec 2012, Viresh Kumar wrote:
> 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,
> > 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, so filling .data field in of_device_id[] is not re
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.
>
> of_driver_match_device() matches agains
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 table and "stmpe810" in dev.
>
>
On Sat, 1 Dec 2012 00:33:46 +0530, 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: stmpe1601 detected, chip id: 0x212
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!!!
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.
:)
> On 1 December 2012 00:33, Viresh Kumar wrote:
> > On 30 Nov
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: stmpe1601 detected, chip id: 0x212".
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 Fri, 30 Nov 2012, Samuel Ortiz wrote:
> Hi Viresh, Lee,
>
> On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> > From: Vipul Kumar Samar
> >
> > This patch extends existing DT support for stmpe devices. This updates:
> > - DT support from stmpe SPI and I2C drivers
> > - missing
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?
>
> Because this was applied 2 days back by Samuel, and i didn't
> fetch it again yesterday:
>
> commit 20d5c7defc228c
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
On Fri, 30 Nov 2012, Samuel Ortiz wrote:
> Hi Viresh, Lee,
>
> On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> > From: Vipul Kumar Samar
> >
> > This patch extends existing DT support for stmpe devices. This updates:
> > - DT support from stmpe SPI and I2C drivers
> > - missing
Hi Viresh, Lee,
On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> From: Vipul Kumar Samar
>
> This patch extends existing DT support for stmpe devices. This updates:
> - DT support from stmpe SPI and I2C drivers
> - missing header files in stmpe.c
> - stmpe_of_probe() with pwm, rot
From: Vipul Kumar Samar
This patch extends existing DT support for stmpe devices. This updates:
- DT support from stmpe SPI and I2C drivers
- missing header files in stmpe.c
- stmpe_of_probe() with pwm, rotator and new bindings.
- Bindings are updated in binding document.
Signed-off-by: Vipul Ku
24 matches
Mail list logo
