> approaches to vibrator control - sysfs with a "speed" attribute, an
> input device using the force feedback ioctls or something that's
> plumbed through the sound codec. While the absence of any consistency
> here is obviously a problem, I'd prefer not to add a fourth - can you
I'll have a look - I hadn't seen one using the force feedback but that
makes an awful lot of sense.
> > + * If the PMIC hasn't been discovered or one is not found
> > then
> > + * the calls will error for us.
>
> Can't you do this at probe time?
We have to check for errors anyway. We could also check at probe time
but that would add ordering issues or mean we needed the scu_ipc driver
to create the platform device for the vibrator - which given it's not
current discoverable is a bit ugly.
> > + if (intel_scu_ipc_iowrite8(0x49, 0xAD))
> > + return -EINVAL;
> > + } else {
> > + if (intel_scu_ipc_iowrite8(0x49, 0x14))
> > + return -EINVAL;
>
> Is there any significance to 0xAD and 0x14? Is this register specific
> to the vibrator?
As I understand it yes.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
