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
>>
>>
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
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
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 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
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,
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
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
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
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
On Wednesday 18 December 2013, Sergei Ianovich wrote:
> > You would still be able to boot a kernel with an old dts file on a new
> > kernel if it just contains a "simple-bus" node here, as long as it doesn't
> > need any boot-time setup at the bus controller. We can change the dts
> > file later
On Wed, 2013-12-18 at 22:10 +0100, Arnd Bergmann wrote:
> On Wednesday 18 December 2013, Sergei Ianovich wrote:
> > Could we postpone this until someone needs this functionality?
>
> We have to be sure that any device tree files you write now can remain
> compatible with future kernels if we add
On Wednesday 18 December 2013, Sergei Ianovich wrote:
> > Hmm, this is a bit tricky then. I think it would be best to not
> > use "simple-bus" then, to allow migrating the other platforms later,
> > but that will be a little more work. Maybe you can register a trivial
> > driver in the platform
On Wed, 2013-12-18 at 21:50 +0100, Arnd Bergmann wrote:
> > This is a platform-specific bus (PXA27x). Should it go into pxa27x.dtsi
> > rather than machine dts?
>
> Yes, that was the idea.
Great.
> > There seems to be none at the moment. However, some machines need to
> > setup these partitions
On Monday 16 December 2013, Sergei Ianovich wrote:
> On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote:
> > Ok, I see. This sounds like some of the other platforms we have with
> > external memory buses. If there is a chance that Linux ever has to
> > program the per-CS settings into the bus
On Monday 16 December 2013, Sergei Ianovich wrote:
On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote:
Ok, I see. This sounds like some of the other platforms we have with
external memory buses. If there is a chance that Linux ever has to
program the per-CS settings into the bus
On Wed, 2013-12-18 at 21:50 +0100, Arnd Bergmann wrote:
This is a platform-specific bus (PXA27x). Should it go into pxa27x.dtsi
rather than machine dts?
Yes, that was the idea.
Great.
There seems to be none at the moment. However, some machines need to
setup these partitions as a part
On Wednesday 18 December 2013, Sergei Ianovich wrote:
Hmm, this is a bit tricky then. I think it would be best to not
use simple-bus then, to allow migrating the other platforms later,
but that will be a little more work. Maybe you can register a trivial
driver in the platform code that
On Wed, 2013-12-18 at 22:10 +0100, Arnd Bergmann wrote:
On Wednesday 18 December 2013, Sergei Ianovich wrote:
Could we postpone this until someone needs this functionality?
We have to be sure that any device tree files you write now can remain
compatible with future kernels if we add it
On Wednesday 18 December 2013, Sergei Ianovich wrote:
You would still be able to boot a kernel with an old dts file on a new
kernel if it just contains a simple-bus node here, as long as it doesn't
need any boot-time setup at the bus controller. We can change the dts
file later if we need
On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote:
> Ok, I see. This sounds like some of the other platforms we have with
> external memory buses. If there is a chance that Linux ever has to
> program the per-CS settings into the bus controller, I would suggest
> to represent that as well as
On Monday 16 December 2013, Sergei Ianovich wrote:
> PXA27x memory bus can have up to 10 devices: up to 6 slower
> flash/SRAM/variable-latency-IO selected by nCS<0> to <5>, and up to 4
> partions of SDRAM selected by nSDCS<0> to <3>.
>
> It appears that the FPGA is directly connected to the
On Sun, 2013-12-15 at 03:55 +0100, Arnd Bergmann wrote:
> On Sunday 15 December 2013, Sergei Ianovich wrote:
> ...
> I think the way you have structured your code is good, and an MFD would
> not help. Please just restructure the DT representation to contain the
> external-bus and/or the fpga
On Sun, 2013-12-15 at 03:55 +0100, Arnd Bergmann wrote:
On Sunday 15 December 2013, Sergei Ianovich wrote:
...
I think the way you have structured your code is good, and an MFD would
not help. Please just restructure the DT representation to contain the
external-bus and/or the fpga connected
On Monday 16 December 2013, Sergei Ianovich wrote:
PXA27x memory bus can have up to 10 devices: up to 6 slower
flash/SRAM/variable-latency-IO selected by nCS0 to 5, and up to 4
partions of SDRAM selected by nSDCS0 to 3.
It appears that the FPGA is directly connected to the memory bus and is
On Mon, 2013-12-16 at 18:56 +0100, Arnd Bergmann wrote:
Ok, I see. This sounds like some of the other platforms we have with
external memory buses. If there is a chance that Linux ever has to
program the per-CS settings into the bus controller, I would suggest
to represent that as well as a
On Sunday 15 December 2013, Sergei Ianovich wrote:
> On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
> > On Saturday 14 December 2013, Sergei Ianovich wrote:
> > Unfortunately I don't have a good way to judge the tradeoffs without
> > understanding more about the design of the hardware.
On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
> On Saturday 14 December 2013, Sergei Ianovich wrote:
> > There are basically 2 options: one-for-all mfd device and one-for-one
> > device drivers.
> >
> > MFD
> > pros:
> > * easy to add into the tree (one file)
> > * easy config (one
On Saturday 14 December 2013, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> > On Friday 13 December 2013, Sergei Ianovich wrote:
> > > I've also decided not to create a single mfd device for
> > > machine-specific devices. Instead each type is supported by a
On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> On Friday 13 December 2013, Sergei Ianovich wrote:
> > I've also decided not to create a single mfd device for
> > machine-specific devices. Instead each type is supported by a separate
> > driver in respective subsystem. It was tempting to
On Friday 13 December 2013, Sergei Ianovich wrote:
> Fixed most review requirements. Details in respective patches.
>
> I've completely met the requirement for using dmaengine-based DMA
> in patch v2-03/16. Tests showed new DMA was underperforming. It added
> on top of a pre-existing problem with
On Friday 13 December 2013, Sergei Ianovich wrote:
Fixed most review requirements. Details in respective patches.
I've completely met the requirement for using dmaengine-based DMA
in patch v2-03/16. Tests showed new DMA was underperforming. It added
on top of a pre-existing problem with MMC
On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
On Friday 13 December 2013, Sergei Ianovich wrote:
I've also decided not to create a single mfd device for
machine-specific devices. Instead each type is supported by a separate
driver in respective subsystem. It was tempting to
On Saturday 14 December 2013, Sergei Ianovich wrote:
On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
On Friday 13 December 2013, Sergei Ianovich wrote:
I've also decided not to create a single mfd device for
machine-specific devices. Instead each type is supported by a separate
On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
On Saturday 14 December 2013, Sergei Ianovich wrote:
There are basically 2 options: one-for-all mfd device and one-for-one
device drivers.
MFD
pros:
* easy to add into the tree (one file)
* easy config (one option)
On Sunday 15 December 2013, Sergei Ianovich wrote:
On Sun, 2013-12-15 at 01:53 +0100, Arnd Bergmann wrote:
On Saturday 14 December 2013, Sergei Ianovich wrote:
Unfortunately I don't have a good way to judge the tradeoffs without
understanding more about the design of the hardware. Did I
On Fri, 2013-12-13 at 06:27 +0400, Sergei Ianovich wrote:
> Fixed most review requirements. Details in respective patches.
>
> I've completely met the requirement for using dmaengine-based DMA
> in patch v2-03/16. Tests showed new DMA was underperforming. It added
> on top of a pre-existing
Fixed most review requirements. Details in respective patches.
I've completely met the requirement for using dmaengine-based DMA
in patch v2-03/16. Tests showed new DMA was underperforming. It added
on top of a pre-existing problem with MMC bus width and made the system
barely usable. However,
Fixed most review requirements. Details in respective patches.
I've completely met the requirement for using dmaengine-based DMA
in patch v2-03/16. Tests showed new DMA was underperforming. It added
on top of a pre-existing problem with MMC bus width and made the system
barely usable. However,
On Fri, 2013-12-13 at 06:27 +0400, Sergei Ianovich wrote:
Fixed most review requirements. Details in respective patches.
I've completely met the requirement for using dmaengine-based DMA
in patch v2-03/16. Tests showed new DMA was underperforming. It added
on top of a pre-existing problem
40 matches
Mail list logo
