[Buildroot] ADP5588 - Platform data

[Buildroot] ADP5588 - Platform data

[Leonardo Giordano]

Hi,

My board has and ADP5588 IC (it is an I2C matrix keyboard scanner).
I enabled the ADP5588 at kernel configuration.
Then I added the following section to i2c at dts file:

adp5588: keyboard at 1b {
compatible = "adp5588-keys";
reg = <0x1b>;
interrupt-parent = <&pioC>;
interrupts = <1 0x0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_adp5588_irq>;
wakeup-source;
};

However, at adp5588_probe() function (drivers/input/keyboard/adp5588.c), it
fails when trying to get platform data:

const struct adp5588_kpad_platform_data *pdata =
 dev_get_platdata(&client->dev);

pdata points to null.

I made a workaround by defining platform_data right there, but I don't want
to modify a driver file because of this.
I could not find a way of defining the platform data on the initialisation
board file, or better in the dts.

I see the driver is not a platform driver, so not sure
if platform_device_register() will work or not.


Any tips?
BR,
Leonardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161213/a6f2350e/attachment.html>

[Buildroot] ADP5588 - Platform data

[Peter Korsgaard]

>>>>> "Leonardo" == Leonardo Giordano <lgiordano@controlnet.com.ar> writes:

 > Hi,
 > My board has and ADP5588 IC (it is an I2C matrix keyboard scanner).

This kind of kernel questions are really more suited for one of the
kernel lists, E.G. the input or i2c lists.

 > I enabled the ADP5588 at kernel configuration.
 > Then I added the following section to i2c at dts file:

 > adp5588: keyboard at 1b {
 > compatible = "adp5588-keys";
 > reg = <0x1b>;
 > interrupt-parent = <&pioC>;
 > interrupts = <1 0x0>;
 > pinctrl-names = "default";
 > pinctrl-0 = <&pinctrl_adp5588_irq>;
 > wakeup-source;
 > };

Where did you get this from? As far as I can see there isn't any
devicetree support in that driver of any bindings documented.

 > However, at adp5588_probe() function (drivers/input/keyboard/adp5588.c), it
 > fails when trying to get platform data:

 > const struct adp5588_kpad_platform_data *pdata =
 >  dev_get_platdata(&client->dev);

 > pdata points to null.

The driver has to be extended with devicetree bindings to get the
information that used to be encoded in the platform data from the DT.

-- 
Bye, Peter Korsgaard

[Buildroot] ADP5588 - Platform data

[Leonardo Giordano]

Hi Peter,
Thanks for replying.

It seems I'm "extending" the driver, as I want to use device tree.
Sorry for sending to this list, I agree it should be sent to kernel list,
but I'm not part of it yet.

Regards,
Leonardo

2016-12-13 15:57 GMT-03:00 Peter Korsgaard <peter@korsgaard.com>:

> >>>>> "Leonardo" == Leonardo Giordano <lgiordano@controlnet.com.ar>
> writes:
>
>  > Hi,
>  > My board has and ADP5588 IC (it is an I2C matrix keyboard scanner).
>
> This kind of kernel questions are really more suited for one of the
> kernel lists, E.G. the input or i2c lists.
>
>  > I enabled the ADP5588 at kernel configuration.
>  > Then I added the following section to i2c at dts file:
>
>  > adp5588: keyboard at 1b {
>  > compatible = "adp5588-keys";
>  > reg = <0x1b>;
>  > interrupt-parent = <&pioC>;
>  > interrupts = <1 0x0>;
>  > pinctrl-names = "default";
>  > pinctrl-0 = <&pinctrl_adp5588_irq>;
>  > wakeup-source;
>  > };
>
> Where did you get this from? As far as I can see there isn't any
> devicetree support in that driver of any bindings documented.
>
>  > However, at adp5588_probe() function (drivers/input/keyboard/adp5588.c),
> it
>  > fails when trying to get platform data:
>
>  > const struct adp5588_kpad_platform_data *pdata =
>  >  dev_get_platdata(&client->dev);
>
>  > pdata points to null.
>
> The driver has to be extended with devicetree bindings to get the
> information that used to be encoded in the platform data from the DT.
>
> --
> Bye, Peter Korsgaard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161213/616bfb61/attachment.html>