On 2022-04-21 15:13, Christoph Hellwig wrote:
> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
>> Hi all,
>>
>> Thanks to Christoph's latest series, I'm reminded that, if we're going
>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
>> any to dust off these old patches and add them on top as well. I've
>> based these on the arm-dma-direct branch which I assume matches the
>> patches posted at [1].
>
> All these do look sensible to me. But weren't you working on replacing
> the ARM iommu dma_ops with dma-іommu anyway?
Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
probably get to the point of having to revisit it in a couple of months
or so. These patches are off the bottom of that stack from my first
attempt, where the aim was to make the current ops the same shape first
so that the switch is then easier to reason about (particularly in terms
of sounding out any issues with the hooking up of dev->dma_coherent,
although your series will now be taking most of the load off there).
Cheers,
Robin.
Hi, Robin, Christoph
With the changes landed in the mainline kernel,
one problem is exposed with our out of tree pvr module.
Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
the format like the following:
arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
DMA_FROM_DEVICE);
Not sure if you could give some suggestions on what I should do next
to make the pvr module work again.
Thanks in advance!
[1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
Thanks,
Yongqin Liu
On Thu, 21 Apr 2022 at 22:35, Robin Murphy <[email protected]> wrote:
>
> On 2022-04-21 15:13, Christoph Hellwig wrote:
> > On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
> >> Hi all,
> >>
> >> Thanks to Christoph's latest series, I'm reminded that, if we're going
> >> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
> >> any to dust off these old patches and add them on top as well. I've
> >> based these on the arm-dma-direct branch which I assume matches the
> >> patches posted at [1].
> >
> > All these do look sensible to me. But weren't you working on replacing
> > the ARM iommu dma_ops with dma-іommu anyway?
>
> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
> probably get to the point of having to revisit it in a couple of months
> or so. These patches are off the bottom of that stack from my first
> attempt, where the aim was to make the current ops the same shape first
> so that the switch is then easier to reason about (particularly in terms
> of sounding out any issues with the hooking up of dev->dma_coherent,
> although your series will now be taking most of the load off there).
>
> Cheers,
> Robin.
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
On 2022-08-27 13:24, Yongqin Liu wrote:
> Hi, Robin, Christoph
>
> With the changes landed in the mainline kernel,
> one problem is exposed with our out of tree pvr module.
> Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
> the format like the following:
> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> DMA_FROM_DEVICE);
>
> Not sure if you could give some suggestions on what I should do next
> to make the pvr module work again.
Wow, that driver reinvents so many standard APIs for no apparent reason
it's not even funny.
Anyway, from a brief look it seemingly already knows how to call the DMA
API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
However it's still so completely wrong in general - fundamentally broken
AArch64 set/way cache maintenance!? - that it looks largely beyond help.
"Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
support I'm prepared to provide for that mess.
Thanks,
Robin.
> Thanks in advance!
>
> [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
>
> Thanks,
> Yongqin Liu
>
> On Thu, 21 Apr 2022 at 22:35, Robin Murphy <[email protected]> wrote:
>>
>> On 2022-04-21 15:13, Christoph Hellwig wrote:
>>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
>>>> Hi all,
>>>>
>>>> Thanks to Christoph's latest series, I'm reminded that, if we're going
>>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
>>>> any to dust off these old patches and add them on top as well. I've
>>>> based these on the arm-dma-direct branch which I assume matches the
>>>> patches posted at [1].
>>>
>>> All these do look sensible to me. But weren't you working on replacing
>>> the ARM iommu dma_ops with dma-іommu anyway?
>>
>> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
>> probably get to the point of having to revisit it in a couple of months
>> or so. These patches are off the bottom of that stack from my first
>> attempt, where the aim was to make the current ops the same shape first
>> so that the switch is then easier to reason about (particularly in terms
>> of sounding out any issues with the hooking up of dev->dma_coherent,
>> although your series will now be taking most of the load off there).
>>
>> Cheers,
>> Robin.
>
>
>
Hi, Robin
Thanks for the kind reply!
On Tue, 30 Aug 2022 at 17:48, Robin Murphy <[email protected]> wrote:
>
> On 2022-08-27 13:24, Yongqin Liu wrote:
> > Hi, Robin, Christoph
> >
> > With the changes landed in the mainline kernel,
> > one problem is exposed with our out of tree pvr module.
> > Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
> > the format like the following:
> > arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> > DMA_FROM_DEVICE);
> >
> > Not sure if you could give some suggestions on what I should do next
> > to make the pvr module work again.
>
> Wow, that driver reinvents so many standard APIs for no apparent reason
> it's not even funny.
>
> Anyway, from a brief look it seemingly already knows how to call the DMA
> API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
> However it's still so completely wrong in general - fundamentally broken
> AArch64 set/way cache maintenance!? - that it looks largely beyond help.
> "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
> support I'm prepared to provide for that mess.
For the moment, I do not care about the AArch64 lines, like if we only
say the following two lines:
arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
DMA_TO_DEVICE);
arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
DMA_FROM_DEVICE);
Could you please give some suggestions for that?
Thanks,
Yongqin Liu
> > Thanks in advance!
> >
> > [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
> >
> > Thanks,
> > Yongqin Liu
> >
> > On Thu, 21 Apr 2022 at 22:35, Robin Murphy <[email protected]> wrote:
> >>
> >> On 2022-04-21 15:13, Christoph Hellwig wrote:
> >>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
> >>>> Hi all,
> >>>>
> >>>> Thanks to Christoph's latest series, I'm reminded that, if we're going
> >>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
> >>>> any to dust off these old patches and add them on top as well. I've
> >>>> based these on the arm-dma-direct branch which I assume matches the
> >>>> patches posted at [1].
> >>>
> >>> All these do look sensible to me. But weren't you working on replacing
> >>> the ARM iommu dma_ops with dma-іommu anyway?
> >>
> >> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
> >> probably get to the point of having to revisit it in a couple of months
> >> or so. These patches are off the bottom of that stack from my first
> >> attempt, where the aim was to make the current ops the same shape first
> >> so that the switch is then easier to reason about (particularly in terms
> >> of sounding out any issues with the hooking up of dev->dma_coherent,
> >> although your series will now be taking most of the load off there).
> >>
> >> Cheers,
> >> Robin.
> >
> >
> >
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
On 2022-08-30 16:19, Yongqin Liu wrote:
> Hi, Robin
>
> Thanks for the kind reply!
>
> On Tue, 30 Aug 2022 at 17:48, Robin Murphy <[email protected]> wrote:
>>
>> On 2022-08-27 13:24, Yongqin Liu wrote:
>>> Hi, Robin, Christoph
>>>
>>> With the changes landed in the mainline kernel,
>>> one problem is exposed with our out of tree pvr module.
>>> Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
>>> the format like the following:
>>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
>>> DMA_FROM_DEVICE);
>>>
>>> Not sure if you could give some suggestions on what I should do next
>>> to make the pvr module work again.
>>
>> Wow, that driver reinvents so many standard APIs for no apparent reason
>> it's not even funny.
>>
>> Anyway, from a brief look it seemingly already knows how to call the DMA
>> API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
>> However it's still so completely wrong in general - fundamentally broken
>> AArch64 set/way cache maintenance!? - that it looks largely beyond help.
>> "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
>> support I'm prepared to provide for that mess.
>
> For the moment, I do not care about the AArch64 lines, like if we only
> say the following two lines:
> arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
> DMA_TO_DEVICE);
> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> DMA_FROM_DEVICE);
>
> Could you please give some suggestions for that?
Remove them. Then remove the #ifdef __arch64__ too, since the code under
there is doing a passable impression of generic DMA API usage, as long
as one ignores the bigger picture.
arm64 already uses dma-direct. To say you don't care about the arm64
code when asking how to deal with ARM having now been converted to use
dma-direct as well is supremely missing the point.
Robin.
>
> Thanks,
> Yongqin Liu
>
>
>>> Thanks in advance!
>>>
>>> [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
>>>
>>> Thanks,
>>> Yongqin Liu
>>>
>>> On Thu, 21 Apr 2022 at 22:35, Robin Murphy <[email protected]> wrote:
>>>>
>>>> On 2022-04-21 15:13, Christoph Hellwig wrote:
>>>>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Thanks to Christoph's latest series, I'm reminded that, if we're going
>>>>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
>>>>>> any to dust off these old patches and add them on top as well. I've
>>>>>> based these on the arm-dma-direct branch which I assume matches the
>>>>>> patches posted at [1].
>>>>>
>>>>> All these do look sensible to me. But weren't you working on replacing
>>>>> the ARM iommu dma_ops with dma-іommu anyway?
>>>>
>>>> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
>>>> probably get to the point of having to revisit it in a couple of months
>>>> or so. These patches are off the bottom of that stack from my first
>>>> attempt, where the aim was to make the current ops the same shape first
>>>> so that the switch is then easier to reason about (particularly in terms
>>>> of sounding out any issues with the hooking up of dev->dma_coherent,
>>>> although your series will now be taking most of the load off there).
>>>>
>>>> Cheers,
>>>> Robin.
>>>
>>>
>>>
>
>
>
Hi, Robin
On Tue, 30 Aug 2022 at 23:37, Robin Murphy <[email protected]> wrote:
>
> On 2022-08-30 16:19, Yongqin Liu wrote:
> > Hi, Robin
> >
> > Thanks for the kind reply!
> >
> > On Tue, 30 Aug 2022 at 17:48, Robin Murphy <[email protected]> wrote:
> >>
> >> On 2022-08-27 13:24, Yongqin Liu wrote:
> >>> Hi, Robin, Christoph
> >>>
> >>> With the changes landed in the mainline kernel,
> >>> one problem is exposed with our out of tree pvr module.
> >>> Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
> >>> the format like the following:
> >>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> >>> DMA_FROM_DEVICE);
> >>>
> >>> Not sure if you could give some suggestions on what I should do next
> >>> to make the pvr module work again.
> >>
> >> Wow, that driver reinvents so many standard APIs for no apparent reason
> >> it's not even funny.
> >>
> >> Anyway, from a brief look it seemingly already knows how to call the DMA
> >> API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
> >> However it's still so completely wrong in general - fundamentally broken
> >> AArch64 set/way cache maintenance!? - that it looks largely beyond help.
> >> "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
> >> support I'm prepared to provide for that mess.
> >
> > For the moment, I do not care about the AArch64 lines, like if we only
> > say the following two lines:
> > arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
> > DMA_TO_DEVICE);
> > arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> > DMA_FROM_DEVICE);
> >
> > Could you please give some suggestions for that?
>
> Remove them. Then remove the #ifdef __arch64__ too, since the code under
> there is doing a passable impression of generic DMA API usage, as long
> as one ignores the bigger picture.
I tried with this method, and found that if I only update for the
pvr_flush_range
and the pvr_clean_range functions, the build still could boot to the
home screen.
but if I update all the pvr_flush_range, pvr_clean_range and
pvr_invalidate_range
functions with this method(remove the arm_dma_ops lines and the #ifdef
__arch64__ lines),
then a "Unable to handle kernel NULL pointer dereference at virtual
address 0000003c"
error is reported like here: http://ix.io/49gu
Not sure if you have any idea from the log, or could you please give
some suggestions
on how to debug it.
> arm64 already uses dma-direct. To say you don't care about the arm64
> code when asking how to deal with ARM having now been converted to use
> dma-direct as well is supremely missing the point.
Sorry for that, I am not familiar with the dma part, and just know
"dma-direct" from here,
will check how "dma-direct" should be used next, and check if there is
something wrong in
the pvr source code.
It would be appreciated if you could suggest some links on
"dma-direct" I can study with.
Thanks,
Yongqin Liu
> >
> >
> >>> Thanks in advance!
> >>>
> >>> [1]: https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n4615
> >>>
> >>> Thanks,
> >>> Yongqin Liu
> >>>
> >>> On Thu, 21 Apr 2022 at 22:35, Robin Murphy <[email protected]> wrote:
> >>>>
> >>>> On 2022-04-21 15:13, Christoph Hellwig wrote:
> >>>>> On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
> >>>>>> Hi all,
> >>>>>>
> >>>>>> Thanks to Christoph's latest series, I'm reminded that, if we're going
> >>>>>> to give the ARM DMA ops some cleanup this cycle, it's as good a time as
> >>>>>> any to dust off these old patches and add them on top as well. I've
> >>>>>> based these on the arm-dma-direct branch which I assume matches the
> >>>>>> patches posted at [1].
> >>>>>
> >>>>> All these do look sensible to me. But weren't you working on replacing
> >>>>> the ARM iommu dma_ops with dma-іommu anyway?
> >>>>
> >>>> Yes, that's somewhat entangled with the IOMMU bus ops stuff, so I'll
> >>>> probably get to the point of having to revisit it in a couple of months
> >>>> or so. These patches are off the bottom of that stack from my first
> >>>> attempt, where the aim was to make the current ops the same shape first
> >>>> so that the switch is then easier to reason about (particularly in terms
> >>>> of sounding out any issues with the hooking up of dev->dma_coherent,
> >>>> although your series will now be taking most of the load off there).
> >>>>
> >>>> Cheers,
> >>>> Robin.
> >>>
> >>>
> >>>
> >
> >
> >
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android
On 2022-08-31 17:41, Yongqin Liu wrote:
> Hi, Robin
>
> On Tue, 30 Aug 2022 at 23:37, Robin Murphy <[email protected]> wrote:
>>
>> On 2022-08-30 16:19, Yongqin Liu wrote:
>>> Hi, Robin
>>>
>>> Thanks for the kind reply!
>>>
>>> On Tue, 30 Aug 2022 at 17:48, Robin Murphy <[email protected]> wrote:
>>>>
>>>> On 2022-08-27 13:24, Yongqin Liu wrote:
>>>>> Hi, Robin, Christoph
>>>>>
>>>>> With the changes landed in the mainline kernel,
>>>>> one problem is exposed with our out of tree pvr module.
>>>>> Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
>>>>> the format like the following:
>>>>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
>>>>> DMA_FROM_DEVICE);
>>>>>
>>>>> Not sure if you could give some suggestions on what I should do next
>>>>> to make the pvr module work again.
>>>>
>>>> Wow, that driver reinvents so many standard APIs for no apparent reason
>>>> it's not even funny.
>>>>
>>>> Anyway, from a brief look it seemingly already knows how to call the DMA
>>>> API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
>>>> However it's still so completely wrong in general - fundamentally broken
>>>> AArch64 set/way cache maintenance!? - that it looks largely beyond help.
>>>> "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
>>>> support I'm prepared to provide for that mess.
>>>
>>> For the moment, I do not care about the AArch64 lines, like if we only
>>> say the following two lines:
>>> arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
>>> DMA_TO_DEVICE);
>>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
>>> DMA_FROM_DEVICE);
>>>
>>> Could you please give some suggestions for that?
>>
>> Remove them. Then remove the #ifdef __arch64__ too, since the code under
>> there is doing a passable impression of generic DMA API usage, as long
>> as one ignores the bigger picture.
>
> I tried with this method, and found that if I only update for the
> pvr_flush_range
> and the pvr_clean_range functions, the build still could boot to the
> home screen.
>
> but if I update all the pvr_flush_range, pvr_clean_range and
> pvr_invalidate_range
> functions with this method(remove the arm_dma_ops lines and the #ifdef
> __arch64__ lines),
> then a "Unable to handle kernel NULL pointer dereference at virtual
> address 0000003c"
> error is reported like here: http://ix.io/49gu
>
> Not sure if you have any idea from the log, or could you please give
> some suggestions
> on how to debug it.
Obviously there's almost certainly going to be more work to do on top to
make the newly-exposed codepath actually behave as expected - I was
simply making a general suggestion for a starting point based on looking
at half a dozen lines of code in isolation.
To restate the point yet again in the hope that it's clear this time,
the DMA ops on ARM are now effectively the same as the DMA ops on arm64,
and will behave the same way. Assuming the driver already works on
arm64, then the aim should be to unify all the ARM and arm64 codepaths
for things that involve the DMA API. If you don't understand the code
well enough to do that, please contact Imagination; I don't support
their driver.
Thanks,
Robin.
Hi, Robin
On Thu, 1 Sept 2022 at 01:10, Robin Murphy <[email protected]> wrote:
>
> On 2022-08-31 17:41, Yongqin Liu wrote:
> > Hi, Robin
> >
> > On Tue, 30 Aug 2022 at 23:37, Robin Murphy <[email protected]> wrote:
> >>
> >> On 2022-08-30 16:19, Yongqin Liu wrote:
> >>> Hi, Robin
> >>>
> >>> Thanks for the kind reply!
> >>>
> >>> On Tue, 30 Aug 2022 at 17:48, Robin Murphy <[email protected]> wrote:
> >>>>
> >>>> On 2022-08-27 13:24, Yongqin Liu wrote:
> >>>>> Hi, Robin, Christoph
> >>>>>
> >>>>> With the changes landed in the mainline kernel,
> >>>>> one problem is exposed with our out of tree pvr module.
> >>>>> Like the source here[1], arm_dma_ops.sync_single_for_cpu is called in
> >>>>> the format like the following:
> >>>>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> >>>>> DMA_FROM_DEVICE);
> >>>>>
> >>>>> Not sure if you could give some suggestions on what I should do next
> >>>>> to make the pvr module work again.
> >>>>
> >>>> Wow, that driver reinvents so many standard APIs for no apparent reason
> >>>> it's not even funny.
> >>>>
> >>>> Anyway, from a brief look it seemingly already knows how to call the DMA
> >>>> API semi-correctly, so WTF that's doing behind an #ifdef, who knows?
> >>>> However it's still so completely wrong in general - fundamentally broken
> >>>> AArch64 set/way cache maintenance!? - that it looks largely beyond help.
> >>>> "Throw CONFIG_DMA_API_DEBUG at it and cry" is about the extent of
> >>>> support I'm prepared to provide for that mess.
> >>>
> >>> For the moment, I do not care about the AArch64 lines, like if we only
> >>> say the following two lines:
> >>> arm_dma_ops.sync_single_for_device(NULL, pStart, pEnd - pStart,
> >>> DMA_TO_DEVICE);
> >>> arm_dma_ops.sync_single_for_cpu(NULL, pStart, pEnd - pStart,
> >>> DMA_FROM_DEVICE);
> >>>
> >>> Could you please give some suggestions for that?
> >>
> >> Remove them. Then remove the #ifdef __arch64__ too, since the code under
> >> there is doing a passable impression of generic DMA API usage, as long
> >> as one ignores the bigger picture.
> >
> > I tried with this method, and found that if I only update for the
> > pvr_flush_range
> > and the pvr_clean_range functions, the build still could boot to the
> > home screen.
> >
> > but if I update all the pvr_flush_range, pvr_clean_range and
> > pvr_invalidate_range
> > functions with this method(remove the arm_dma_ops lines and the #ifdef
> > __arch64__ lines),
> > then a "Unable to handle kernel NULL pointer dereference at virtual
> > address 0000003c"
> > error is reported like here: http://ix.io/49gu
> >
> > Not sure if you have any idea from the log, or could you please give
> > some suggestions
> > on how to debug it.
>
> Obviously there's almost certainly going to be more work to do on top to
> make the newly-exposed codepath actually behave as expected - I was
> simply making a general suggestion for a starting point based on looking
> at half a dozen lines of code in isolation.
>
> To restate the point yet again in the hope that it's clear this time,
> the DMA ops on ARM are now effectively the same as the DMA ops on arm64,
> and will behave the same way.
Thanks for confirming again here!
> Assuming the driver already works on
> arm64, then the aim should be to unify all the ARM and arm64 codepaths
> for things that involve the DMA API.
Thanks for the suggestion here, I will try to see if I could find
anything there.
> If you don't understand the code
> well enough to do that, please contact Imagination; I don't support
> their driver.
Will try to contact the maintainer of the PVR source, but as you could guess,
it might take quite a long time before it's fixed in the perfect way,
and before that
I need to have the build continue even with various workarounds based
on my limited undersanding:(
Thanks again for all the kind help and suggestions!
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-android