From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751812AbdJLPIo convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Thu, 12 Oct 2017 11:08:44 -0400
Received: from mail-out-2.itc.rwth-aachen.de ([134.130.5.47]:2421 "EHLO
        mail-out-2.itc.rwth-aachen.de" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751356AbdJLPIm (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 12 Oct 2017 11:08:42 -0400
X-IronPort-AV: E=Sophos;i="5.43,366,1503352800"; 
   d="scan'208";a="18206022"
From: =?iso-8859-1?Q?Br=FCns=2C_Stefan?= <Stefan.Bruens@rwth-aachen.de>
To: Vinod Koul <vinod.koul@intel.com>
CC: "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        =?iso-8859-1?Q?Niklas_S=F6derlund?= 
        <niklas.soderlund+renesas@ragnatech.se>,
        Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: [RFC PATCH] dmaengine: sh: Correct
 src_addr_widths/dst_addr_widths bitmask setting
Thread-Topic: [RFC PATCH] dmaengine: sh: Correct
 src_addr_widths/dst_addr_widths bitmask setting
Thread-Index: AQHTQ2a6Kl6RchGIlkuAvCgphpyIWaLgL5SA
Date: Thu, 12 Oct 2017 15:08:27 +0000
Message-ID: <1991799.ckRSdLPnpL@sbruens-linux>
References: <20170917144539.3497-1-stefan.bruens@rwth-aachen.de>
 <20171012141812.GQ30097@localhost>
In-Reply-To: <20171012141812.GQ30097@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [78.35.13.203]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5E7726776A564844A6B6B554D20B6C6C@rwth-ad.de>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Donnerstag, 12. Oktober 2017 16:18:12 CEST Vinod Koul wrote:
> On Sun, Sep 17, 2017 at 04:45:39PM +0200, Stefan Brüns wrote:
> > Obviously, the current value for the burst widths are wrong, and if this
> > value is retrieved from some other subsystem using dma_get_slave_caps,
> > it will wrongly assume burst width of e.g. 3 bytes are supported.
> > 
> > Each bit in the bitmask corresponds to a supported width, but it uses
> > an encoding of BIT(<widths>), not BIT(log2<widths>), as it must be able
> > to encode a width of 3 bytes.
> > 
> > The corollary is, it is not possible to encode either a width of 32 or
> > 64 bytes, as the field has a size of 32 bits, and only a subset of the
> > controller capabilities can be exposed.
> 
> well the right way would have been to fix this in the core by extending the
> src/dst_addr_widths. I am sending a patch for that. please use that and
> update this

Thats the reason I sent this as RFC, I never expected this to go mainline as 
is, but wanted to trigger a discussion.

Kind regards,

Stefan