Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755119AbcCaGtW (ORCPT ); Thu, 31 Mar 2016 02:49:22 -0400 Received: from mail-oi0-f54.google.com ([209.85.218.54]:32852 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751459AbcCaGtU (ORCPT ); Thu, 31 Mar 2016 02:49:20 -0400 MIME-Version: 1.0 In-Reply-To: <20160331135322.523a7ceb@xhacker> References: <1459344310-626-1-git-send-email-jszhang@marvell.com> <8737r8uhjm.fsf@free-electrons.com> <20160331135322.523a7ceb@xhacker> Date: Thu, 31 Mar 2016 08:49:19 +0200 Message-ID: Subject: Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform From: Marcin Wojtas To: Jisheng Zhang Cc: Gregory CLEMENT , "David S. Miller" , Thomas Petazzoni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2595 Lines: 64 Hi Jisheng, 2016-03-31 7:53 GMT+02:00 Jisheng Zhang : > Hi Gregory, > > On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote: > >> Hi Jisheng, >> >> On mer., mars 30 2016, Jisheng Zhang wrote: >> >> > The mvneta BM can't work on 64bit platform, as the BM hardware expects >> > buf virtual address to be placed in the first four bytes of mapped >> > buffer, but obviously the virtual address on 64bit platform can't be >> > stored in 4 bytes. So we have to explicitly disable BM on 64bit >> > platform. >> >> Actually mvneta is used on Armada 3700 which is a 64bits platform. >> Is it true that the driver needs some change to use BM in 64 bits, but >> we don't have to disable it. >> >> Here is the 64 bits part of the patch we have currently on the hardware >> prototype. We have more things which are really related to the way the >> mvneta is connected to the Armada 3700 SoC. This code was not ready for > > Thanks for the sharing. > > I think we could commit easy parts firstly, for example: the cacheline size > hardcoding, either piece of your diff or my version: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418513.html Since the commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cache.h?id=97303480753e48fb313dc0e15daaf11b0451cdb8 detached L1_CACHE_BYTES from real cache size, I suggest, the macro should be: #define MVNETA_CPU_D_CACHE_LINE_SIZE cache_line_size() Regarding check after dma_alloc_coherent, I agree it's not necessary. > >> mainline but I prefer share it now instead of having the HWBM blindly > > I have looked through the diff, it is for the driver itself on 64bit platforms, > and it doesn't touch BM. The BM itself need to be disabled for 64bit, I'm not > sure the BM could work on 64bit even with your diff. Per my understanding, the BM > can't work on 64 bit, let's have a look at some piece of the mvneta_bm_construct() > > *(u32 *)buf = (u32)buf; Indeed this particular part is different and unclear, I tried different options - with no success. I'm checking with design team now. Anyway, I managed to enable operation for HWBM on A3700 with one work-around in mvneta_hwbm_rx(): data = phys_to_virt(rx_desc->buf_phys_addr); Of course mvneta_bm, due to some silicone differences needed also a rework. Actually I'd wait with updating 64-bit parts of mvneta, until real support for such machine's controller is introduced. Basing on my experience with enabling neta on A3700, it turns out to be more changes. Best regards, Marcin