On 5 February 2016 at 05:52, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: > Chunyan Zhang <zhang.chunyan@xxxxxxxxxx> writes: > >> From: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> >> >> Some architecture like ARM assign masterIDs statically at the HW design >> phase, making masterID manipulation in the generic STM core irrelevant. >> >> This patch adds a new 'mstatic' flag to struct stm_data that tells the >> core that this specific STM device doesn't need explicit masterID >> management. > > So why do we need this patch? If your STM only has master 42 allocated > for software sources, simply set sw_start = 42, sw_end = 42 and you're > good to go, software will have exactly one channel to choose from. See > also the comment from <linux/stm.h>: On ARM each source, i.e entity capable of accessing STM channels, has a different master ID set in HW. We can't assume the IDs are contiguous and from a SW point of view there is no way to probe the values. > > * @sw_start: first STP master available to software > * @sw_end: last STP master available to software > > particularly the "available to software" part. Any other kinds of > masters the STM class code doesn't care about (yet). > >> In the core sw_start/end of masterID are set to '1', >> i.e there is only one masterID to deal with. > > This is also a completely arbitrary and unnecessary requirement. Again, > you can set both to 42 and it will still work. True - any value will do. The important thing to remember is that on ARM, there is only one masterID channel (from an STM core point of view). But we could also proceed differently, see below for more details. > >> Also this patch depends on [1], so that the number of masterID >> is '1' too. >> >> Finally the lower and upper bound for masterIDs as presented >> in ($SYSFS)/class/stm/XYZ.stm/masters and >> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters >> are set to '-1'. That way users can't confuse them with >> architecture where masterID management is required (where any >> other value would be valid). > > Why is this a good idea? Having the actual master there will allow > software to know what it is and also tell the decoding side what it is > (assuming you have more than one source in the STP stream, it might not > be easy to figure out, unless you know it in advance). In the ARM world masterIDs are irrelevant so why bother with them? Writing a '-1' simply highlight this reality. Another way of approaching the problem would be to change sw_start/end to a bitfield that represent the valid masterIDs but in my opinion, it is a lot of code churn for information that isn't used outside of the decoder. Thanks, Mathieu > > I don't see how one master statically assigned to software sources is > different from two masters or 32 masters. And I don't see any benefit of > hiding the master id from userspace. Am I missing something? > > Regards, > -- > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
