On Tue, 17 Nov 2009 14:55:51 -0500, Devin Heitmueller wrote: > On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxxxxx> wrote: > > I don't like the idea of creating structs grouping those parameters. While for > > certain devices this may mean a more direct approach, for others, this may > > not make sense, due to the way their API's were implemented (for example, > > devices with firmware may need several calls to get all those info). > > There is some value in providing grouping the results in a single > request - in many cases the data is based off of the same internal > registers, and Manu's proposed approach allows for a more "atomic" > response. The fact that we currently do the status, SNR, strength, > and UNC/BER in separate calls is one reason that people sometimes see > inconsistent results in the output of tools like zap. As an example, > they can see lines in the zap output where the lock is lost but SNR > appears fine. > > In the case where the driver servicing the query needs to do three > calls, it could be slightly more expensive, but only if we believe > that it is commonplace to ask for a subset of the stats. For what it's worth, we have solved this problem in hwmon driver the following way: we cache related values (read from the same register or set of registers) for ~1 second. When user-space requests the information, if the cache is fresh it is used, otherwise the cache is first refreshed. That way we ensure that data returned to nearby user-space calls are taken from the same original register value. One advantage is that we thus did not have to map the API to the hardware register constraints and thus have the guarantee that all hardware designs fit. I don't know if a similar logic would help for DVB. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
