From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [PATCH 02/32] drivers/common: introducing dpaa2 mc
	driver
Date: Mon, 19 Dec 2016 10:57:18 +0530
Message-ID: <5d84ac9c-b25a-f056-5501-1c16d4224b83@nxp.com>
References: <1480875447-23680-1-git-send-email-hemant.agrawal@nxp.com>
 <1480875447-23680-3-git-send-email-hemant.agrawal@nxp.com>
 <20161215060453.GA19354@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <dev@dpdk.org>, <thomas.monjalon@6wind.com>, <bruce.richardson@intel.com>,
 <shreyansh.jain@nxp.com>, Cristian Sovaiala <cristian.sovaiala@nxp.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM02-CY1-obe.outbound.protection.outlook.com
 (mail-cys01nam02on0044.outbound.protection.outlook.com [104.47.37.44])
 by dpdk.org (Postfix) with ESMTP id 79D292FDD
 for <dev@dpdk.org>; Mon, 19 Dec 2016 06:27:27 +0100 (CET)
In-Reply-To: <20161215060453.GA19354@localhost.localdomain>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 12/15/2016 11:34 AM, Jerin Jacob wrote:
> On Sun, Dec 04, 2016 at 11:46:57PM +0530, Hemant Agrawal wrote:
>> This patch intoduces the DPAA2 MC(Management complex Driver)
>>
>> This driver is common to be used by various DPAA2 net, crypto
>> and other drivers
>>
>> Signed-off-by: Cristian Sovaiala <cristian.sovaiala@nxp.com>
>> [Hemant:rebase and conversion to library for DPDK]
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> +#ifndef _FSL_MC_SYS_H
>> +#define _FSL_MC_SYS_H
>> +
>> +#ifdef __linux_driver__
>> +
>> +#include <linux/errno.h>
>> +#include <asm/io.h>
>> +#include <linux/slab.h>
>> +
>> +struct fsl_mc_io {
>> +	void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP		95
>> +#endif
>> +
>> +#define ioread64(_p)	    readq(_p)
>> +#define iowrite64(_v, _p)   writeq(_v, _p)
>> +
>> +#else /* __linux_driver__ */
>> +
>> +#include <stdio.h>
>> +#include <libio.h>
>> +#include <stdint.h>
>> +#include <errno.h>
>> +#include <sys/uio.h>
>> +#include <linux/byteorder/little_endian.h>
>> +
>> +#define cpu_to_le64(x) __cpu_to_le64(x)
>> +#ifndef dmb
>> +#define dmb() {__asm__ __volatile__("" : : : "memory"); }
>> +#endif
>
> Better to use DPDK macros here.
>
>> +#define __iormb()       dmb()
>> +#define __iowmb()       dmb()
>> +#define __arch_getq(a)                  (*(volatile unsigned long *)(a))
>> +#define __arch_putq(v, a)                (*(volatile unsigned long *)(a) = (v))
>> +#define __arch_putq32(v, a)                (*(volatile unsigned int *)(a) = (v))
>> +#define readq(c)        \
>> +	({ uint64_t __v = __arch_getq(c); __iormb(); __v; })
>> +#define writeq(v, c)     \
>> +	({ uint64_t __v = v; __iowmb(); __arch_putq(__v, c); __v; })
>> +#define writeq32(v, c) \
>> +	({ uint32_t __v = v; __iowmb(); __arch_putq32(__v, c); __v; })
>> +#define ioread64(_p)	    readq(_p)
>> +#define iowrite64(_v, _p)   writeq(_v, _p)
>> +#define iowrite32(_v, _p)   writeq32(_v, _p)
>
> Hopefully, we can clean all this once rte_read32 and rte_write32 becomes
> mainline
>
> http://dpdk.org/dev/patchwork/patch/17935/

I agree, We will update it as your other patch progresses.

>> +#define __iomem
>> +
>> +struct fsl_mc_io {
>> +	void *regs;
>> +};
>> +
>> +#ifndef ENOTSUP
>> +#define ENOTSUP		95
>> +#endif
>> +
>> +/*GPP is supposed to use MC commands with low priority*/
>> +#define CMD_PRI_LOW          0 /*!< Low Priority command indication */
>> +
>> +struct mc_command;
>> +
>> +int mc_send_command(struct fsl_mc_io *mc_io, struct mc_command *cmd);
>> +
>> +#endif /* __linux_driver__ */
>> +
>> +#endif /* _FSL_MC_SYS_H */
>> +
>> +/** User space framework uses MC Portal in shared mode. Following change
>> +* introduces lock in MC FLIB
>> +*/
>> +
>> +/**
>> +* The mc_spinlock_t type.
>> +*/
>> +typedef struct {
>> +	volatile int locked; /**< lock status 0 = unlocked, 1 = locked */
>> +} mc_spinlock_t;
>> +
>> +/**
>> +* A static spinlock initializer.
>> +*/
>> +static mc_spinlock_t mc_portal_lock = { 0 };
>> +
>> +static inline void mc_pause(void) {}
>> +
>> +static inline void mc_spinlock_lock(mc_spinlock_t *sl)
>> +{
>> +	while (__sync_lock_test_and_set(&sl->locked, 1))
>> +		while (sl->locked)
>> +			mc_pause();
>> +}
>> +
>> +static inline void mc_spinlock_unlock(mc_spinlock_t *sl)
>> +{
>> +	__sync_lock_release(&sl->locked);
>> +}
>> +
>
> DPDK spinlock can be used here.
>
Yes!