From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751391AbcBLUeA (ORCPT ); Fri, 12 Feb 2016 15:34:00 -0500 Received: from mail-ob0-f180.google.com ([209.85.214.180]:35092 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750976AbcBLUd6 (ORCPT ); Fri, 12 Feb 2016 15:33:58 -0500 MIME-Version: 1.0 In-Reply-To: <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com> References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org> <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org> <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com> <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com> <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com> Date: Fri, 12 Feb 2016 13:33:58 -0700 Message-ID: Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs From: Mathieu Poirier To: Alexander Shishkin Cc: Chunyan Zhang , Rob Herring , Mark Brown , Pratik Patel , Nicolas GUION , Jon Corbet , Mark Rutland , Mike Leach , "Jeremiassen, Tor" , Al Grant , Lyra Zhang , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-api@vger.kernel.org, linux-doc@vger.kernel.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 On 12 February 2016 at 09:27, Alexander Shishkin wrote: > Mathieu Poirier writes: > >> On 8 February 2016 at 06:26, Alexander Shishkin >> wrote: >>> This $end==$start situation itself may be ambiguous and can be >>> interpreted either as having just one *static* master ID fixed for all >>> SW writers (what I assumed from your commit message) or as having a >>> floating master ID, which changes of its own accord and is not >>> controllable by software. >> >> Some clarification here. >> >> On ARM from a SW point of view $end == $start and that doesn't change >> (with regards to masterIDs) . The ambiguity comes from the fact that >> on other platforms where masterID configuration does change and is >> important, the condition $end == $start could also be valid. > > Yes, that's what I was saying. The thing is, on the system-under-tracing > side these two situations are not very different from one > another. Master IDs are really just numbers without any semantics > attached to them in the sense that they are not covered by the mipi spec > or any other standard (to my knowledge). We are definitely on the same page here, just using slightly different terms. > > The difference is in the way we map channels to masters. One way is to > allocate a distinct set of channels for each master (the way Intel Trace > Hub does it); another way is to share the same set of channels between > multiple masters. We are in total agreement. > So we can describe this as "hardware implements the > same set of channels across multiple masters" or something along those > lines. I suggest "Shared channels"? In the end, that's really what it is... The outstanding issue is still how to represent these to different way of mapping things in the STM core. I suggested a flag, called "mstatic" (but that can be changed), and a representation of '-1' in for masterIDs sysFS. Whether we stick with that or not is irrelevant, I'd be fine with another mechanism. What I am keen on is that from sysFS users can quickly tell which heuristic is enacted on that specific architecture. > > Actually, in the latter scheme of things you can also have multiple > masters, at least theoretically. Say, you have masters [0..15], each > with distinct set of channels, but depending on hardware state these > masters actually end up as $state*16+$masterID in the STP stream. > > So we might also think about differentiating between the hardware > masters (0 though 15 in the above example) and STP masters. I'm not sure I get what you mean here. On ARM the masterIDs assigned in HW, which will depend on the state, will show up in the STP stream. But again, I might be missing your point. Thanks, Mathieu > > Regards, > -- > Alex