Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <3c6a9126-bf88-0f29-425f-36748271c179@amd.com>
Date:   Thu, 27 Jan 2022 09:55:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize
 second map
Content-Language: en-US
To:     Lucas De Marchi <lucas.demarchi@intel.com>
Cc:     linaro-mm-sig@lists.linaro.org, intel-gfx@lists.freedesktop.org,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        linux-media@vger.kernel.org
References: <20220126203702.1784589-1-lucas.demarchi@intel.com>
 <20220126203702.1784589-3-lucas.demarchi@intel.com>
 <f0dbdcc0-13b5-c484-0bf3-a1f8c3e48954@amd.com>
 <20220127075728.ygwgorhnrwaocdqv@ldmartin-desk2>
 <3066c6a7-fc73-d34d-d209-a3ff6818dfb6@amd.com>
 <20220127081810.6zt6cyib4s7kpa6f@ldmartin-desk2>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <20220127081810.6zt6cyib4s7kpa6f@ldmartin-desk2>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXRpYXBrZWFoMFJoZW1DMUh3RjZmRVgxazgxR3YrYUlrZDV5eGpzbVN0NW9G?=
 =?utf-8?B?SDBWT3ZXV0x4VmxDaXJETGFTMmt4YW9CTHNVRHM4d3EycVIxL05Xc20xU21Y?=
 =?utf-8?B?Q05XMEtpeDVVdEdHT2dkRzZUckhrajZ5TE5jM1NtOHp5a2RmSnpLalQ5N3FP?=
 =?utf-8?B?aXJwTjRhVjV4Z1FKUVpWWEFhZDg0ZHdiZGI3ZTR6R2RMU2owVnU4S0VtSnY5?=
 =?utf-8?B?TWM2Uk00T01Lc1lBcEJNaWVMb1o1ZTBkZWlTdElEc2Z2dFVNT0gyTE1tTlNh?=
 =?utf-8?B?MmVabDBzQnBLNFJXR2xldHVFcTBiWFI2RUpSem5icnN1eXd1UVkvbnQ1dkZE?=
 =?utf-8?B?UGtiMzM2Wnhobk96QUx4amV2MEhmZmtHVU1oLzZkSEJXMDRkVklqaURaU3p2?=
 =?utf-8?B?cGRLRVB4ZmVPczdMMkFCekZLZFF2NmR5L3hJQlNiMVYvRjM1dklGdktDNUxi?=
 =?utf-8?B?ZERNQ2VQam5ZUnBEYm5iZUJaaXgySDk3TmFRL2ZDMkRONEhDWmx3VG80dElt?=
 =?utf-8?B?NlZUZXp5UC9tbjMwTzFVUCtMalBWdk50UEFQZytOZzFORENRN3dBS3Bpako4?=
 =?utf-8?B?RjNYY0tGUWJHZUc4aWxOaWdDclZaMlZ5RjQvbENIcHdPamI4NHRBeHhwMGVk?=
 =?utf-8?B?VlRuRDRpMnJ5NitZNWFmU2VEblBueFdFUmg0eVpuSHVEWXMrTzRkNEpCKzha?=
 =?utf-8?B?Y01zYUpJbDh2NnQ4WmFFamRqWlhUeUxQam5vU054K0NkUGZReDRxdjNjTUhv?=
 =?utf-8?B?UkxEOGl2VlpMcExVNFJkSDRObmk0RDRzTThaRVF1ZmhhN2Noa1JGM1BQYTdv?=
 =?utf-8?B?RG4xZUNZR0kyRXdySUc2eFNvRWZJbVdwSzVkT3dKdmhkVUxpbGNlQXJlNUJX?=
 =?utf-8?B?V0pLNGVMdW9qeFYzME4yczBlM3Y5WGxMOVRJRjNTMUNleEpNZ0hpR3JORHlq?=
 =?utf-8?B?bU0yenpnUG5IV1ExNzU5UmxEVTlFM3ovTHhaUVVNWnZSdjRDUlFWZmxkT2RK?=
 =?utf-8?B?aTlScERYWEI1dC9oWkV3QkRUbTlEMXpyZjlzTkxLczYrcXRNUFFJSTlFd1lz?=
 =?utf-8?B?dmtQTkZxcktXYzlnaUxvM3FlMWE0c1hhSVNQZDhLYTNyMU5YZHE3RUNLczVi?=
 =?utf-8?B?Y2xUcHZhNVMvOEsvS296MXRQU3pERWhacDRYSm5qa1pWbmE3U1FiYzZwSUto?=
 =?utf-8?B?UGdodmJUM3RnQ3lKbGZpNTlZTmlpTmh1MWJYOTJwQU5UNWNkYjJiRnplMzU4?=
 =?utf-8?B?Z1Z4UUI4M2QrVk8wTkFkTDlvRVRzUVgxYjZuOTB0ajhaRzhZd2ozUTRITVZm?=
 =?utf-8?B?U0lhTE1NM0hvUjUzK1YrTm5OaVFMZkRXWTgwOUlqNFBHekxkWlF2WmpLUEtC?=
 =?utf-8?B?cldhZUdieVNIcW03QzdIenQ3c3grZjJWeUo5Qy9NMHRRSXMwVFNVdWhqMmR2?=
 =?utf-8?B?N0FGSGowK1lYYmRtelR1RzFrVVJhb3pEeWRUQlNLc2ZsS29BR2xEbVlPNVFi?=
 =?utf-8?B?a1JURnhOU1IyRnBlWVhkM2d5bG1iWUZHeE90Tm1PRENQR0pDdzllZVhwQXda?=
 =?utf-8?B?OFFoaUpFSEtpRmFBYkloMlJ6NEUwZHNtSjViZHVIY05WZGYrU1pZWXJlUVVp?=
 =?utf-8?B?SUFGOGQwS1VMenFqMWw2RWZ2R3pIajFZZHNVektNakZJSEVnaXY4bzFORVg2?=
 =?utf-8?B?WWJOZFJDK3BVMGFYRmxMR2hTYk9RdnpRdmpSejJoZFdHZkgwVllqMDYrWEtD?=
 =?utf-8?B?eG9QOXFuYk5IV1pGMGc4S3FrQXd4alhpVTYvWTNubGtLNTRvUnA3TFNiTm5V?=
 =?utf-8?B?cUtuZmkyZExaOUQ4eWwxRS9pbFluVlpqcWRmOXlOTnNrUWR6RUgrMHJRMXBI?=
 =?utf-8?B?d0txeDFxTHVFenZFek9wMHlXNzB6eUk2UmRGcHo5MWV4R29pVFY4UW1YZ1VG?=
 =?utf-8?B?ZXI2NkNtcnA4S25xcFNMakpIRFV6OXk0Q3o3NDZBK0NCZkZ2Vys1KzEwbGR6?=
 =?utf-8?B?YWliT0FoRTFCYnZ1L1UrdlA3NTFnRlI4ZldEWUk5ZDA0alJlVXRSUDVYem1N?=
 =?utf-8?B?d3lPVytYcEMvSzVyaG1EaVdBS1hyVVlubEtOclpRMGthWFY2djJ1YTNyVW1y?=
 =?utf-8?Q?4Hno=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a719322-61cc-43ff-cc7e-08d9e172b9a7
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jan 2022 08:55:11.0220
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: P7omnw3Ub/ny4RAV+XkynlCx2dhNScNEwiO0D73JJMgEJuv7gGDokZ8kNgETZhkH
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4223
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 27.01.22 um 09:18 schrieb Lucas De Marchi:
> On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
>> Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
>>> On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
>>>> Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
>>>>> [SNIP]
>>> humn... not sure if I was  clear. There is no importer and exporter 
>>> here.
>>
>> Yeah, and exactly that's what I'm pointing out as problem here.
>>
>> You are using the inter driver framework for something internal to 
>> the driver. That is an absolutely clear NAK!
>>
>> We could discuss that, but you guys are just sending around patches 
>> to do this without any consensus that this is a good idea.
>
> s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
> these patches. I'm sending these to _build consensus_ on what may be a 
> good
> use for it showing a real problem it's helping to fix.

Well a cover letter would have been helpful, my impression was that you 
have a larger set and just want to upstream some minor DMA-buf changes 
necessary for it.

Now I know why people are bugging me all the time to add cover letters 
to add more context to my sets.

>
> From its documentation:
>
>  * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers 
> are
>  * actually independent from the dma-buf infrastructure. When sharing 
> buffers
>  * among devices, drivers have to know the location of the memory to 
> access
>  * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
>  * solves this problem for dma-buf and its users. If other drivers or
>  * sub-systems require similar functionality, the type could be 
> generalized
>  * and moved to a more prominent header file.
>
> if there is no consensus and a better alternative, I'm perfectly fine in
> throwing it out and using the better approach.

When Thomas Zimmermann upstreamed the dma_buf_map work we had a 
discussion if that shouldn't be independent of the DMA-buf framework.

The consensus was that as soon as we have more widely use for it this 
should be made independent. So basically that is what's happening now.

I suggest the following approach:
1. Find a funky name for this, something like iomem_, kiomap_ or similar.
2. Separate this from all you driver dependent work and move the 
dma_buf_map structure out of DMA-buf into this new whatever_ prefix.
3. Ping Thomas, LKML, me and probably a couple of other core people if 
this is the right idea or not.
4. Work on dropping the map parameter from dma_buf_vunmap(). This is 
basically why we can't modify the pointers returned from dma_buf_vmap() 
and has already cause a few problems with dma_buf_map_incr().

Regards,
Christian.

>
> Lucas De Marchi