On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote:
> This would work only if we can probe the devices behind the external
> bus controller before the controller itsef has been set up, since
> the initialization order can depend on a number of things but not
> the bus hierarchy. It will also work if the code setting up the
> bus controller can be guaranteed to run before we call
> of_platform_populate for the regular devices, which is probably
> the best solution here.
There has been no activity for 3 weeks. Could we resume the series?
On Fri, 2014-01-10 at 03:12 +0400, Sergei Ianovich wrote:
> On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote:
> > This would work only if we can probe the devices behind the external
> > bus controller before the controller itsef has been set up, since
> > the initialization order can depend on a number of things but not
> > the bus hierarchy. It will also work if the code setting up the
> > bus controller can be guaranteed to run before we call
> > of_platform_populate for the regular devices, which is probably
> > the best solution here.
>
> There has been no activity for 3 weeks. Could we resume the series?
It's over a month now. Is anything wrong?
On 01/20/2014 05:08 PM, Sergei Ianovich wrote:
> On Fri, 2014-01-10 at 03:12 +0400, Sergei Ianovich wrote:
>> On Thu, 2013-12-19 at 06:30 +0100, Arnd Bergmann wrote:
>>> This would work only if we can probe the devices behind the external
>>> bus controller before the controller itsef has been set up, since
>>> the initialization order can depend on a number of things but not
>>> the bus hierarchy. It will also work if the code setting up the
>>> bus controller can be guaranteed to run before we call
>>> of_platform_populate for the regular devices, which is probably
>>> the best solution here.
>>
>> There has been no activity for 3 weeks. Could we resume the series?
>
> It's over a month now. Is anything wrong?
>
No, I'm busy, that's all.
That said, the current situation is
a) we need someone to have a look at the performance regression of the
MMC file system layer that you reported. I couldn't find a PXA-based
board yet with a MMC slot soldered on it. But as you apparently have
such hardware, I'd really appreciate your help here. Could you do some
measurements and see whether you see major differences in packet size or
timings?
b) Marek Vasut thankfully reported back to me and signaled success with
his pxa-pata driver. So we're most probably good in that area.
c) Robert Jarzmik is still in the process of converting the camera
driver. Here as well, I lack hardware, I can't even compile-test
anything here.
So please, if you have any spare time, have a look at the MMC
regressions and see if you can contribute anything. I'll hope to find
some time to rebase my patches on top of 3.13 very soon, so we have a
new base to work on.
Thanks,
Daniel
On Mon, 2014-01-20 at 17:20 +0100, Daniel Mack wrote:
> On 01/20/2014 05:08 PM, Sergei Ianovich wrote:
> > It's over a month now. Is anything wrong?
> No, I'm busy, that's all.
Thanks for reply.
> That said, the current situation is
>
> a) we need someone to have a look at the performance regression of the
> MMC file system layer that you reported. I couldn't find a PXA-based
> board yet with a MMC slot soldered on it. But as you apparently have
> such hardware, I'd really appreciate your help here. Could you do some
> measurements and see whether you see major differences in packet size or
> timings?
I have the hardware with MMC, but none of the other devices. Could you
give some pointer where to start? How would you do measurements?
(...)
> So please, if you have any spare time, have a look at the MMC
> regressions and see if you can contribute anything. I'll hope to find
> some time to rebase my patches on top of 3.13 very soon, so we have a
> new base to work on.
It would be nice to have updated patches. Most interesting is whether
the new DMA still works as expected for other devices.
Apart from that, would mind if my series is landed with a workaround
(Patch v3 7/21). I hope you understand it doesn't feel good to depend on
something with no development activity.
On 01/20/2014 05:52 PM, Sergei Ianovich wrote:
> On Mon, 2014-01-20 at 17:20 +0100, Daniel Mack wrote:
>> On 01/20/2014 05:08 PM, Sergei Ianovich wrote:
>>> It's over a month now. Is anything wrong?
>> No, I'm busy, that's all.
>
> Thanks for reply.
>
>> That said, the current situation is
>>
>> a) we need someone to have a look at the performance regression of the
>> MMC file system layer that you reported. I couldn't find a PXA-based
>> board yet with a MMC slot soldered on it. But as you apparently have
>> such hardware, I'd really appreciate your help here. Could you do some
>> measurements and see whether you see major differences in packet size or
>> timings?
>
> I have the hardware with MMC, but none of the other devices. Could you
> give some pointer where to start? How would you do measurements?
Please check whether the DMA engine transfers data in chunks of
comparable size in both cases. Also, take time stamps when the packet is
submitted, and calculate the delta when the transfer returns. See if any
significant time gap contributes to the regression you see.
After all, it's still quite possible that the DMA driver has performance
bottlenecks. We need to find the code where so much more time is spent
with the new implementation.
> It would be nice to have updated patches. Most interesting is whether
> the new DMA still works as expected for other devices.
I'll allocate a time slot for that :)
> Apart from that, would mind if my series is landed with a workaround
> (Patch v3 7/21). I hope you understand it doesn't feel good to depend on
> something with no development activity.
I understand, but that shouldn't keep you you from maintaining a patch
stack out-of-tree until things are in shape enough to go mainline.
Thanks for you help,
Daniel