netdev - Re: [PATCH 5/6] stmmac: configure burst related GMAC DMA parameters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F56FD99.4040702@st.com>
Date:	Wed, 7 Mar 2012 11:48:01 +0530
From:	deepaksi <deepak.sikri@...com>
To:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
Cc:	spear-devel <spear-devel@...t.st.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	Vikas MANOCHA <vikas.manocha@...com>
Subject: Re: [PATCH 5/6] stmmac: configure burst related GMAC DMA parameters

Hellp Giuseppe,

>
> bit 24 in the Bus Mode Register represents the 8xPBL in databooks newer
> than the 3.50a. In older databook it is 4xPBL.
> So maybe, the DMA_BUS_MODE_4PBL define should be renamed as
> DMA_BUS_PBL_MODE (to be more generic and surrounded by a nice comment
> that details its meaning for different devices).
>
> but ...

Ok, will do that

>> @@ -56,6 +56,18 @@ static int dwmac1000_dma_init(void __iomem *ioaddr, int pbl, u32 dma_tx,
>>   	value |= DMA_BUS_MODE_DA;	/* Rx has priority over tx */
>>   #endif
>>   	writel(value, ioaddr + DMA_BUS_MODE);
>> +	/*
>> +	 * We need to program DMA_AXI_BUS_MODE for supported bursts in
>> +	 * case DMA_BUS_MODE_FB mode is selected
>> +	 * Note: This is applicable only for revision GMACv3.61a. For
>> +	 * older version this register is reserved and shall have no
>> +	 * effect.
>> +	 * Further we directly write 0xFF to this register. This would
>> +	 * ensure that all bursts supported by platform is set and those
>> +	 * which are not supported would remain ineffective.
>> +	 */
>> +	if (value&  DMA_BUS_MODE_FB)
>> +		writel(0xFF, ioaddr + DMA_AXI_BUS_MODE);
> ... this patch sets the FB: Fixed Burst (not set on other GMAC!) and
> then always writes into the DMA_AXI_BUS_MODE register.
>
> I agree that the DMA_AXI_BUS_MODE Reg is reserved in old devices but I'd
> like to have a new platform parameter to do this kind of thing.
>
> We could have .fixed_burst in the linux/stmmac.h (like .pbl).
>
> If it is passed, so we set the DMA_BUS_MODE_FB in the DMA Reg 0.
>
> In this case, we can also set the DMA reg11 but, pls, not using 0xff.
> I wonder if you could improve the code adding the defines for this register.
>
> With this approach we have no impact on other GMAC!
>
> peppe

Looks good, will use the <include/linux/stmmac.h> for passing the fixed 
burst option, and also
program the DMA register accordingly.

Along with that, we may need to program following things.
- For Fixed burst mode, the fixed burst length that has to be programmed.
- For no-fixed burst mode, the maximum allowed burst length need to be set.

This is in sync with the following information captured from the stmmac 
core manual for the
bit-0  of the DMA AXI Bus Mode register

**********************************************************************
UNDEF: AXI Undefined Burst Length
This bit is read-only bit and indicates the complement (invert) value of 
FB bit
in Register0 (Bus Mode Register[16]).
• When this bit is set to 1, the GMAC-AXI is allowed to perform any burst
length equal to or below the maximum allowed burst length as
programmed in bits[7:1]
• When this bit is set to 0, the GMAC-AXI is allowed to perform only fixed
burst lengths as indicated by BLEN256/128/64/32/16/8/4, or a burst
length of 1.
*********************************************************************

It would be better if additionally we pass the burst length, signifying the
- Fixed burst length for fixed burst mode
- Max Burst length for non-fixed burst mode.


Regards
Deepak
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html