| Message ID | 20180711080218.GA21225@amd (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Pavel Machek <pavel@ucw.cz> [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 <pavel@ucw.cz> [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 <pavel@ucw.cz> [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
* Pavel Machek <pavel@ucw.cz> [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
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 <j-keerthy@ti.com> 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 <j-keerthy@ti.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Tony Lindgren <tony@atomide.com> should I try to revert that one? (Are pdata still there in the board files somewhere). Do vibrations work for you? Best regards, Pavel
On Mon 2018-07-16 00:59:26, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [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
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
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; }