IIO driver merge plans (for next merge window)

IIO driver merge plans (for next merge window)

[Jonathan Cameron]

Hi All,

It is getting to that point of the kernel development cycle where we
want to start thinking about which drivers to push out to Greg in
plenty of time for the next merge window.  If possible I'd like to
see some of them moving over to the new abi.  However, given we are
in staging anyway, we can always merge them first and change them
later!  Obviously the question of whether the abi changes merge
in time is down to what feedback they generate so that may further
complicate things.

I see there are loads from Analog in the blackfin tree and based on
a quick glance at the source they are all in pretty good state.  The
only holes I can see are possibly in documentation and that is probably
more a case of adding things to the abi docs (in my latest patch set)
than anything else.

Barry, Sonic, Michael, what are your current plans for mainlining?
(as much as staging is mainline anyway)

I see you guys have started adding ring support.  How are you finding
that element?  I'm still far from sure we have gotten that bit right
yet!  I'm going to have a play with the new FIFO implementation and
see if that provides at the very least and easier to review alternative
to the current buffer.

Would also be great to start merging DAC and DDS support from your tree and
finally justify the output element of IIO.

I know Manuel has a couple of drivers as well. Sorry to anyone I have
forgotten.  Please post your drivers!

If people want assistance with moving over to the new abi, then I'm happy
to convert drivers, but obviously would need people to test that I haven't
broken anything in the process.

With a bit of luck I'll clean up a few half written drivers I have
and perhaps look at pulling in the other light sensors now that ALS
has bitten the dust.

Looking forward to seeing lots of drivers!

Thanks,

Jonathan

p.s. If anyone has a chance to glance over the latest patch set, that would
be great.

RE: IIO driver merge plans (for next merge window)

[Song, Barry]

Drivers that passed debugging and testing on hardware can be pushed to =
mainline. By now, ADIS16300 and ADIS16400 drivers are on the list.
But the problem is they are based on old abi, will you change codes to =
match new abi? If no, we can update codes after you merge the new abi =
into mainline.

Thanks
Barry

-----Original Message-----
From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
Sent: Tue 4/27/2010 4:16 AM
To: linux-iio@vger.kernel.org
Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
Subject: IIO driver merge plans (for next merge window)
=20
Hi All,

It is getting to that point of the kernel development cycle where we
want to start thinking about which drivers to push out to Greg in
plenty of time for the next merge window.  If possible I'd like to
see some of them moving over to the new abi.  However, given we are
in staging anyway, we can always merge them first and change them
later!  Obviously the question of whether the abi changes merge
in time is down to what feedback they generate so that may further
complicate things.

I see there are loads from Analog in the blackfin tree and based on
a quick glance at the source they are all in pretty good state.  The
only holes I can see are possibly in documentation and that is probably
more a case of adding things to the abi docs (in my latest patch set)
than anything else.

Barry, Sonic, Michael, what are your current plans for mainlining?
(as much as staging is mainline anyway)

I see you guys have started adding ring support.  How are you finding
that element?  I'm still far from sure we have gotten that bit right
yet!  I'm going to have a play with the new FIFO implementation and
see if that provides at the very least and easier to review alternative
to the current buffer.

Would also be great to start merging DAC and DDS support from your tree =
and
finally justify the output element of IIO.

I know Manuel has a couple of drivers as well. Sorry to anyone I have
forgotten.  Please post your drivers!

If people want assistance with moving over to the new abi, then I'm =
happy
to convert drivers, but obviously would need people to test that I =
haven't
broken anything in the process.

With a bit of luck I'll clean up a few half written drivers I have
and perhaps look at pulling in the other light sensors now that ALS
has bitten the dust.

Looking forward to seeing lots of drivers!

Thanks,

Jonathan

p.s. If anyone has a chance to glance over the latest patch set, that =
would
be great.

Re: IIO driver merge plans (for next merge window)

[Jonathan Cameron]

On 04/27/10 04:20, Song, Barry wrote:
> Drivers that passed debugging and testing on hardware can be pushed
> to mainline. By now, ADIS16300 and ADIS16400 drivers are on the
> list. But the problem is they are based on old abi, will you change
> codes to match new abi? If no, we can update codes after you merge
> the new abi into mainline.

Sure.  I'll take a look at those and see what the best merge technique
is.  Hopefully we can tack those on to the end of the abi patch series
and do it in two stages.

Jonathan
> Thanks
> Barry
> 
> -----Original Message-----
> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
> Sent: Tue 4/27/2010 4:16 AM
> To: linux-iio@vger.kernel.org
> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
> Subject: IIO driver merge plans (for next merge window)
>  
> Hi All,
> 
> It is getting to that point of the kernel development cycle where we
> want to start thinking about which drivers to push out to Greg in
> plenty of time for the next merge window.  If possible I'd like to
> see some of them moving over to the new abi.  However, given we are
> in staging anyway, we can always merge them first and change them
> later!  Obviously the question of whether the abi changes merge
> in time is down to what feedback they generate so that may further
> complicate things.
> 
> I see there are loads from Analog in the blackfin tree and based on
> a quick glance at the source they are all in pretty good state.  The
> only holes I can see are possibly in documentation and that is probably
> more a case of adding things to the abi docs (in my latest patch set)
> than anything else.
> 
> Barry, Sonic, Michael, what are your current plans for mainlining?
> (as much as staging is mainline anyway)
> 
> I see you guys have started adding ring support.  How are you finding
> that element?  I'm still far from sure we have gotten that bit right
> yet!  I'm going to have a play with the new FIFO implementation and
> see if that provides at the very least and easier to review alternative
> to the current buffer.
> 
> Would also be great to start merging DAC and DDS support from your tree and
> finally justify the output element of IIO.
> 
> I know Manuel has a couple of drivers as well. Sorry to anyone I have
> forgotten.  Please post your drivers!
> 
> If people want assistance with moving over to the new abi, then I'm happy
> to convert drivers, but obviously would need people to test that I haven't
> broken anything in the process.
> 
> With a bit of luck I'll clean up a few half written drivers I have
> and perhaps look at pulling in the other light sensors now that ALS
> has bitten the dust.
> 
> Looking forward to seeing lots of drivers!
> 
> Thanks,
> 
> Jonathan
> 
> p.s. If anyone has a chance to glance over the latest patch set, that would
> be great.
> 
> 

Re: IIO driver merge plans (for next merge window)

[Barry Song]

Just note adis16209 is in the tested list too:
drivers/staging/iio/accel/

On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron <jic23@cam.ac.uk> wrote:
> On 04/27/10 04:20, Song, Barry wrote:
>> Drivers that passed debugging and testing on hardware can be pushed
>> to mainline. By now, ADIS16300 and ADIS16400 drivers are on the
>> list. But the problem is they are based on old abi, will you change
>> codes to match new abi? If no, we can update codes after you merge
>> the new abi into mainline.
>
> Sure. =C2=A0I'll take a look at those and see what the best merge techniq=
ue
> is. =C2=A0Hopefully we can tack those on to the end of the abi patch seri=
es
> and do it in two stages.
>
> Jonathan
>> Thanks
>> Barry
>>
>> -----Original Message-----
>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>> Sent: Tue 4/27/2010 4:16 AM
>> To: linux-iio@vger.kernel.org
>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>> Subject: IIO driver merge plans (for next merge window)
>>
>> Hi All,
>>
>> It is getting to that point of the kernel development cycle where we
>> want to start thinking about which drivers to push out to Greg in
>> plenty of time for the next merge window. =C2=A0If possible I'd like to
>> see some of them moving over to the new abi. =C2=A0However, given we are
>> in staging anyway, we can always merge them first and change them
>> later! =C2=A0Obviously the question of whether the abi changes merge
>> in time is down to what feedback they generate so that may further
>> complicate things.
>>
>> I see there are loads from Analog in the blackfin tree and based on
>> a quick glance at the source they are all in pretty good state. =C2=A0Th=
e
>> only holes I can see are possibly in documentation and that is probably
>> more a case of adding things to the abi docs (in my latest patch set)
>> than anything else.
>>
>> Barry, Sonic, Michael, what are your current plans for mainlining?
>> (as much as staging is mainline anyway)
>>
>> I see you guys have started adding ring support. =C2=A0How are you findi=
ng
>> that element? =C2=A0I'm still far from sure we have gotten that bit righ=
t
>> yet! =C2=A0I'm going to have a play with the new FIFO implementation and
>> see if that provides at the very least and easier to review alternative
>> to the current buffer.
>>
>> Would also be great to start merging DAC and DDS support from your tree =
and
>> finally justify the output element of IIO.
>>
>> I know Manuel has a couple of drivers as well. Sorry to anyone I have
>> forgotten. =C2=A0Please post your drivers!
>>
>> If people want assistance with moving over to the new abi, then I'm happ=
y
>> to convert drivers, but obviously would need people to test that I haven=
't
>> broken anything in the process.
>>
>> With a bit of luck I'll clean up a few half written drivers I have
>> and perhaps look at pulling in the other light sensors now that ALS
>> has bitten the dust.
>>
>> Looking forward to seeing lots of drivers!
>>
>> Thanks,
>>
>> Jonathan
>>
>> p.s. If anyone has a chance to glance over the latest patch set, that wo=
uld
>> be great.
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>

Re: IIO driver merge plans (for next merge window)

[Jonathan Cameron]

On 05/05/10 08:37, Barry Song wrote:
> Just note adis16209 is in the tested list too:
> drivers/staging/iio/accel/

Cool, I've done a quick import on top of Greg's tree and it all seems good.
(required half a dozen name changes and some addition dependencies in Kconfig).

How do you guys want to handle mainlining drivers from now on.  I know Michael
has requested a merge of the iio changes from Greg's tree into yours so as to
fix everything up in one go.  Do you want to wait for that and then send them
on, or if not I can keep doing quick merges of necessary change and forwarding
to Greg as you tell me they are tested?

The best option to me, would be if you guys started by initially posting the
drivers to linux-iio so we can clean any big issues up before they hit the tree.
Then either after making any requested changes or getting a few positive responses
(or a lack of response for a few days - which is acceptable here given we are still
in staging!) send them on to Greg KH for the actual merge.  For this one I will
start the ball rolling by posting this particular driver to linux-iio (and commenting
on it myself later today).

Jonathan
> 
> On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron <jic23@cam.ac.uk> wrote:
>> On 04/27/10 04:20, Song, Barry wrote:
>>> Drivers that passed debugging and testing on hardware can be pushed
>>> to mainline. By now, ADIS16300 and ADIS16400 drivers are on the
>>> list. But the problem is they are based on old abi, will you change
>>> codes to match new abi? If no, we can update codes after you merge
>>> the new abi into mainline.
>>
>> Sure.  I'll take a look at those and see what the best merge technique
>> is.  Hopefully we can tack those on to the end of the abi patch series
>> and do it in two stages.
>>
>> Jonathan
>>> Thanks
>>> Barry
>>>
>>> -----Original Message-----
>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>> Sent: Tue 4/27/2010 4:16 AM
>>> To: linux-iio@vger.kernel.org
>>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>>> Subject: IIO driver merge plans (for next merge window)
>>>
>>> Hi All,
>>>
>>> It is getting to that point of the kernel development cycle where we
>>> want to start thinking about which drivers to push out to Greg in
>>> plenty of time for the next merge window.  If possible I'd like to
>>> see some of them moving over to the new abi.  However, given we are
>>> in staging anyway, we can always merge them first and change them
>>> later!  Obviously the question of whether the abi changes merge
>>> in time is down to what feedback they generate so that may further
>>> complicate things.
>>>
>>> I see there are loads from Analog in the blackfin tree and based on
>>> a quick glance at the source they are all in pretty good state.  The
>>> only holes I can see are possibly in documentation and that is probably
>>> more a case of adding things to the abi docs (in my latest patch set)
>>> than anything else.
>>>
>>> Barry, Sonic, Michael, what are your current plans for mainlining?
>>> (as much as staging is mainline anyway)
>>>
>>> I see you guys have started adding ring support.  How are you finding
>>> that element?  I'm still far from sure we have gotten that bit right
>>> yet!  I'm going to have a play with the new FIFO implementation and
>>> see if that provides at the very least and easier to review alternative
>>> to the current buffer.
>>>
>>> Would also be great to start merging DAC and DDS support from your tree and
>>> finally justify the output element of IIO.
>>>
>>> I know Manuel has a couple of drivers as well. Sorry to anyone I have
>>> forgotten.  Please post your drivers!
>>>
>>> If people want assistance with moving over to the new abi, then I'm happy
>>> to convert drivers, but obviously would need people to test that I haven't
>>> broken anything in the process.
>>>
>>> With a bit of luck I'll clean up a few half written drivers I have
>>> and perhaps look at pulling in the other light sensors now that ALS
>>> has bitten the dust.
>>>
>>> Looking forward to seeing lots of drivers!
>>>
>>> Thanks,
>>>
>>> Jonathan
>>>
>>> p.s. If anyone has a chance to glance over the latest patch set, that would
>>> be great.
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

RE: IIO driver merge plans (for next merge window)

[Zhang, Sonic]

Hi Jonathan,

Yes, we can send the driver patches to linux-iio after it passes
debugging in local SVN. But, since the kernel version and iio tree base
in our SVN are different from yours, we have to port the patches before
posting. And we don't ensure the new patches still run without problem
in your tree, until your tree is merged into mainline and updated to our
local SVN.


Sonic


>-----Original Message-----
>From: Jonathan Cameron [mailto:jic23@cam.ac.uk]=20
>Sent: Wednesday, May 05, 2010 11:20 PM
>To: Barry Song
>Cc: Song, Barry; linux-iio@vger.kernel.org; Zhang, Sonic;=20
>Hennerich, Michael; Manuel Stahl
>Subject: Re: IIO driver merge plans (for next merge window)
>
>On 05/05/10 08:37, Barry Song wrote:
>> Just note adis16209 is in the tested list too:
>> drivers/staging/iio/accel/
>
>Cool, I've done a quick import on top of Greg's tree and it=20
>all seems good.
>(required half a dozen name changes and some addition=20
>dependencies in Kconfig).
>
>How do you guys want to handle mainlining drivers from now on.=20
> I know Michael has requested a merge of the iio changes from=20
>Greg's tree into yours so as to fix everything up in one go. =20
>Do you want to wait for that and then send them on, or if not=20
>I can keep doing quick merges of necessary change and=20
>forwarding to Greg as you tell me they are tested?
>
>The best option to me, would be if you guys started by=20
>initially posting the drivers to linux-iio so we can clean any=20
>big issues up before they hit the tree.
>Then either after making any requested changes or getting a=20
>few positive responses (or a lack of response for a few days -=20
>which is acceptable here given we are still in staging!) send=20
>them on to Greg KH for the actual merge.  For this one I will=20
>start the ball rolling by posting this particular driver to=20
>linux-iio (and commenting on it myself later today).
>
>Jonathan
>>=20
>> On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron=20
><jic23@cam.ac.uk> wrote:
>>> On 04/27/10 04:20, Song, Barry wrote:
>>>> Drivers that passed debugging and testing on hardware can=20
>be pushed=20
>>>> to mainline. By now, ADIS16300 and ADIS16400 drivers are on the=20
>>>> list. But the problem is they are based on old abi, will=20
>you change=20
>>>> codes to match new abi? If no, we can update codes after you merge=20
>>>> the new abi into mainline.
>>>
>>> Sure.  I'll take a look at those and see what the best merge=20
>>> technique is.  Hopefully we can tack those on to the end of the abi=20
>>> patch series and do it in two stages.
>>>
>>> Jonathan
>>>> Thanks
>>>> Barry
>>>>
>>>> -----Original Message-----
>>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>>> Sent: Tue 4/27/2010 4:16 AM
>>>> To: linux-iio@vger.kernel.org
>>>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>>>> Subject: IIO driver merge plans (for next merge window)
>>>>
>>>> Hi All,
>>>>
>>>> It is getting to that point of the kernel development=20
>cycle where we=20
>>>> want to start thinking about which drivers to push out to Greg in=20
>>>> plenty of time for the next merge window.  If possible I'd like to=20
>>>> see some of them moving over to the new abi.  However,=20
>given we are=20
>>>> in staging anyway, we can always merge them first and change them=20
>>>> later!  Obviously the question of whether the abi changes merge in=20
>>>> time is down to what feedback they generate so that may further=20
>>>> complicate things.
>>>>
>>>> I see there are loads from Analog in the blackfin tree and=20
>based on=20
>>>> a quick glance at the source they are all in pretty good=20
>state.  The=20
>>>> only holes I can see are possibly in documentation and that is=20
>>>> probably more a case of adding things to the abi docs (in=20
>my latest=20
>>>> patch set) than anything else.
>>>>
>>>> Barry, Sonic, Michael, what are your current plans for mainlining?
>>>> (as much as staging is mainline anyway)
>>>>
>>>> I see you guys have started adding ring support.  How are you=20
>>>> finding that element?  I'm still far from sure we have gotten that=20
>>>> bit right yet!  I'm going to have a play with the new FIFO=20
>>>> implementation and see if that provides at the very least=20
>and easier=20
>>>> to review alternative to the current buffer.
>>>>
>>>> Would also be great to start merging DAC and DDS support from your=20
>>>> tree and finally justify the output element of IIO.
>>>>
>>>> I know Manuel has a couple of drivers as well. Sorry to anyone I=20
>>>> have forgotten.  Please post your drivers!
>>>>
>>>> If people want assistance with moving over to the new abi,=20
>then I'm=20
>>>> happy to convert drivers, but obviously would need people to test=20
>>>> that I haven't broken anything in the process.
>>>>
>>>> With a bit of luck I'll clean up a few half written drivers I have=20
>>>> and perhaps look at pulling in the other light sensors now=20
>that ALS=20
>>>> has bitten the dust.
>>>>
>>>> Looking forward to seeing lots of drivers!
>>>>
>>>> Thanks,
>>>>
>>>> Jonathan
>>>>
>>>> p.s. If anyone has a chance to glance over the latest patch set,=20
>>>> that would be great.
>>>>
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe=20
>linux-iio"=20
>>> in the body of a message to majordomo@vger.kernel.org More=20
>majordomo=20
>>> info at  http://vger.kernel.org/majordomo-info.html
>>>
>>=20
>
>

RE: IIO driver merge plans (for next merge window)

[Hennerich, Michael]

Zhang, Sonic wrote on 2010-05-17:
> Hi Jonathan,
>
> Yes, we can send the driver patches to linux-iio after it passes
> debugging in local SVN. But, since the kernel version and iio tree
> base in our SVN are different from yours, we have to port the patches
> before posting. And we don't ensure the new patches still run without
> problem in your tree, until your tree is merged into mainline and
> updated to our local SVN.

Sonic,

How about we merge Greg's staging iio folder into our svn right now?
This way we can do the API fixes to our drivers and send them also to Greg =
for
inclusion without greater delays.

-Michael

>
>
> Sonic
>
>
>> -----Original Message-----
>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>> Sent: Wednesday, May 05, 2010 11:20 PM
>> To: Barry Song
>> Cc: Song, Barry; linux-iio@vger.kernel.org; Zhang, Sonic; Hennerich,
>> Michael; Manuel Stahl
>> Subject: Re: IIO driver merge plans (for next merge window)
>>
>> On 05/05/10 08:37, Barry Song wrote:
>>> Just note adis16209 is in the tested list too:
>>> drivers/staging/iio/accel/
>>
>> Cool, I've done a quick import on top of Greg's tree and it all seems
>> good.
>> (required half a dozen name changes and some addition dependencies in
>> Kconfig).
>>
>> How do you guys want to handle mainlining drivers from now on.
>> I know Michael has requested a merge of the iio changes from Greg's
>> tree into yours so as to fix everything up in one go.
>> Do you want to wait for that and then send them on, or if not I can
>> keep doing quick merges of necessary change and forwarding to Greg as
>> you tell me they are tested?
>>
>> The best option to me, would be if you guys started by initially
>> posting the drivers to linux-iio so we can clean any big issues up
>> before they hit the tree. Then either after making any requested
>> changes or getting a few positive responses (or a lack of response for
>> a few days - which is acceptable here given we are still in staging!)
>> send them on to Greg KH for the actual merge.  For this one I will
>> start the ball rolling by posting this particular driver to linux-iio
>> (and commenting on it myself later today).
>>
>> Jonathan
>>>
>>> On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron
>> <jic23@cam.ac.uk> wrote:
>>>> On 04/27/10 04:20, Song, Barry wrote:
>>>>> Drivers that passed debugging and testing on hardware can be pushed
>>>>> to mainline. By now, ADIS16300 and ADIS16400 drivers are on the
>>>>> list. But the problem is they are based on old abi, will you change
>>>>> codes to match new abi? If no, we can update codes after you merge
>>>>> the new abi into mainline.
>>>>
>>>> Sure.  I'll take a look at those and see what the best merge
>>>> technique is.  Hopefully we can tack those on to the end of the
>>>> abi patch series and do it in two stages.
>>>>
>>>> Jonathan
>>>>> Thanks
>>>>> Barry
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>>>> Sent: Tue 4/27/2010 4:16 AM
>>>>> To: linux-iio@vger.kernel.org
>>>>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>>>>> Subject: IIO driver merge plans (for next merge window)
>>>>>
>>>>> Hi All,
>>>>>
>>>>> It is getting to that point of the kernel development cycle where we
>>>>> want to start thinking about which drivers to push out to Greg in
>>>>> plenty of time for the next merge window.  If possible I'd like to
>>>>> see some of them moving over to the new abi.  However, given we are
>>>>> in staging anyway, we can always merge them first and change them
>>>>> later!  Obviously the question of whether the abi changes merge in
>>>>> time is down to what feedback they generate so that may further
>>>>> complicate things.
>>>>>
>>>>> I see there are loads from Analog in the blackfin tree and based on
>>>>> a quick glance at the source they are all in pretty good state.  The
>>>>> only holes I can see are possibly in documentation and that is
>>>>> probably more a case of adding things to the abi docs (in my latest
>>>>> patch set) than anything else.
>>>>>
>>>>> Barry, Sonic, Michael, what are your current plans for mainlining?
>>>>> (as much as staging is mainline anyway)
>>>>>
>>>>> I see you guys have started adding ring support.  How are you
>>>>> finding that element?  I'm still far from sure we have gotten that
>>>>> bit right yet!  I'm going to have a play with the new FIFO
>>>>> implementation and see if that provides at the very least and easier
>>>>> to review alternative to the current buffer.
>>>>>
>>>>> Would also be great to start merging DAC and DDS support from
>>>>> your tree and finally justify the output element of IIO.
>>>>>
>>>>> I know Manuel has a couple of drivers as well. Sorry to anyone I
>>>>> have forgotten.  Please post your drivers!
>>>>>
>>>>> If people want assistance with moving over to the new abi, then I'm
>>>>> happy to convert drivers, but obviously would need people to test
>>>>> that I haven't broken anything in the process.
>>>>>
>>>>> With a bit of luck I'll clean up a few half written drivers I have
>>>>> and perhaps look at pulling in the other light sensors now that ALS
>>>>> has bitten the dust.
>>>>>
>>>>> Looking forward to seeing lots of drivers!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jonathan
>>>>>
>>>>> p.s. If anyone has a chance to glance over the latest patch set,
>>>>> that would be great.
>>>>>
>>>>>
>>>>
>>>> -- To unsubscribe from this list: send the line "unsubscribe
>>>> linux-iio" in the body of a message to majordomo@vger.kernel.org More
>>>> majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>>

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif

RE: IIO driver merge plans (for next merge window)

[Zhang, Sonic]

=20

>-----Original Message-----
>From: Hennerich, Michael=20
>Sent: Monday, May 17, 2010 3:48 PM
>To: Zhang, Sonic; Jonathan Cameron; Barry Song
>Cc: Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl;=20
>Frysinger, Michael
>Subject: RE: IIO driver merge plans (for next merge window)
>
>Zhang, Sonic wrote on 2010-05-17:
>> Hi Jonathan,
>>=20
>> Yes, we can send the driver patches to linux-iio after it passes=20
>> debugging in local SVN. But, since the kernel version and iio tree=20
>> base in our SVN are different from yours, we have to port=20
>the patches=20
>> before posting. And we don't ensure the new patches still=20
>run without=20
>> problem in your tree, until your tree is merged into mainline and=20
>> updated to our local SVN.
>
>Sonic,
>
>How about we merge Greg's staging iio folder into our svn right now?
>This way we can do the API fixes to our drivers and send them=20
>also to Greg for inclusion without greater delays.
>

It is OK to merge the IIO patches if they don't care about kernel
version difference between Greg's tree and our SVN tree. Our's is
2.6.33.4, while Greg's is 2.6.34-rc6



Sonic


>-Michael=20
>
>>=20
>>=20
>> Sonic
>>=20
>>=20
>>> -----Original Message-----
>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>> Sent: Wednesday, May 05, 2010 11:20 PM
>>> To: Barry Song
>>> Cc: Song, Barry; linux-iio@vger.kernel.org; Zhang, Sonic;=20
>Hennerich,=20
>>> Michael; Manuel Stahl
>>> Subject: Re: IIO driver merge plans (for next merge window)
>>>=20
>>> On 05/05/10 08:37, Barry Song wrote:
>>>> Just note adis16209 is in the tested list too:
>>>> drivers/staging/iio/accel/
>>>=20
>>> Cool, I've done a quick import on top of Greg's tree and it=20
>all seems=20
>>> good.
>>> (required half a dozen name changes and some addition=20
>dependencies in=20
>>> Kconfig).
>>>=20
>>> How do you guys want to handle mainlining drivers from now on.
>>> I know Michael has requested a merge of the iio changes from Greg's=20
>>> tree into yours so as to fix everything up in one go.
>>> Do you want to wait for that and then send them on, or if not I can=20
>>> keep doing quick merges of necessary change and forwarding=20
>to Greg as=20
>>> you tell me they are tested?
>>>=20
>>> The best option to me, would be if you guys started by initially=20
>>> posting the drivers to linux-iio so we can clean any big issues up=20
>>> before they hit the tree. Then either after making any requested=20
>>> changes or getting a few positive responses (or a lack of response=20
>>> for a few days - which is acceptable here given we are still in=20
>>> staging!) send them on to Greg KH for the actual merge. =20
>For this one=20
>>> I will start the ball rolling by posting this particular driver to=20
>>> linux-iio (and commenting on it myself later today).
>>>=20
>>> Jonathan
>>>>=20
>>>> On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron
>>> <jic23@cam.ac.uk> wrote:
>>>>> On 04/27/10 04:20, Song, Barry wrote:
>>>>>> Drivers that passed debugging and testing on hardware can be=20
>>>>>> pushed to mainline. By now, ADIS16300 and ADIS16400=20
>drivers are on=20
>>>>>> the list. But the problem is they are based on old abi, will you=20
>>>>>> change codes to match new abi? If no, we can update codes after=20
>>>>>> you merge the new abi into mainline.
>>>>>=20
>>>>> Sure.  I'll take a look at those and see what the best merge=20
>>>>> technique is.  Hopefully we can tack those on to the end=20
>of the abi=20
>>>>> patch series and do it in two stages.
>>>>>=20
>>>>> Jonathan
>>>>>> Thanks
>>>>>> Barry
>>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>>>>> Sent: Tue 4/27/2010 4:16 AM
>>>>>> To: linux-iio@vger.kernel.org
>>>>>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>>>>>> Subject: IIO driver merge plans (for next merge window)
>>>>>>=20
>>>>>> Hi All,
>>>>>>=20
>>>>>> It is getting to that point of the kernel development=20
>cycle where=20
>>>>>> we want to start thinking about which drivers to push=20
>out to Greg=20
>>>>>> in plenty of time for the next merge window.  If=20
>possible I'd like=20
>>>>>> to see some of them moving over to the new abi. =20
>However, given we=20
>>>>>> are in staging anyway, we can always merge them first and change=20
>>>>>> them later!  Obviously the question of whether the abi changes=20
>>>>>> merge in time is down to what feedback they generate so that may=20
>>>>>> further complicate things.
>>>>>>=20
>>>>>> I see there are loads from Analog in the blackfin tree and based=20
>>>>>> on a quick glance at the source they are all in pretty=20
>good state. =20
>>>>>> The only holes I can see are possibly in documentation=20
>and that is=20
>>>>>> probably more a case of adding things to the abi docs (in my=20
>>>>>> latest patch set) than anything else.
>>>>>>=20
>>>>>> Barry, Sonic, Michael, what are your current plans for=20
>mainlining?
>>>>>> (as much as staging is mainline anyway)
>>>>>>=20
>>>>>> I see you guys have started adding ring support.  How are you=20
>>>>>> finding that element?  I'm still far from sure we have=20
>gotten that=20
>>>>>> bit right yet!  I'm going to have a play with the new FIFO=20
>>>>>> implementation and see if that provides at the very least and=20
>>>>>> easier to review alternative to the current buffer.
>>>>>>=20
>>>>>> Would also be great to start merging DAC and DDS support=20
>from your=20
>>>>>> tree and finally justify the output element of IIO.
>>>>>>=20
>>>>>> I know Manuel has a couple of drivers as well. Sorry to anyone I=20
>>>>>> have forgotten.  Please post your drivers!
>>>>>>=20
>>>>>> If people want assistance with moving over to the new abi, then=20
>>>>>> I'm happy to convert drivers, but obviously would need people to=20
>>>>>> test that I haven't broken anything in the process.
>>>>>>=20
>>>>>> With a bit of luck I'll clean up a few half written=20
>drivers I have=20
>>>>>> and perhaps look at pulling in the other light sensors now that=20
>>>>>> ALS has bitten the dust.
>>>>>>=20
>>>>>> Looking forward to seeing lots of drivers!
>>>>>>=20
>>>>>> Thanks,
>>>>>>=20
>>>>>> Jonathan
>>>>>>=20
>>>>>> p.s. If anyone has a chance to glance over the latest patch set,=20
>>>>>> that would be great.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> -- To unsubscribe from this list: send the line "unsubscribe=20
>>>>> linux-iio" in the body of a message to majordomo@vger.kernel.org=20
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>=20
>>>>=20
>>>=20
>>>
>
>Greetings,
>Michael
>
>Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
>Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB=20
>4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
>
>

RE: IIO driver merge plans (for next merge window)

[Hennerich, Michael]

Zhang, Sonic wrote on 2010-05-17:
>
>
>> -----Original Message-----
>> From: Hennerich, Michael
>> Sent: Monday, May 17, 2010 3:48 PM
>> To: Zhang, Sonic; Jonathan Cameron; Barry Song
>> Cc: Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>> Michael
>> Subject: RE: IIO driver merge plans (for next merge window)
>>
>> Zhang, Sonic wrote on 2010-05-17:
>>> Hi Jonathan,
>>>
>>> Yes, we can send the driver patches to linux-iio after it passes
>>> debugging in local SVN. But, since the kernel version and iio tree
>>> base in our SVN are different from yours, we have to port the patches
>>> before posting. And we don't ensure the new patches still run without
>>> problem in your tree, until your tree is merged into mainline and
>>> updated to our local SVN.
>>
>> Sonic,
>>
>> How about we merge Greg's staging iio folder into our svn right now?
>> This way we can do the API fixes to our drivers and send them also to
>> Greg for inclusion without greater delays.
>>
>
> It is OK to merge the IIO patches if they don't care about kernel
> version difference between Greg's tree and our SVN tree. Our's is
> 2.6.33.4, while Greg's is 2.6.34-rc6

staging-iio is pretty much self contained.
As far I can tell it doesn't depend on anything that has been changed
between 2.6.33 and 2.6.34.

-Michael

>
>
>
> Sonic
>
>
>> -Michael
>>
>>>
>>>
>>> Sonic
>>>
>>>
>>>> -----Original Message----- From: Jonathan Cameron
>>>> [mailto:jic23@cam.ac.uk] Sent: Wednesday, May 05, 2010 11:20 PM To:
>>>> Barry Song Cc: Song, Barry; linux-iio@vger.kernel.org; Zhang, Sonic;
>>>> Hennerich, Michael; Manuel Stahl Subject: Re: IIO driver merge plans
>>>> (for next merge window)
>>>>
>>>> On 05/05/10 08:37, Barry Song wrote:
>>>>> Just note adis16209 is in the tested list too:
>>>>> drivers/staging/iio/accel/
>>>>
>>>> Cool, I've done a quick import on top of Greg's tree and it all seems
>>>> good. (required half a dozen name changes and some addition
>>>> dependencies in Kconfig).
>>>>
>>>> How do you guys want to handle mainlining drivers from now on. I know
>>>> Michael has requested a merge of the iio changes from Greg's tree
>>>> into yours so as to fix everything up in one go. Do you want to wait
>>>> for that and then send them on, or if not I can keep doing quick
>>>> merges of necessary change and forwarding to Greg as you tell me they
>>>> are tested?
>>>>
>>>> The best option to me, would be if you guys started by initially
>>>> posting the drivers to linux-iio so we can clean any big issues up
>>>> before they hit the tree. Then either after making any requested
>>>> changes or getting a few positive responses (or a lack of response
>>>> for a few days - which is acceptable here given we are still in
>>>> staging!) send them on to Greg KH for the actual merge. For this one
>>>> I will start the ball rolling by posting this particular driver to
>>>> linux-iio (and commenting on it myself later today).
>>>>
>>>> Jonathan
>>>>>
>>>>> On Tue, Apr 27, 2010 at 5:27 PM, Jonathan Cameron
>>>> <jic23@cam.ac.uk> wrote:
>>>>>> On 04/27/10 04:20, Song, Barry wrote:
>>>>>>> Drivers that passed debugging and testing on hardware can be
>>>>>>> pushed to mainline. By now, ADIS16300 and ADIS16400 drivers are on
>>>>>>> the list. But the problem is they are based on old abi, will you
>>>>>>> change codes to match new abi? If no, we can update codes after
>>>>>>> you merge the new abi into mainline.
>>>>>>
>>>>>> Sure.  I'll take a look at those and see what the best merge
>>>>>> technique is.  Hopefully we can tack those on to the end of the abi
>>>>>> patch series and do it in two stages.
>>>>>>
>>>>>> Jonathan
>>>>>>> Thanks
>>>>>>> Barry
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jonathan Cameron [mailto:jic23@cam.ac.uk]
>>>>>>> Sent: Tue 4/27/2010 4:16 AM
>>>>>>> To: linux-iio@vger.kernel.org
>>>>>>> Cc: Song, Barry; Zhang, Sonic; Hennerich, Michael; Manuel Stahl
>>>>>>> Subject: IIO driver merge plans (for next merge window)
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> It is getting to that point of the kernel development cycle where
>>>>>>> we want to start thinking about which drivers to push out to Greg
>>>>>>> in plenty of time for the next merge window.  If possible I'd like
>>>>>>> to see some of them moving over to the new abi. However, given we
>>>>>>> are in staging anyway, we can always merge them first and change
>>>>>>> them later!  Obviously the question of whether the abi changes
>>>>>>> merge in time is down to what feedback they generate so that may
>>>>>>> further complicate things.
>>>>>>>
>>>>>>> I see there are loads from Analog in the blackfin tree and based
>>>>>>> on a quick glance at the source they are all in pretty good state.
>>>>>>> The only holes I can see are possibly in documentation and that is
>>>>>>> probably more a case of adding things to the abi docs (in my
>>>>>>> latest patch set) than anything else.
>>>>>>>
>>>>>>> Barry, Sonic, Michael, what are your current plans for mainlining?
>>>>>>> (as much as staging is mainline anyway)
>>>>>>>
>>>>>>> I see you guys have started adding ring support.  How are you
>>>>>>> finding that element?  I'm still far from sure we have gotten that
>>>>>>> bit right yet!  I'm going to have a play with the new FIFO
>>>>>>> implementation and see if that provides at the very least and
>>>>>>> easier to review alternative to the current buffer.
>>>>>>>
>>>>>>> Would also be great to start merging DAC and DDS support from your
>>>>>>> tree and finally justify the output element of IIO.
>>>>>>>
>>>>>>> I know Manuel has a couple of drivers as well. Sorry to anyone
>>>>>>> I have forgotten.  Please post your drivers!
>>>>>>>
>>>>>>> If people want assistance with moving over to the new abi, then
>>>>>>> I'm happy to convert drivers, but obviously would need people
>>>>>>> to test that I haven't broken anything in the process.
>>>>>>>
>>>>>>> With a bit of luck I'll clean up a few half written drivers I have
>>>>>>> and perhaps look at pulling in the other light sensors now that
>>>>>>> ALS has bitten the dust.
>>>>>>>
>>>>>>> Looking forward to seeing lots of drivers!
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jonathan
>>>>>>>
>>>>>>> p.s. If anyone has a chance to glance over the latest patch
>>>>>>> set, that would be great.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -- To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-iio" in the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo- info.html
>>>>>>
>>>>>
>>>>
>>>>
>>
>> Greetings,
>> Michael
>>
>> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
>> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB
>> 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret
>> Seif
>>
>>

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: IIO driver merge plans (for next merge window)

[Jonathan Cameron]

On 05/17/10 09:08, Hennerich, Michael wrote:
> Zhang, Sonic wrote on 2010-05-17:
>>
>>
>>> -----Original Message-----
>>> From: Hennerich, Michael
>>> Sent: Monday, May 17, 2010 3:48 PM
>>> To: Zhang, Sonic; Jonathan Cameron; Barry Song
>>> Cc: Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>>> Michael
>>> Subject: RE: IIO driver merge plans (for next merge window)
>>>
>>> Zhang, Sonic wrote on 2010-05-17:
>>>> Hi Jonathan,
>>>>
>>>> Yes, we can send the driver patches to linux-iio after it passes
>>>> debugging in local SVN. But, since the kernel version and iio tree
>>>> base in our SVN are different from yours, we have to port the patches
>>>> before posting. And we don't ensure the new patches still run without
>>>> problem in your tree, until your tree is merged into mainline and
>>>> updated to our local SVN.
>>>
>>> Sonic,
>>>
>>> How about we merge Greg's staging iio folder into our svn right now?
>>> This way we can do the API fixes to our drivers and send them also to
>>> Greg for inclusion without greater delays.
>>>
>>
>> It is OK to merge the IIO patches if they don't care about kernel
>> version difference between Greg's tree and our SVN tree. Our's is
>> 2.6.33.4, while Greg's is 2.6.34-rc6
> 
> staging-iio is pretty much self contained.
> As far I can tell it doesn't depend on anything that has been changed
> between 2.6.33 and 2.6.34.
There might be a few header issues outside IIO. These are just additional
required headers (due to some general clean up) that shouldn't effect
the merge from mainline to your tree, but may cause issues the other way
around by requiring a few more includes in some of your drivers. A simple
build test should throw up any of these.

I don't know what Greg's policy is on taking patches at this stage in the
merge cycle (merge window just opened).  I'd imagine anything he doesn't
get in the next couple of days will have to work for the next window
(in about three months).  They'll sit in linux next until then.  I don't
think operates the normal kernel rule of allowing new self contained drivers
to merge later in the cycle.  This would become hard to manage for staging
where the majority of code fits in that category.

Jonathan

RE: IIO driver merge plans (for next merge window)

[Hennerich, Michael]

Jonathan Cameron wrote on 2010-05-17:
> On 05/17/10 09:08, Hennerich, Michael wrote:
>> Zhang, Sonic wrote on 2010-05-17:
>>>
>>>
>>>> -----Original Message----- From: Hennerich, Michael Sent: Monday, May
>>>> 17, 2010 3:48 PM To: Zhang, Sonic; Jonathan Cameron; Barry Song Cc:
>>>> Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>>>> Michael Subject: RE: IIO driver merge plans (for next merge window)
>>>>
>>>> Zhang, Sonic wrote on 2010-05-17:
>>>>> Hi Jonathan,
>>>>>
>>>>> Yes, we can send the driver patches to linux-iio after it passes
>>>>> debugging in local SVN. But, since the kernel version and iio
>>>>> tree base in our SVN are different from yours, we have to port
>>>>> the patches before posting. And we don't ensure the new patches
>>>>> still run without problem in your tree, until your tree is merged
>>>>> into mainline and updated to our local SVN.
>>>>
>>>> Sonic,
>>>>
>>>> How about we merge Greg's staging iio folder into our svn right now?
>>>> This way we can do the API fixes to our drivers and send them also to
>>>> Greg for inclusion without greater delays.
>>>>
>>>
>>> It is OK to merge the IIO patches if they don't care about kernel
>>> version difference between Greg's tree and our SVN tree. Our's is
>>> 2.6.33.4, while Greg's is 2.6.34-rc6
>>
>> staging-iio is pretty much self contained.
>> As far I can tell it doesn't depend on anything that has been
>> changed between 2.6.33 and 2.6.34.
> There might be a few header issues outside IIO. These are just
> additional required headers (due to some general clean up) that
> shouldn't effect the merge from mainline to your tree, but may cause
> issues the other way around by requiring a few more includes in some
> of your drivers. A simple build test should throw up any of these.

I think you are referring to include linux/slab.h?

>
> I don't know what Greg's policy is on taking patches at this stage in
> the merge cycle (merge window just opened).  I'd imagine anything he
> doesn't get in the next couple of days will have to work for the next
> window (in about three months).  They'll sit in linux next until then.
> I don't think operates the normal kernel rule of allowing new self
> contained drivers to merge later in the cycle.  This would become hard
> to manage for staging where the majority of code fits in that category.
>
> Jonathan

Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: IIO driver merge plans (for next merge window)

[Jonathan Cameron]

On 05/17/10 10:36, Hennerich, Michael wrote:
> Jonathan Cameron wrote on 2010-05-17:
>> On 05/17/10 09:08, Hennerich, Michael wrote:
>>> Zhang, Sonic wrote on 2010-05-17:
>>>>
>>>>
>>>>> -----Original Message----- From: Hennerich, Michael Sent: Monday, May
>>>>> 17, 2010 3:48 PM To: Zhang, Sonic; Jonathan Cameron; Barry Song Cc:
>>>>> Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>>>>> Michael Subject: RE: IIO driver merge plans (for next merge window)
>>>>>
>>>>> Zhang, Sonic wrote on 2010-05-17:
>>>>>> Hi Jonathan,
>>>>>>
>>>>>> Yes, we can send the driver patches to linux-iio after it passes
>>>>>> debugging in local SVN. But, since the kernel version and iio
>>>>>> tree base in our SVN are different from yours, we have to port
>>>>>> the patches before posting. And we don't ensure the new patches
>>>>>> still run without problem in your tree, until your tree is merged
>>>>>> into mainline and updated to our local SVN.
>>>>>
>>>>> Sonic,
>>>>>
>>>>> How about we merge Greg's staging iio folder into our svn right now?
>>>>> This way we can do the API fixes to our drivers and send them also to
>>>>> Greg for inclusion without greater delays.
>>>>>
>>>>
>>>> It is OK to merge the IIO patches if they don't care about kernel
>>>> version difference between Greg's tree and our SVN tree. Our's is
>>>> 2.6.33.4, while Greg's is 2.6.34-rc6
>>>
>>> staging-iio is pretty much self contained.
>>> As far I can tell it doesn't depend on anything that has been
>>> changed between 2.6.33 and 2.6.34.
>> There might be a few header issues outside IIO. These are just
>> additional required headers (due to some general clean up) that
>> shouldn't effect the merge from mainline to your tree, but may cause
>> issues the other way around by requiring a few more includes in some
>> of your drivers. A simple build test should throw up any of these.
> 
> I think you are referring to include linux/slab.h?
Yup. Though I have a vague recollection of there being another
one as well, but that may have been prior to this cycle.
> 
>>
>> I don't know what Greg's policy is on taking patches at this stage in
>> the merge cycle (merge window just opened).  I'd imagine anything he
>> doesn't get in the next couple of days will have to work for the next
>> window (in about three months).  They'll sit in linux next until then.
>> I don't think operates the normal kernel rule of allowing new self
>> contained drivers to merge later in the cycle.  This would become hard
>> to manage for staging where the majority of code fits in that category.
>>
>> Jonathan
> 
> Greetings,
> Michael
> 
> Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
> Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
> 
> 
> 

Re: IIO driver merge plans (for next merge window)

[Barry Song]

On Mon, May 17, 2010 at 5:32 PM, Jonathan Cameron <jic23@cam.ac.uk> wrote:
> On 05/17/10 09:08, Hennerich, Michael wrote:
>> Zhang, Sonic wrote on 2010-05-17:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Hennerich, Michael
>>>> Sent: Monday, May 17, 2010 3:48 PM
>>>> To: Zhang, Sonic; Jonathan Cameron; Barry Song
>>>> Cc: Song, Barry; linux-iio@vger.kernel.org; Manuel Stahl; Frysinger,
>>>> Michael
>>>> Subject: RE: IIO driver merge plans (for next merge window)
>>>>
>>>> Zhang, Sonic wrote on 2010-05-17:
>>>>> Hi Jonathan,
>>>>>
>>>>> Yes, we can send the driver patches to linux-iio after it passes
>>>>> debugging in local SVN. But, since the kernel version and iio tree
>>>>> base in our SVN are different from yours, we have to port the patches
>>>>> before posting. And we don't ensure the new patches still run without
>>>>> problem in your tree, until your tree is merged into mainline and
>>>>> updated to our local SVN.
>>>>
>>>> Sonic,
>>>>
>>>> How about we merge Greg's staging iio folder into our svn right now?
>>>> This way we can do the API fixes to our drivers and send them also to
>>>> Greg for inclusion without greater delays.
>>>>
>>>
>>> It is OK to merge the IIO patches if they don't care about kernel
>>> version difference between Greg's tree and our SVN tree. Our's is
>>> 2.6.33.4, while Greg's is 2.6.34-rc6
>>
>> staging-iio is pretty much self contained.
>> As far I can tell it doesn't depend on anything that has been changed
>> between 2.6.33 and 2.6.34.
> There might be a few header issues outside IIO. These are just additional
> required headers (due to some general clean up) that shouldn't effect
> the merge from mainline to your tree, but may cause issues the other way
> around by requiring a few more includes in some of your drivers. A simple
> build test should throw up any of these.
>
> I don't know what Greg's policy is on taking patches at this stage in the
> merge cycle (merge window just opened). =C2=A0I'd imagine anything he doe=
sn't
> get in the next couple of days will have to work for the next window
> (in about three months).

Can you help to merge my last tested driver adis16350? That's the last
one from me in this window.
I think, after that,  new drivers patches and incremental patches
against the staging tree will come from us directly since the instant
blackfin tree will pull the new features in staging tree.

> They'll sit in linux next until then. =C2=A0I don't
> think operates the normal kernel rule of allowing new self contained driv=
ers
> to merge later in the cycle. =C2=A0This would become hard to manage for s=
taging
> where the majority of code fits in that category.
>
> Jonathan
>

adis16300 to new abi

[Jonathan Cameron]

On 04/27/10 04:20, Song, Barry wrote:
> Drivers that passed debugging and testing on hardware can be pushed to mainline. By now, ADIS16300 and ADIS16400 drivers are on the list.
> But the problem is they are based on old abi, will you change codes to match new abi? If no, we can update codes after you merge the new abi into mainline.
> 

Hi Barry,

I've just taken a quick look at the adis16300 driver.  The following
patch is all that is needed to get it to build against the abi patch set.
(and touch wood it should still work, be it with an odd mix of abis)

There are other changes to meet the abi, but they can be done via 
incremental patches after this one.  They are all name changes (such as
addition of _raw to the inclination parameters) or additional parameters
that would be needed by a general userspace interpreter (my
drivers are missing some of these as well at the moment!).  Also there
are a couple of additions to make to the abi documentation.  All of these
could be sorted by a nice clean patch set after the driver patch itself.

Whilst we are here.  Under what circumstances does userspace want to reset
the device manually?  Unless there is a clear and common use for this, I'd
be inclined to move that particular attribute definition into individual
drivers.

How do you want to do the actual patch? I could apply the following as
a 'merge' fix to a clean patch from you, or I can put together a suitable
hybrid of the two (from you of course). Obviously this would need you
to take a quick glance and sign-off on it.

Thanks,

Jonathan
---
diff --git a/drivers/staging/iio/imu/adis16300_core.c b/drivers/staging/iio/imu/adis16300_core.c
index 8f84175..94ea2d1 100644
--- a/drivers/staging/iio/imu/adis16300_core.c
+++ b/drivers/staging/iio/imu/adis16300_core.c
@@ -646,9 +646,9 @@ static struct attribute *adis16300_attributes[] = {
        &iio_const_attr_volt_supply_scale.dev_attr.attr,
        &iio_dev_attr_gyro_x.dev_attr.attr,
        &iio_const_attr_gyro_scale.dev_attr.attr,
-       &iio_dev_attr_accel_x.dev_attr.attr,
-       &iio_dev_attr_accel_y.dev_attr.attr,
-       &iio_dev_attr_accel_z.dev_attr.attr,
+       &iio_dev_attr_accel_x_raw.dev_attr.attr,
+       &iio_dev_attr_accel_y_raw.dev_attr.attr,
+       &iio_dev_attr_accel_z_raw.dev_attr.attr,
        &iio_const_attr_accel_scale.dev_attr.attr,
        &iio_dev_attr_incli_x.dev_attr.attr,
        &iio_dev_attr_incli_y.dev_attr.attr,
diff --git a/drivers/staging/iio/imu/adis16300_ring.c b/drivers/staging/iio/imu/adis16300_ring.c
index 79298b3..76cf8a6 100644
--- a/drivers/staging/iio/imu/adis16300_ring.c
+++ b/drivers/staging/iio/imu/adis16300_ring.c
@@ -49,7 +49,7 @@ static IIO_SCAN_EL_C(incli_x, ADIS16300_SCAN_INCLI_X, IIO_SIGNED(12),
 static IIO_SCAN_EL_C(incli_y, ADIS16300_SCAN_INCLI_Y, IIO_SIGNED(12),
                     ADIS16300_YINCLI_OUT, NULL);
 
-static IIO_SCAN_EL_TIMESTAMP;
+static IIO_SCAN_EL_TIMESTAMP(9);
 
 static struct attribute *adis16300_scan_el_attrs[] = {
        &iio_scan_el_supply.dev_attr.attr,
@@ -224,7 +224,7 @@ error_iio_sw_rb_free:
 
 int adis16300_initialize_ring(struct iio_ring_buffer *ring)
 {
-       return iio_ring_buffer_register(ring);
+       return iio_ring_buffer_register(ring, 0);
 }
 
 void adis16300_uninitialize_ring(struct iio_ring_buffer *ring)

Re: adis16300 to new abi

[Barry Song]

On Wed, Apr 28, 2010 at 7:17 AM, Jonathan Cameron <jic23@cam.ac.uk> wrote:
> On 04/27/10 04:20, Song, Barry wrote:
>> Drivers that passed debugging and testing on hardware can be pushed to m=
ainline. By now, ADIS16300 and ADIS16400 drivers are on the list.
>> But the problem is they are based on old abi, will you change codes to m=
atch new abi? If no, we can update codes after you merge the new abi into m=
ainline.
>>
>
> Hi Barry,
>
> I've just taken a quick look at the adis16300 driver. =C2=A0The following
> patch is all that is needed to get it to build against the abi patch set.
> (and touch wood it should still work, be it with an odd mix of abis)
>
> There are other changes to meet the abi, but they can be done via
> incremental patches after this one. =C2=A0They are all name changes (such=
 as
> addition of _raw to the inclination parameters) or additional parameters
> that would be needed by a general userspace interpreter (my
> drivers are missing some of these as well at the moment!). =C2=A0Also the=
re
> are a couple of additions to make to the abi documentation. =C2=A0All of =
these
> could be sorted by a nice clean patch set after the driver patch itself.
>
> Whilst we are here. =C2=A0Under what circumstances does userspace want to=
 reset
> the device manually? =C2=A0Unless there is a clear and common use for thi=
s, I'd
> be inclined to move that particular attribute definition into individual
> drivers.
>
> How do you want to do the actual patch? I could apply the following as
> a 'merge' fix to a clean patch from you, or I can put together a suitable
> hybrid of the two (from you of course). Obviously this would need you
> to take a quick glance and sign-off on it.
Thanks! I prefer you make a hybrid of the two since this patch will be
applied after your new abi is merged.
-barry
>
> Thanks,
>
> Jonathan
> ---
> diff --git a/drivers/staging/iio/imu/adis16300_core.c b/drivers/staging/i=
io/imu/adis16300_core.c
> index 8f84175..94ea2d1 100644
> --- a/drivers/staging/iio/imu/adis16300_core.c
> +++ b/drivers/staging/iio/imu/adis16300_core.c
> @@ -646,9 +646,9 @@ static struct attribute *adis16300_attributes[] =3D {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_const_attr_volt_supply_scale.dev_attr.att=
r,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_dev_attr_gyro_x.dev_attr.attr,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_const_attr_gyro_scale.dev_attr.attr,
> - =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_x.dev_attr.attr,
> - =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_y.dev_attr.attr,
> - =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_z.dev_attr.attr,
> + =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_x_raw.dev_attr.attr,
> + =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_y_raw.dev_attr.attr,
> + =C2=A0 =C2=A0 =C2=A0 &iio_dev_attr_accel_z_raw.dev_attr.attr,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_const_attr_accel_scale.dev_attr.attr,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_dev_attr_incli_x.dev_attr.attr,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_dev_attr_incli_y.dev_attr.attr,
> diff --git a/drivers/staging/iio/imu/adis16300_ring.c b/drivers/staging/i=
io/imu/adis16300_ring.c
> index 79298b3..76cf8a6 100644
> --- a/drivers/staging/iio/imu/adis16300_ring.c
> +++ b/drivers/staging/iio/imu/adis16300_ring.c
> @@ -49,7 +49,7 @@ static IIO_SCAN_EL_C(incli_x, ADIS16300_SCAN_INCLI_X, I=
IO_SIGNED(12),
> =C2=A0static IIO_SCAN_EL_C(incli_y, ADIS16300_SCAN_INCLI_Y, IIO_SIGNED(12=
),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ADI=
S16300_YINCLI_OUT, NULL);
>
> -static IIO_SCAN_EL_TIMESTAMP;
> +static IIO_SCAN_EL_TIMESTAMP(9);
>
> =C2=A0static struct attribute *adis16300_scan_el_attrs[] =3D {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0&iio_scan_el_supply.dev_attr.attr,
> @@ -224,7 +224,7 @@ error_iio_sw_rb_free:
>
> =C2=A0int adis16300_initialize_ring(struct iio_ring_buffer *ring)
> =C2=A0{
> - =C2=A0 =C2=A0 =C2=A0 return iio_ring_buffer_register(ring);
> + =C2=A0 =C2=A0 =C2=A0 return iio_ring_buffer_register(ring, 0);
> =C2=A0}
>
> =C2=A0void adis16300_uninitialize_ring(struct iio_ring_buffer *ring)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>

Re: adis16300 to new abi

[Jonathan Cameron]

Purely for the interested. Greg took the adis16300 and adis16400
drivers into staging-next yesterday.  There are a few corners to fix
but they will be done in an incremental patch.

Jonathan