From: Marcin Wojtas
Date: Tue, 8 Dec 2015 11:56:28 +0100
> Do you think you can point to anything similar that could be a sort
> of reference for such solution?
I don't have much time to explain because I'm constantly backlogged doing
patch review, but mostly it has to do with page management an
Hi David,
2015-12-04 21:15 GMT+01:00 Florian Fainelli :
> (no top posting please)
>
> On 02/12/15 00:26, Marcin Wojtas wrote:
>> Hi Florian,
>>
>> Can you please describe in more details, what would you expect from
>> such special abstraction layer regarding buffer managers? I'd like to
>> underst
(no top posting please)
On 02/12/15 00:26, Marcin Wojtas wrote:
> Hi Florian,
>
> Can you please describe in more details, what would you expect from
> such special abstraction layer regarding buffer managers? I'd like to
> understand more of your expectations and evaluate possible work.
Well, s
Hi Marcin,
On mer., déc. 02 2015, Marcin Wojtas wrote:
>>>
2. Change condition in mvebu_mbus_get_dram_win_info to:
if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size -1))
>>>
>>> I think it would be the best solution.
>>
>> So I applied the following patch:
>> --- a/drivers/bu
Hi Gregory,
2015-12-02 17:21 GMT+01:00 Gregory CLEMENT :
> Hi,
>
> On mer., déc. 02 2015, Gregory CLEMENT
> wrote:
>
>>>
>>> So far the issue may have been not noticed, because in every IO driver
>>> using mvebu_mbus_dram_info for configuring MBUS windows, there's
>>> following substraction:
>>
Hi,
On mer., déc. 02 2015, Gregory CLEMENT
wrote:
>>
>> So far the issue may have been not noticed, because in every IO driver
>> using mvebu_mbus_dram_info for configuring MBUS windows, there's
>> following substraction:
>> (cs->size - 1) & 0xf000
>>
>> I think there are two options:
>>
Hi Marcin,
On mer., déc. 02 2015, Marcin Wojtas wrote:
> Gregory,
>
> Please apply below patch:
> http://pastebin.com/t42xyU3i
> It will confirm if there's an overflow for CS0 size in your setup.
> Please let know.
Indeed it is an overflow. In v4.0 the size was correct because it was no
longe
Hi Florian,
Can you please describe in more details, what would you expect from
such special abstraction layer regarding buffer managers? I'd like to
understand more of your expectations and evaluate possible work.
Best regards,
Marcin
2015-11-30 17:25 GMT+01:00 David Miller :
> From: Marcin Woj
Gregory,
Please apply below patch:
http://pastebin.com/t42xyU3i
It will confirm if there's an overflow for CS0 size in your setup.
Please let know.
So far the issue may have been not noticed, because in every IO driver
using mvebu_mbus_dram_info for configuring MBUS windows, there's
following sub
Hi Gregory,
Thanks for the log. I think it may be an overall problem with 4GB size
representation in mvebu_mbus_dram_info structure? Maybe whole DRAM
space is associated to CS0, and the 4GB size (0x1 ) does not
fit u32 variable?
Best regards,
Marcin
2015-12-01 14:12 GMT+01:00 Gregory CL
Hi Marcin,
On lun., nov. 30 2015, Marcin Wojtas wrote:
[...]
>>> 5. Enable BM on Armada XP and 38X development boards - those ones and
>>> A370 I could check on my own. In all cases they survived night-long
>>> linerate iperf. Also tests were performed with A388 SoC working as a
>>> network bri
Hi Gregory,
2015-11-30 18:16 GMT+01:00 Gregory CLEMENT :
> Hi Marcin,
>
> On dim., nov. 22 2015, Marcin Wojtas wrote:
>
>> Hi,
>>
>> Hereby I submit a patchset that introduces various fixes and support
>> for new features and enhancements to the mvneta driver:
>>
>> 1. First three patches are mi
Hi Marcin,
On dim., nov. 22 2015, Marcin Wojtas wrote:
> Hi,
>
> Hereby I submit a patchset that introduces various fixes and support
> for new features and enhancements to the mvneta driver:
>
> 1. First three patches are minimal fixes, stable-CC'ed.
>
> 2. Suspend to ram ('s2ram') support. D
From: Marcin Wojtas
Date: Mon, 30 Nov 2015 15:13:22 +0100
> What kind of abstraction and helpers do you mean? Some kind of API
> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
> bm_get_buffer), which would be used by platform drivers (and specific
> aplications if one wants to develop o
Hi David and Florian,
2015-11-30 3:02 GMT+01:00 David Miller :
> From: Marcin Wojtas
> Date: Sun, 29 Nov 2015 14:21:35 +0100
>
>>> Looking at your patches, it was not entirely clear to me how the buffer
>>> manager on these Marvell SoCs work, but other networking products have
>>> something simil
From: Marcin Wojtas
Date: Sun, 29 Nov 2015 14:21:35 +0100
>> Looking at your patches, it was not entirely clear to me how the buffer
>> manager on these Marvell SoCs work, but other networking products have
>> something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and
>> maybe Freesca
Hi Florian,
>
> Looking at your patches, it was not entirely clear to me how the buffer
> manager on these Marvell SoCs work, but other networking products have
> something similar, like Broadcom's Cable Modem SoCs (BCM33xx) FPM, and
> maybe Freescale's FMAN/DPAA seems to do something similar.
>
>
On 21/11/15 23:53, Marcin Wojtas wrote:
>
> 4. Buffer manager (BM) support with two preparatory commits. As it is a
> separate block, common for all network ports, a new driver is introduced,
> which configures it and exposes API to the main network driver. It is
> throughly described in binding d
Hi David,
Thanks for the remark. I will do the split and re-submit.
Best regards,
Marcin
2015-11-24 17:22 GMT+01:00 David Miller :
>
> This patch series has a lot of problems.
>
> The worst one is that you are mixing bug fixes and new
> features/cleanups.
>
> You cannot do that.
>
> You _especia
This patch series has a lot of problems.
The worst one is that you are mixing bug fixes and new
features/cleanups.
You cannot do that.
You _especially_ can't do that if you expect some of this stuff
to be submitted to -stable too.
Therefore you _must_ extract out the bug fixes, and submit thos
Arnd,
2015-11-22 21:06 GMT+01:00 Arnd Bergmann :
> On Sunday 22 November 2015 08:53:46 Marcin Wojtas wrote:
>>
>> 3. Optimisations - concatenating TX descriptors' flush, basing on
>> xmit_more support and combined approach for finalizing egress processing.
>> Thanks to HR timer buffers can be rele
On Sunday 22 November 2015 08:53:46 Marcin Wojtas wrote:
>
> 3. Optimisations - concatenating TX descriptors' flush, basing on
> xmit_more support and combined approach for finalizing egress processing.
> Thanks to HR timer buffers can be released with small latency, which is
> good for low transf
Hi,
Hereby I submit a patchset that introduces various fixes and support
for new features and enhancements to the mvneta driver:
1. First three patches are minimal fixes, stable-CC'ed.
2. Suspend to ram ('s2ram') support. Due to some stability problems
Thomas Petazzoni's patches did not get merg
23 matches
Mail list logo
