Hi!
Do you have vibrations on d4 working?
I believe I have required drivers enabled, but no luck:
user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
bind uevent unbind
user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
bind uevent unbind
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Mon, Jul 09, 2018 at 10:15:35AM +0200, Pavel Machek wrote:
> Do you have vibrations on d4 working?
> I believe I have required drivers enabled, but no luck:
>
> user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> bind uevent unbind
> user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> bind uevent unbind
Have you checked probe deferrals?
-- Sebastian
Hi!
> > Do you have vibrations on d4 working?
> > I believe I have required drivers enabled, but no luck:
> >
> > user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> > bind uevent unbind
> > user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> > bind uevent unbind
>
> Have you checked probe deferrals?
Not really. Is there easier way to do that than adding printks in the
probe function? (I can go through dmesg tommorow).
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Tue, Jul 10, 2018 at 12:02:11AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Do you have vibrations on d4 working?
> > > I believe I have required drivers enabled, but no luck:
> > >
> > > user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> > > bind uevent unbind
> > > user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> > > bind uevent unbind
> >
> > Have you checked probe deferrals?
>
> Not really. Is there easier way to do that than adding printks in the
> probe function? (I can go through dmesg tommorow).
Option 1: https://lkml.org/lkml/2018/7/8/63
Option 2: dynamic debug via kernel commandline (needs CONFIG_DYNAMIC_DEBUG)
dyndbg="func deferred_probe_work_func +p; func driver_deferred_probe_add +p"
Option 3: use "initcall_debug" kernel commandline
-- Sebastian
On Tue 2018-07-10 12:11:47, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 10, 2018 at 12:02:11AM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > Do you have vibrations on d4 working?
> > > > I believe I have required drivers enabled, but no luck:
> > > >
> > > > user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> > > > bind uevent unbind
> > > > user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> > > > bind uevent unbind
> > >
> > > Have you checked probe deferrals?
> >
> > Not really. Is there easier way to do that than adding printks in the
> > probe function? (I can go through dmesg tommorow).
>
> Option 1: https://lkml.org/lkml/2018/7/8/63
I tried this methodq, and no luck.
static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
does not seem to be called.
Its parent is gpio@4805d000 , and that one seems to be present.
user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
driver driver_override gpio
gpiochip5 modalias of_node power subsystem uevent
So I'm now confused.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Tue, Jul 10, 2018 at 03:30:40PM +0200, Pavel Machek wrote:
> On Tue 2018-07-10 12:11:47, Sebastian Reichel wrote:
> > On Tue, Jul 10, 2018 at 12:02:11AM +0200, Pavel Machek wrote:
> > > > > Do you have vibrations on d4 working?
> > > > > I believe I have required drivers enabled, but no luck:
> > > > >
> > > > > user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> > > > > bind uevent unbind
> > > > > user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> > > > > bind uevent unbind
> > > >
> > > > Have you checked probe deferrals?
> > >
> > > Not really. Is there easier way to do that than adding printks in the
> > > probe function? (I can go through dmesg tommorow).
> >
> > Option 1: https://lkml.org/lkml/2018/7/8/63
>
> I tried this methodq, and no luck.
>
> static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
>
> does not seem to be called.
>
> Its parent is gpio@4805d000 , and that one seems to be present.
>
> user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> driver driver_override gpio
> gpiochip5 modalias of_node power subsystem uevent
Sorry, something went wrong with merging this. The parent
of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
not gpio6.
-- Sebastian
Hi!
> > Its parent is gpio@4805d000 , and that one seems to be present.
> >
> > user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> > driver driver_override gpio
> > gpiochip5 modalias of_node power subsystem uevent
>
> Sorry, something went wrong with merging this. The parent
> of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
> not gpio6.
Ok, got it to probe... after dts fix and adding EPROBE_DEFFER to
driver.
Still can't get it to actually vibrate.
user@devuan:/sys/bus/platform/drivers/pwm-vibrator/vibrator$ sudo fftest /dev/input/event3
Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES
Device /dev/input/event3 opened
Features:
* Absolute axes:
[00 00 00 00 00 00 00 00 ]
* Relative axes:
[00 00 ]
* Force feedback effects types: Periodic, Rumble, Gain,
Force feedback periodic effects: Square, Triangle, Sine,
[00 00 00 00 00 00 00 00 00 00 03 07 01 00 00 00 ]
* Number of simultaneous effects: 16
Setting master gain to 75% ... OK
Uploading effect #0 (Periodic sinusoidal) ... OK (id 0)
Uploading effect #1 (Constant) ... Error: Invalid argument
Uploading effect #2 (Spring) ... Error: Invalid argument
Uploading effect #3 (Damper) ... Error: Invalid argument
Uploading effect #4 (Strong rumble, with heavy motor) ... OK (id 1)
Uploading effect #5 (Weak rumble, with light motor) ... OK (id 2)
Enter effect number, -1 to exit
5
Now Playing: Weak Rumble
Enter effect number, -1 to exit
0
Now Playing: Sine vibration
Enter effect number, -1 to exit
5
Now Playing: Weak Rumble
Enter effect number, -1 to exit
^C
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index 45305e8..c27fc87 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -159,13 +159,7 @@
dais = <&mcbsp2_port>, <&mcbsp3_port>;
};
-};
-
-&dss {
- status = "okay";
-};
-&gpio6 {
pwm8: dmtimer-pwm-8 {
pinctrl-names = "default";
pinctrl-0 = <&vibrator_direction_pin>;
@@ -192,7 +186,10 @@
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <10000000>;
};
+};
+&dss {
+ status = "okay";
};
&dsi1 {
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 665da3c..debeb70 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -265,7 +271,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
timer_pdata = dev_get_platdata(&timer_pdev->dev);
if (!timer_pdata) {
dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
- ret = -EINVAL;
+ ret = -EPROBE_DEFER;
goto put;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue 2018-07-10 18:11:23, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 10, 2018 at 03:30:40PM +0200, Pavel Machek wrote:
> > On Tue 2018-07-10 12:11:47, Sebastian Reichel wrote:
> > > On Tue, Jul 10, 2018 at 12:02:11AM +0200, Pavel Machek wrote:
> > > > > > Do you have vibrations on d4 working?
> > > > > > I believe I have required drivers enabled, but no luck:
> > > > > >
> > > > > > user@devuan:/sys/bus/platform/drivers$ ls pwm-vibrator/
> > > > > > bind uevent unbind
> > > > > > user@devuan:/sys/bus/platform/drivers$ ls omap-dmtimer-pwm/
> > > > > > bind uevent unbind
> > > > >
> > > > > Have you checked probe deferrals?
> > > >
> > > > Not really. Is there easier way to do that than adding printks in the
> > > > probe function? (I can go through dmesg tommorow).
> > >
> > > Option 1: https://lkml.org/lkml/2018/7/8/63
> >
> > I tried this methodq, and no luck.
> >
> > static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> >
> > does not seem to be called.
> >
> > Its parent is gpio@4805d000 , and that one seems to be present.
> >
> > user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> > driver driver_override gpio
> > gpiochip5 modalias of_node power subsystem uevent
>
> Sorry, something went wrong with merging this. The parent
> of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
> not gpio6.
There's still something wrong with pinctrl... I guess.
Pavel
[ 0.973907] phy-mapphone-mdm6600 usb-phy@1: could not find pctldev for node /ocp/l4@4a000000/sc
m@100000/pinmux@40/pinmux_usb_mdm6600_pins, deferring probe
[ 0.990295] pinctrl-single 4a100040.pinmux: 203 pins, size 406
[ 0.996643] pinctrl-single 4a31e040.pinmux: 28 pins, size 56
[ 1.003234] pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x18e (0x38)
[ 1.010986] pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_vibrator_directi
on_pin 398x
[ 1.020996] dmtimer_probe
[ 1.023712] dmtimer_probe: have timer
[ 1.027526] omap-dmtimer-pwm dmtimer-pwm-8: dmtimer pdata structure NULL
[ 1.034484] pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x190 (0x38)
[ 1.042175] pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_vibrator_enable_pin 400x
[ 1.051910] dmtimer_probe
[ 1.054626] dmtimer_probe: have timer
[ 1.058441] omap-dmtimer-pwm dmtimer-pwm-9: dmtimer pdata structure NULL
[ 1.068725] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 70.264739] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
[ 80.093811] omap-dmtimer-pwm dmtimer-pwm-9: requested duty cycle: 3750057 ns, period: 10000000 ns
[ 80.102996] omap-dmtimer-pwm dmtimer-pwm-9: clk rate: 26000000Hz
[ 80.109252] omap-dmtimer-pwm dmtimer-pwm-9: effective duty cycle: 3750038 ns, period: 10000000 ns
[ 80.118530] omap-dmtimer-pwm dmtimer-pwm-9: load value: 0xfffc0860 (-260000), match value: 0xfffd853c (-162500)
[ 80.129089] omap-dmtimer-pwm dmtimer-pwm-8: requested duty cycle: 10000000 ns, period: 10000000 ns
[ 80.138336] omap-dmtimer-pwm dmtimer-pwm-8: clk rate: 26000000Hz
[ 80.144561] omap-dmtimer-pwm dmtimer-pwm-8: duty cycle 10000000 ns is too long for period 10000000 ns at clock rate 26000000 Hz
[ 80.156433] omap-dmtimer-pwm dmtimer-pwm-8: using maximum of 1 clock cycle less than period
[ 80.165069] omap-dmtimer-pwm dmtimer-pwm-8: effective duty cycle: 9999962 ns, period: 10000000 ns
[ 80.174621] omap-dmtimer-pwm dmtimer-pwm-8: load value: 0xfffc0860 (-260000), match value: 0xfffffffe (-2)
[ 100.344970] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek <[email protected]> [180711 08:05]:
> Hi!
>
> > > Its parent is gpio@4805d000 , and that one seems to be present.
> > >
> > > user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> > > driver driver_override gpio
> > > gpiochip5 modalias of_node power subsystem uevent
> >
> > Sorry, something went wrong with merging this. The parent
> > of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
> > not gpio6.
>
> Ok, got it to probe... after dts fix and adding EPROBE_DEFFER to
> driver.
..
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -159,13 +159,7 @@
>
> dais = <&mcbsp2_port>, <&mcbsp3_port>;
> };
> -};
> -
> -&dss {
> - status = "okay";
> -};
>
> -&gpio6 {
> pwm8: dmtimer-pwm-8 {
> pinctrl-names = "default";
> pinctrl-0 = <&vibrator_direction_pin>;
> @@ -192,7 +186,10 @@
> pwm-names = "enable", "direction";
> direction-duty-cycle-ns = <10000000>;
> };
> +};
>
> +&dss {
> + status = "okay";
> };
>
> &dsi1 {
Hmm sorry if I did a mismerge on the above. A note to
myself to stop applying patches that apply with fuzz,
that is clearly dangerous with dts files with lots
of similar named properties.
Regards,
Tony
Hi,
On Wed, Jul 11, 2018 at 06:27:39AM -0700, Tony Lindgren wrote:
> * Pavel Machek <[email protected]> [180711 08:05]:
> > Hi!
> >
> > > > Its parent is gpio@4805d000 , and that one seems to be present.
> > > >
> > > > user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> > > > driver driver_override gpio
> > > > gpiochip5 modalias of_node power subsystem uevent
> > >
> > > Sorry, something went wrong with merging this. The parent
> > > of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
> > > not gpio6.
> >
> > Ok, got it to probe... after dts fix and adding EPROBE_DEFFER to
> > driver.
> ..
> > --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> > +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> > @@ -159,13 +159,7 @@
> >
> > dais = <&mcbsp2_port>, <&mcbsp3_port>;
> > };
> > -};
> > -
> > -&dss {
> > - status = "okay";
> > -};
> >
> > -&gpio6 {
> > pwm8: dmtimer-pwm-8 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&vibrator_direction_pin>;
> > @@ -192,7 +186,10 @@
> > pwm-names = "enable", "direction";
> > direction-duty-cycle-ns = <10000000>;
> > };
> > +};
> >
> > +&dss {
> > + status = "okay";
> > };
> >
> > &dsi1 {
>
> Hmm sorry if I did a mismerge on the above. A note to
> myself to stop applying patches that apply with fuzz,
> that is clearly dangerous with dts files with lots
> of similar named properties.
It might also have been me doing the mismerge before
sending the patch. Anyways, the patch from Pavel looks
good to me. As a side-effect dss and dsi references
come next to each other.
-- Sebastian
On Wed 2018-07-11 06:27:39, Tony Lindgren wrote:
> * Pavel Machek <[email protected]> [180711 08:05]:
> > Hi!
> >
> > > > Its parent is gpio@4805d000 , and that one seems to be present.
> > > >
> > > > user@devuan:/sys/bus/platform/devices$ ls 4805d000.gpio
> > > > driver driver_override gpio
> > > > gpiochip5 modalias of_node power subsystem uevent
> > >
> > > Sorry, something went wrong with merging this. The parent
> > > of ti,omap-dmtimer-pwm and pwm-vibrator should be / and
> > > not gpio6.
> >
> > Ok, got it to probe... after dts fix and adding EPROBE_DEFFER to
> > driver.
> ..
> > --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> > +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> > @@ -159,13 +159,7 @@
> >
> > dais = <&mcbsp2_port>, <&mcbsp3_port>;
> > };
> > -};
> > -
> > -&dss {
> > - status = "okay";
> > -};
> >
> > -&gpio6 {
> > pwm8: dmtimer-pwm-8 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&vibrator_direction_pin>;
> > @@ -192,7 +186,10 @@
> > pwm-names = "enable", "direction";
> > direction-duty-cycle-ns = <10000000>;
> > };
> > +};
> >
> > +&dss {
> > + status = "okay";
> > };
> >
> > &dsi1 {
>
> Hmm sorry if I did a mismerge on the above. A note to
> myself to stop applying patches that apply with fuzz,
> that is clearly dangerous with dts files with lots
> of similar named properties.
Yep, so I have two patches that make the device appear, but vibrations
still do not work for me.
a) any ideas how to debug that / get them to work?
b) do you want the patches anyway?
Regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
pwm node should not be under gpio6 node in the device tree.
This fixes detection of the pwm on Droid 4.
Signed-off-by: Pavel Machek <[email protected]>
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index 45305e8..c27fc87 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -159,13 +159,7 @@
dais = <&mcbsp2_port>, <&mcbsp3_port>;
};
-};
-
-&dss {
- status = "okay";
-};
-&gpio6 {
pwm8: dmtimer-pwm-8 {
pinctrl-names = "default";
pinctrl-0 = <&vibrator_direction_pin>;
@@ -192,7 +186,10 @@
pwm-names = "enable", "direction";
direction-duty-cycle-ns = <10000000>;
};
+};
+&dss {
+ status = "okay";
};
&dsi1 {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
When all the drivers are built-in, timers are not ready and probing
fails. Fix that with -EPROBE_DEFFER.
Signed-off-by: Pavel Machek <[email protected]>
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 665da3c..debeb70 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -265,7 +271,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
timer_pdata = dev_get_platdata(&timer_pdev->dev);
if (!timer_pdata) {
dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
- ret = -EINVAL;
+ ret = -EPROBE_DEFER;
goto put;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek <[email protected]> [180716 07:16]:
>
> When all the drivers are built-in, timers are not ready and probing
> fails. Fix that with -EPROBE_DEFFER.
>
> Signed-off-by: Pavel Machek <[email protected]>
>
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 665da3c..debeb70 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -265,7 +271,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> timer_pdata = dev_get_platdata(&timer_pdev->dev);
> if (!timer_pdata) {
> dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
> - ret = -EINVAL;
> + ret = -EPROBE_DEFER;
> goto put;
> }
There seems to be an earlier similar patch, care to take a look
at "[PATCH] pwm: pwm-omap-dmtimer: return -EPROBE_DEFER if no
dmtimer platform data"?
Regards,
Tony
* Pavel Machek <[email protected]> [180715 20:20]:
> Yep, so I have two patches that make the device appear, but vibrations
> still do not work for me.
>
> a) any ideas how to debug that / get them to work?
Hmm no new ideas except I wonder if there is also some other
regression with the timer pdata not being passed properly now.
> b) do you want the patches anyway?
Yes for things that are obviously broken it makes sense.
Thanks,
Tony
On Mon 2018-07-16 00:57:40, Tony Lindgren wrote:
> * Pavel Machek <[email protected]> [180716 07:16]:
> >
> > When all the drivers are built-in, timers are not ready and probing
> > fails. Fix that with -EPROBE_DEFFER.
> >
> > Signed-off-by: Pavel Machek <[email protected]>
> >
> > diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> > index 665da3c..debeb70 100644
> > --- a/drivers/pwm/pwm-omap-dmtimer.c
> > +++ b/drivers/pwm/pwm-omap-dmtimer.c
> > @@ -265,7 +271,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> > timer_pdata = dev_get_platdata(&timer_pdev->dev);
> > if (!timer_pdata) {
> > dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
> > - ret = -EINVAL;
> > + ret = -EPROBE_DEFER;
> > goto put;
> > }
>
> There seems to be an earlier similar patch, care to take a look
> at "[PATCH] pwm: pwm-omap-dmtimer: return -EPROBE_DEFER if no
> dmtimer platform data"?
Yes, that one is equivalent.
You can add
Acked-by: Pavel Machek <[email protected]>
Tested-by: Pavel Machek <[email protected]>
on it.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Mon, Jul 16, 2018 at 09:10:48AM +0200, Pavel Machek wrote:
> pwm node should not be under gpio6 node in the device tree.
>
> This fixes detection of the pwm on Droid 4.
>
> Signed-off-by: Pavel Machek <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
-- Sebastian
> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> index 45305e8..c27fc87 100644
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -159,13 +159,7 @@
>
> dais = <&mcbsp2_port>, <&mcbsp3_port>;
> };
> -};
> -
> -&dss {
> - status = "okay";
> -};
>
> -&gpio6 {
> pwm8: dmtimer-pwm-8 {
> pinctrl-names = "default";
> pinctrl-0 = <&vibrator_direction_pin>;
> @@ -192,7 +186,10 @@
> pwm-names = "enable", "direction";
> direction-duty-cycle-ns = <10000000>;
> };
> +};
>
> +&dss {
> + status = "okay";
> };
>
> &dsi1 {
>
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 16 Jul 2018 10:37:20 +0200
Pavel Machek <[email protected]> wrote:
> On Mon 2018-07-16 00:57:40, Tony Lindgren wrote:
> > * Pavel Machek <[email protected]> [180716 07:16]:
> > >
> > > When all the drivers are built-in, timers are not ready and probing
> > > fails. Fix that with -EPROBE_DEFFER.
> > >
> > > Signed-off-by: Pavel Machek <[email protected]>
> > >
> > > diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> > > index 665da3c..debeb70 100644
> > > --- a/drivers/pwm/pwm-omap-dmtimer.c
> > > +++ b/drivers/pwm/pwm-omap-dmtimer.c
> > > @@ -265,7 +271,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> > > timer_pdata = dev_get_platdata(&timer_pdev->dev);
> > > if (!timer_pdata) {
> > > dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
> > > - ret = -EINVAL;
> > > + ret = -EPROBE_DEFER;
> > > goto put;
> > > }
> >
> > There seems to be an earlier similar patch, care to take a look
> > at "[PATCH] pwm: pwm-omap-dmtimer: return -EPROBE_DEFER if no
> > dmtimer platform data"?
>
> Yes, that one is equivalent.
>
> You can add
>
> Acked-by: Pavel Machek <[email protected]>
> Tested-by: Pavel Machek <[email protected]>
>
> on it.
>
> Thanks,
> Pavel
Thanks Pavel. I hadn't been watching the Droid 4 threads, so I didn't
see you were hitting the same problem. I'm assuming the patch will go
through the PWM tree, so copying in Thierry.
* Sebastian Reichel <[email protected]> [180716 10:14]:
> Hi,
>
> On Mon, Jul 16, 2018 at 09:10:48AM +0200, Pavel Machek wrote:
> > pwm node should not be under gpio6 node in the device tree.
> >
> > This fixes detection of the pwm on Droid 4.
> >
> > Signed-off-by: Pavel Machek <[email protected]>
>
> Reviewed-by: Sebastian Reichel <[email protected]>
Applying into omap-for-v4.18/fixes thanks.
Tony
Hi!
> > Yep, so I have two patches that make the device appear, but vibrations
> > still do not work for me.
> >
> > a) any ideas how to debug that / get them to work?
>
> Hmm no new ideas except I wonder if there is also some other
> regression with the timer pdata not being passed properly now.
I checked vibrations work in original Motorola Android; my hardware is
not broken.
I see:
commit b7290cf6ff7869ec12070aa146c370728cab62c2
Author: Keerthy <[email protected]>
Date: Thu Feb 15 11:31:50 2018 +0530
pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
Signed-off-by: Keerthy <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Reviewed-by: Claudiu Beznea <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
should I try to revert that one? (Are pdata still there in the board
files somewhere).
Do vibrations work for you?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2018-07-16 00:59:26, Tony Lindgren wrote:
> * Pavel Machek <[email protected]> [180715 20:20]:
> > Yep, so I have two patches that make the device appear, but vibrations
> > still do not work for me.
> >
> > a) any ideas how to debug that / get them to work?
>
> Hmm no new ideas except I wonder if there is also some other
> regression with the timer pdata not being passed properly now.
Got it, pinmux part of dts was at wrong place, too. Patch will follow.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Vibration GPIOs don't have anything to do with wakeup. Move it to
normal section; this fixes vibrations on Droid 4.
Signed-off-by: Pavel Machek <[email protected]>
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index c27fc87..7b82179 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -646,15 +646,6 @@
OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1) /* abe_mcbsp3_fsx */
>;
};
-};
-
-&omap4_pmx_wkup {
- usb_gpio_mux_sel2: pinmux_usb_gpio_mux_sel2_pins {
- /* gpio_wk0 */
- pinctrl-single,pins = <
- OMAP4_IOPAD(0x040, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
- >;
- };
vibrator_direction_pin: pinmux_vibrator_direction_pin {
pinctrl-single,pins = <
@@ -669,6 +660,15 @@
};
};
+&omap4_pmx_wkup {
+ usb_gpio_mux_sel2: pinmux_usb_gpio_mux_sel2_pins {
+ /* gpio_wk0 */
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x040, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
+ >;
+ };
+};
+
/*
* As uart1 is wired to mdm6600 with rts and cts, we can use the cts pin for
* uart1 wakeirq.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Wed, Aug 01, 2018 at 10:28:21PM +0200, Pavel Machek wrote:
> Vibration GPIOs don't have anything to do with wakeup. Move it to
> normal section; this fixes vibrations on Droid 4.
>
> Signed-off-by: Pavel Machek <[email protected]>
>
> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> index c27fc87..7b82179 100644
Reviewed-by: Sebastian Reichel <[email protected]>
-- Sebastian
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -646,15 +646,6 @@
> OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1) /* abe_mcbsp3_fsx */
> >;
> };
> -};
> -
> -&omap4_pmx_wkup {
> - usb_gpio_mux_sel2: pinmux_usb_gpio_mux_sel2_pins {
> - /* gpio_wk0 */
> - pinctrl-single,pins = <
> - OMAP4_IOPAD(0x040, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
> - >;
> - };
>
> vibrator_direction_pin: pinmux_vibrator_direction_pin {
> pinctrl-single,pins = <
> @@ -669,6 +660,15 @@
> };
> };
>
> +&omap4_pmx_wkup {
> + usb_gpio_mux_sel2: pinmux_usb_gpio_mux_sel2_pins {
> + /* gpio_wk0 */
> + pinctrl-single,pins = <
> + OMAP4_IOPAD(0x040, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
> + >;
> + };
> +};
> +
> /*
> * As uart1 is wired to mdm6600 with rts and cts, we can use the cts pin for
> * uart1 wakeirq.
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
On Wed, Aug 01, 2018 at 08:58:24PM +0200, Pavel Machek wrote:
> > > Yep, so I have two patches that make the device appear, but vibrations
> > > still do not work for me.
> > >
> > > a) any ideas how to debug that / get them to work?
> >
> > Hmm no new ideas except I wonder if there is also some other
> > regression with the timer pdata not being passed properly now.
>
> I checked vibrations work in original Motorola Android; my hardware is
> not broken.
You got it working, but this information might still be interesting
in case of future problems:
The Android "driver" is very different from the one I wrote from
scratch and upstreamed. The mainline driver is less lines of code
(iirc 25%), less complicated (Android vibration support is spread
over multiple drivers/arch code), more efficient (Android drivers
does GPIO bitbanging instead of PWM) and provides more features
(Android driver does not allow all strength settings). Also it uses
normal input device API instead of a custom one.
P.S.: Sorry, I don't have much time to work on D4 at the moment :(
-- Sebastian
Hi!
> On Wed, Aug 01, 2018 at 08:58:24PM +0200, Pavel Machek wrote:
> > > > Yep, so I have two patches that make the device appear, but vibrations
> > > > still do not work for me.
> > > >
> > > > a) any ideas how to debug that / get them to work?
> > >
> > > Hmm no new ideas except I wonder if there is also some other
> > > regression with the timer pdata not being passed properly now.
> >
> > I checked vibrations work in original Motorola Android; my hardware is
> > not broken.
>
> You got it working, but this information might still be interesting
> in case of future problems:
>
> The Android "driver" is very different from the one I wrote from
> scratch and upstreamed. The mainline driver is less lines of code
> (iirc 25%), less complicated (Android vibration support is spread
> over multiple drivers/arch code), more efficient (Android drivers
> does GPIO bitbanging instead of PWM) and provides more features
> (Android driver does not allow all strength settings). Also it uses
> normal input device API instead of a custom one.
Thanks for doing it right.
> P.S.: Sorry, I don't have much time to work on D4 at the moment :(
Thanks for doing the work, d4 seems to be the most usable phone at the
moment. Yes, there's more work to do, but there's always more work to
do.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Sebastian Reichel <[email protected]> [180802 10:59]:
> Hi,
>
> On Wed, Aug 01, 2018 at 10:28:21PM +0200, Pavel Machek wrote:
> > Vibration GPIOs don't have anything to do with wakeup. Move it to
> > normal section; this fixes vibrations on Droid 4.
> >
> > Signed-off-by: Pavel Machek <[email protected]>
> >
> > diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> > index c27fc87..7b82179 100644
>
> Reviewed-by: Sebastian Reichel <[email protected]>
Thanks applying into omap-for-v4.19/fixes.
Tony