On Fri, Jan 13, 2012 at 4:27 AM, J.I. Cameron <jic23@xxxxxxxxx> wrote: > On Jan 12 2012, Palande, Ameya wrote: > >> On Thu, Jan 12, 2012 at 2:33 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> >> wrote: >>> >>> On 01/12/2012 11:05 PM, Palande, Ameya wrote: >>>> >>>> Hi Lars, >>>> >>>> On Thu, Jan 12, 2012 at 12:09 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 01/12/2012 08:39 PM, Palande, Ameya wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I submitted a driver for Texas Instruments DRV2665 chip for placing it >>>>>> under "drivers/misc". >>>>>> But I guess it is more appropriate to put it under >>>>>> "drivers/staging/iio" >>>>>> Reference: https://lkml.org/lkml/2012/1/10/31 >>>>> >>>>> >>>>>> >>>>>> Here is the description of the chip: >>>>>> >>>>>> DRV2665 IC drives piezo actuator which enables a wide variety of >>>>>> high-resolution haptic effects, including feedback localized to >>>>>> specific areas of the device, as well as vibrations and pulses that >>>>>> change in frequency based on how the user is interacting with the >>>>>> device. >>>>>> >>>>>> Can you tell me where should I put it under "staging/iio" ? >>>>>> >>>>> >>>>> >>>>> I had a short look at your driver and it looks to me as if all it does >>>>> is >>>>> expose the raw registers as sysfs attributes. So I think one thing you >>>>> first >>>>> have to do is to figure out a generic interface for the device class. >>>>> How does >>>>> a application usually use these kinds of devices, how can the interface >>>>> be >>>>> abstracted, so it applies to a wider range of devices of this class and >>>>> not >>>>> only to this one specific device. >>>> >>>> >>>> Workflow for using DRV2665 is: >>>> 1. Set the desired configuration >>>> 2. Send waveform data to data register >>> >>> >>> Well that's basically the work-flow for every driver ;) Setup config, >>> write data. >>> >>> But the data and config also have a meaning. So what is the high-level >>> task a >>> software want to perform when setting certain up a configuration? >> >> >> Configuration can include: >> 1. Selecting FIFO or Analog input >> 2. Selecting timeout period between when the FIFO runs empty and the >> DRV2665 goes into idle mode >> 3. Overriding bit for the boost converter and amplifier enables >> 4. Programing the GAIN control >> >>> A good start would probably to break the config register down into it's >>> different elements and don't expose the raw register anymore. >> >> >> Thank for suggesting it! I will implement that. >> However my original question is still unanswered: Where should I place >> this driver in iio? > > > Any chance of a datasheet? At the moment it looks like something that might > fit > better in either input (stuff is there for force feedback joysticks etc), > or I believe there was some work on a general haptics framework a while back > (though google implies that kind of disappeard). I'm not against it going > in IIO (probably in a new category) but only if it doesn't fit better > elsewhere! Unfortunately datasheet is not yet public. Main purpose of this chip is to customize the haptics effect. IMHO it doesn't fit in input subsystem. [Touch event] -> [user space analyzer] -> [drv2665] User space analyzer component will generate a waveform depending on touch event it receives from touchscreen and this is fed to drv2665. Cheers, Ameya. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
