On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote: > Hi Pavel, > > On 08/24/2018 12:11 PM, Pavel Machek wrote: > > Hi! > > > >> I think that it would be more flexible if software pattern fallback > >> was applied in case of pattern_set failure. Otherwise, it would > >> lead to the situation where LED class devices that support hardware > >> blinking couldn't be applied the same set of patterns as LED class > >> devices that don't implement pattern_set. The latter will always have to > >> resort to using software pattern engine which will accept far greater > >> amount of pattern combinations. > >> > >> In this case we need to discuss on what basis the decision will be > >> made on whether hardware or software engine will be used. > >> > >> Possible options coming to mind: > >> - an interface will be provided to determine max difference between > >> the settings supported by the hardware and the settings requested by > >> the user, that will result in aligning user's setting to the hardware > >> capabilities > >> - the above alignment rate will be predefined instead > >> - hardware engine will be used only if user requests supported settings > >> on the whole span of the requested pattern > >> - in each of the above cases it would be worth to think of the > >> interface to show the scope of the settings supported by hardware > > > > I'd recommend keeping it simple. We use hardware engine if driver > > author thinks pattern is "close enough". > > The thing is that in the ledtrig-pattern v5 implementation there > is no option of using software fallback if pattern_set op > is initialized: > > + if (led_cdev->pattern_set) { > + return led_cdev->pattern_set(led_cdev, data->patterns, > + data->npatterns, data->repeat); > + } Yeah, that sounds wrong. (Sorry I did not pay enough attention). It pattern_set() returns special error code, it should just continue and use software pattern fallback. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature