[PATCH] ARM: dts: DRA7: wdt: Fix compatible property for watchdog node
OMAP wdt driver supports only ti,omap3-wdt compatible. In DRA7 dt wdt compatible property is defined as ti,omap4-wdt by mistake instead of ti,omap3-wdt. Correcting the typo. Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by: Lokesh Vutla --- arch/arm/boot/dts/dra7.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 9cc9843..666e796 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -653,7 +653,7 @@ }; wdt2: wdt@4ae14000 { - compatible = "ti,omap4-wdt"; + compatible = "ti,omap3-wdt"; reg = <0x4ae14000 0x80>; interrupts = ; ti,hwmods = "wd_timer2"; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 2/2] extcon: gpio: Add support for using cable names
Hi George, On 11/06/2014 12:29 AM, George Cherian wrote: > Add support for using cable names. Enables other drivers to register interest > and get notified using extcon provided notifier call backs. > > Signed-off-by: George Cherian > --- > Documentation/devicetree/bindings/extcon/extcon-gpio.txt | 2 ++ > drivers/extcon/extcon-gpio.c | 4 > 2 files changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > index 30aa2e1..2c9d29f 100644 > --- a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > @@ -7,6 +7,7 @@ Required Properties: > - compatible: should be: > * "linux,extcon-gpio" > - gpios: specifies the gpio pin used. > + - cable-name: Name of the cable used. > > Optional Properties: > - debounce: Debounce time for GPIO IRQ in ms > @@ -18,4 +19,5 @@ Eg: > compatible = "linux,extcon-gpio"; > gpios = <&gpio3 12 GPIO_ACTIVE_HIGH>; > debounce = <20>; > + cable-name = "USB-HOST"; > }; > diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c > index 85795de..0e1b3e8 100644 > --- a/drivers/extcon/extcon-gpio.c > +++ b/drivers/extcon/extcon-gpio.c > @@ -38,6 +38,7 @@ struct gpio_extcon_data { > int irq; > struct delayed_work work; > unsigned long debounce_jiffies; > + const char *cable_name[1]; *cable_name[1] -> **cable_name > }; > > static void gpio_extcon_work(struct work_struct *work) > @@ -100,6 +101,9 @@ static int gpio_extcon_probe(struct platform_device *pdev) > msecs_to_jiffies(debounce); > } > > + of_property_read_string_index(np, "cable-name", 0, > + extcon_data->cable_name); > + extcon_data->edev->supported_cable = extcon_data->cable_name; It is wrong. I don't want to allocate ables to supported_cable directly. For consistency of extcon driver, you have to add the array of supported cables by using devm_extcon_dev_allocate(). Thanks, Chanwoo Choi > ret = devm_extcon_dev_register(&pdev->dev, extcon_data->edev); > if (ret < 0) > return ret; > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] extcon: gpio: Add dt support for the driver
Hi George, How do you test this patch? This patch cannot test it because this patch has not compatible string for binding through DT. You have to add following of_device_id for extcon-gpio: +#if defined(CONFIG_OF) +static const struct of_device_id gpio_extcon_of_match[] = { + { .compatible = "extcon-gpio", }, + {}, +}; +MODULE_DEVICE_TABLE(of, gpio_extcon_of_match); +#endif + static struct platform_driver gpio_extcon_driver = { .probe = gpio_extcon_probe, .remove = gpio_extcon_remove, .driver = { .name = "extcon-gpio", .owner = THIS_MODULE, + .of_match_table = of_match_ptr(gpio_extcon_of_match), .pm = &gpio_extcon_pm_ops, }, }; On 11/06/2014 12:29 AM, George Cherian wrote: > Add device tree support to extcon-gpio driver. > Add devicetree binding documentation > > While at that > - Cleanup the pdata as there are no users for the same. > - Convert the driver to use gpiod_* API's. > - Some gpio's can sleep while reading, so always use > gpio_get_value_cansleep > to get data. This fixes warning from gpiolib due to wrong API usage. > > Signed-off-by: George Cherian > --- > .../devicetree/bindings/extcon/extcon-gpio.txt | 21 ++ > drivers/extcon/extcon-gpio.c | 83 > +++--- > include/linux/extcon/extcon-gpio.h | 59 --- > 3 files changed, 46 insertions(+), 117 deletions(-) > create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt > delete mode 100644 include/linux/extcon/extcon-gpio.h > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > new file mode 100644 > index 000..30aa2e1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > @@ -0,0 +1,21 @@ > +GPIO based EXTCON > + > +EXTCON GPIO > +--- > + > +Required Properties: > + - compatible: should be: > + * "linux,extcon-gpio" I prefer to use simply "extcon-gpio" compatible" instead of "linux,extcon-gpio". > + - gpios: specifies the gpio pin used. > + > +Optional Properties: > + - debounce: Debounce time for GPIO IRQ in ms > + > + Remove unneeded blank line. > +Eg: > + > + extcon1: am43_usbid_extcon1 { I want to change the example of extcon-gpio as following: "extcon1: am43_usbid_extcon1" -> "usb_extcon: extcon-gpio0" > + compatible = "linux,extcon-gpio"; ditto. > + gpios = <&gpio3 12 GPIO_ACTIVE_HIGH>; > + debounce = <20>; > + }; You have to fix indentation of brace. > diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c > index 72f19a3..85795de 100644 > --- a/drivers/extcon/extcon-gpio.c > +++ b/drivers/extcon/extcon-gpio.c > @@ -21,26 +21,23 @@ > */ > > #include > -#include > #include > #include > #include > +#include > #include > #include > +#include > #include > #include > #include > > struct gpio_extcon_data { > struct extcon_dev *edev; > - unsigned gpio; > - bool gpio_active_low; > - const char *state_on; > - const char *state_off; > + struct gpio_desc *gpiod; > int irq; > struct delayed_work work; > unsigned long debounce_jiffies; > - bool check_on_resume; > }; > > static void gpio_extcon_work(struct work_struct *work) > @@ -50,9 +47,7 @@ static void gpio_extcon_work(struct work_struct *work) > container_of(to_delayed_work(work), struct gpio_extcon_data, >work); > > - state = gpio_get_value(data->gpio); > - if (data->gpio_active_low) > - state = !state; > + state = gpiod_get_value_cansleep(data->gpiod); > extcon_set_state(data->edev, state); > } > > @@ -65,34 +60,16 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id) > return IRQ_HANDLED; > } > > -static ssize_t extcon_gpio_print_state(struct extcon_dev *edev, char *buf) > -{ > - struct device *dev = edev->dev.parent; > - struct gpio_extcon_data *extcon_data = dev_get_drvdata(dev); > - const char *state; > - > - if (extcon_get_state(edev)) > - state = extcon_data->state_on; > - else > - state = extcon_data->state_off; > - > - if (state) > - return sprintf(buf, "%s\n", state); > - return -EINVAL; > -} > - > static int gpio_extcon_probe(struct platform_device *pdev) > { > - struct gpio_extcon_platform_data *pdata = dev_get_platdata(&pdev->dev); > + struct device_node *np = pdev->dev.of_node; > struct gpio_extcon_data *extcon_data; > + unsigned int irq_flags; > + unsigned int debounce = 0; > int ret; > > - if (!pdata) > - return -EBUSY; > - if (!pdata->irq_flags) { > - dev_err(&pdev->dev, "IRQ flag is not specified.\n"); > +
Re: SGX support on AM572x
On 11/11/14, 2:22 PM, "Nishanth Menon" wrote: >On 13:58-2014, John Syn wrote: >> >> On 11/11/14, 11:54 AM, "Nishanth Menon" wrote: >> >> >On 11:17-2014, John Syn wrote: >> >> With the release of the Beagleboard-X15 in February 2015, I¹m trying >>to >> >> get a handle on the status of SGX support for the AM572x processor. >>Is >> >> anyone working on adding this support and is there any schedule for >> >> releasing SGX on AM572x? There is a lot of interest on the >>beagleboard >> >> mailing list, but SGX support seems to be a big stumbling block. >> > >> >1. Are you looking for SGX driver support in >> >https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ ? >> > >> >OR >> > >> >2. Are you looking for distro support? >> > >> >OR >> >3. Are you looking for what TI release(if any) will contain? >> > >> >for (1) you already have response from beagleboard mailing list - TI, >>to >> >my knowledge will not support IMG[1] drivers in kernel.org - at least >>no >> >known activity in the past present or future to do that. >> Yeah, I think this is clearly understood. >> > >> >For (2): as the distro folks how they want to do things - again depends >> >on where you are getting your distro from. >> The official distro for Beagleboard-X15 is Robert Nelson’s Debian >>distro, >> but as long as SGX is available for AM572x, I’m sure Robert will find a >> way to get this working. > >I suppose - you should probably use which ever mailing list meant for >Debian and Robert for that discussion. we discuss kernel.org kernel in >this list. obviously many stuff Robert does pick up comes from here - >lets stick with that. > >> > >> >For (3): use TI support channel over e2e Phorums[2] and look at >>relevant >> >TI release's release notes. Things like [3] are handled properly that >> >way. >> I took a look in e2e and I did find one promising posting: >> >> http://e2e.ti.com/support/omap/f/885/t/366372.aspx >> >> However, this article and your reference [3] are for V3.8 and I believe >> BeagleBoard-X15 will be released with V3.14 or V3.18. So my question is >> related to [3] and SGX support for either V3.14 or V3.18. > >I do think that discussion has the wrong audience in this mailing list. > >We dont deal with SGX drivers in upstream kernel. If you need to know >from TI, use e2e and ask on the thread - TI formal reply can only come >from that source. Whenever anyone asks question on e2e about TI technology and Beagleboard, e2e response is always "refer your questions to beagleboard.org". Anyway, the info you provided are a good starting point so hopefully we have enough info to move forward. Thank you for all your help. Regards, John > >> >> Regards, >> John >> > >> > >> >Other recent references: >> >https://plus.google.com/100242854243155306943/posts/TKX7GfHkTow >> >>>http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F1t3yxk >>>PY >> >SB8%2FxCbkoWC_GhQJ >> > >> > >> >[1] http://www.imgtec.com/community/ >> >[2] e2e.ti.com >> >[3] >> >>>http://git.omapzoom.org/?p=device/ti/proprietary-open.git;a=tree;f=jacin >>>to >> >>>6;h=6203e0dfe7cf89456517a1b877610f8ac2b4fd86;hb=refs/heads/d-lollipop-re >>>le >> >ase >> >-- >> >Regards, >> >Nishanth Menon >> >> > >-- >Regards, >Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SGX support on AM572x
On 13:58-2014, John Syn wrote: > > On 11/11/14, 11:54 AM, "Nishanth Menon" wrote: > > >On 11:17-2014, John Syn wrote: > >> With the release of the Beagleboard-X15 in February 2015, I¹m trying to > >> get a handle on the status of SGX support for the AM572x processor. Is > >> anyone working on adding this support and is there any schedule for > >> releasing SGX on AM572x? There is a lot of interest on the beagleboard > >> mailing list, but SGX support seems to be a big stumbling block. > > > >1. Are you looking for SGX driver support in > >https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ ? > > > >OR > > > >2. Are you looking for distro support? > > > >OR > >3. Are you looking for what TI release(if any) will contain? > > > >for (1) you already have response from beagleboard mailing list - TI, to > >my knowledge will not support IMG[1] drivers in kernel.org - at least no > >known activity in the past present or future to do that. > Yeah, I think this is clearly understood. > > > >For (2): as the distro folks how they want to do things - again depends > >on where you are getting your distro from. > The official distro for Beagleboard-X15 is Robert Nelson’s Debian distro, > but as long as SGX is available for AM572x, I’m sure Robert will find a > way to get this working. I suppose - you should probably use which ever mailing list meant for Debian and Robert for that discussion. we discuss kernel.org kernel in this list. obviously many stuff Robert does pick up comes from here - lets stick with that. > > > >For (3): use TI support channel over e2e Phorums[2] and look at relevant > >TI release's release notes. Things like [3] are handled properly that > >way. > I took a look in e2e and I did find one promising posting: > > http://e2e.ti.com/support/omap/f/885/t/366372.aspx > > However, this article and your reference [3] are for V3.8 and I believe > BeagleBoard-X15 will be released with V3.14 or V3.18. So my question is > related to [3] and SGX support for either V3.14 or V3.18. I do think that discussion has the wrong audience in this mailing list. We dont deal with SGX drivers in upstream kernel. If you need to know from TI, use e2e and ask on the thread - TI formal reply can only come from that source. > > Regards, > John > > > > > >Other recent references: > >https://plus.google.com/100242854243155306943/posts/TKX7GfHkTow > >http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F1t3yxkPY > >SB8%2FxCbkoWC_GhQJ > > > > > >[1] http://www.imgtec.com/community/ > >[2] e2e.ti.com > >[3] > >http://git.omapzoom.org/?p=device/ti/proprietary-open.git;a=tree;f=jacinto > >6;h=6203e0dfe7cf89456517a1b877610f8ac2b4fd86;hb=refs/heads/d-lollipop-rele > >ase > >-- > >Regards, > >Nishanth Menon > > -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API
Em Tue, 11 Nov 2014 18:59:31 +0100 Hans Verkuil escreveu: > Hi Mauro, > > On 11/11/2014 12:07 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 21 Oct 2014 17:07:00 +0200 > > Sebastian Reichel escreveu: > > > >> This switches back to the normal regulator API (but use > >> managed variant) in preparation for device tree support. > > > > This patch broke compilation. Please be sure that none of the patches in > > the series would break it, as otherwise git bisect would be broken. > > Weird, as reported by Sebastian, it works for me. Weird. Not sure what happened here. > > However, after applying this patch I get these new warnings: > > CC drivers/media/radio/si4713/radio-usb-si4713.o > drivers/media/radio/si4713/si4713.c: In function ‘si4713_probe’: > drivers/media/radio/si4713/si4713.c:1617:1: warning: label ‘free_gpio’ > defined but not used [-Wunused-label] > free_gpio: > ^ > drivers/media/radio/si4713/si4713.c:1451:12: warning: unused variable ‘i’ > [-Wunused-variable] > int rval, i; > ^ > > So it's probably not a good idea to merge this patch anyway until this is > fixed. Agreed. Also, v3 of this series apparently came after the pull request. Regards, Mauro > Sebastian, can you fix these warnings and repost? > > Thanks! > > Hans > > > > > Thanks, > > Mauro > > > > drivers/media/radio/si4713/si4713.c: In function 'si4713_powerup': > > drivers/media/radio/si4713/si4713.c:369:10: error: 'struct si4713_device' > > has no member named 'supplies' > > > > ^ > > drivers/media/radio/si4713/si4713.c:370:35: error: 'struct si4713_device' > > has no member named 'supplies' > > if (sdev->vdd) { > >^ > > drivers/media/radio/si4713/si4713.c:370:51: error: 'struct si4713_device' > > has no member named 'supply_data' > > if (sdev->vdd) { > >^ > > drivers/media/radio/si4713/si4713.c:402:10: error: 'struct si4713_device' > > has no member named 'supplies' > >v4l2_dbg(1, debug, &sdev->sd, "Device in power up mode\n"); > > ^ > > drivers/media/radio/si4713/si4713.c:403:36: error: 'struct si4713_device' > > has no member named 'supplies' > >sdev->power_state = POWER_ON; > > ^ > > drivers/media/radio/si4713/si4713.c:403:52: error: 'struct si4713_device' > > has no member named 'supply_data' > >sdev->power_state = POWER_ON; > > ^ > > drivers/media/radio/si4713/si4713.c: In function 'si4713_powerdown': > > drivers/media/radio/si4713/si4713.c:435:11: error: 'struct si4713_device' > > has no member named 'supplies' > > int err; > >^ > > drivers/media/radio/si4713/si4713.c:436:37: error: 'struct si4713_device' > > has no member named 'supplies' > > u8 resp[SI4713_PWDN_NRESP]; > > ^ > > drivers/media/radio/si4713/si4713.c:437:16: error: 'struct si4713_device' > > has no member named 'supply_data' > > > > ^ > > drivers/media/radio/si4713/si4713.c: In function 'si4713_probe': > > drivers/media/radio/si4713/si4713.c:1444:7: error: 'struct si4713_device' > > has no member named 'supplies' > > /* si4713_probe - probe for the device */ > >^ > > drivers/media/radio/si4713/si4713.c:1447:22: error: 'struct si4713_device' > > has no member named 'supplies' > > { > > ^ > > drivers/media/radio/si4713/si4713.c:1448:7: error: 'struct si4713_device' > > has no member named 'supply_data' > > struct si4713_device *sdev; > >^ > > drivers/media/radio/si4713/si4713.c:1450:46: error: 'struct si4713_device' > > has no member named 'supplies' > > struct v4l2_ctrl_handler *hdl; > > ^ > > drivers/media/radio/si4713/si4713.c:1451:11: error: 'struct si4713_device' > > has no member named 'supply_data' > > int rval, i; > >^ > > drivers/media/radio/si4713/si4713.c:1583:26: error: 'struct si4713_device' > > has no member named 'supplies' > > > > ^ > > drivers/media/radio/si4713/si4713.c:1583:42: error: 'struct si4713_device' > > has no member named 'supply_data' > > > > ^ > > drivers/media/radio/si4713/si4713.c: In function 'si4713_remove': > > drivers/media/radio/si4713/si4713.c:1607:26: error: 'struct si4713_device' > > has no member named 'supplies' > >goto free_irq; > > ^ > > drivers/media/radio/si4713/si4713.c:1607:42: error: 'struct si4713_device' > > has no member named 'supply_data' > >goto free_irq; > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a
Re: SGX support on AM572x
On 11/11/14, 11:54 AM, "Nishanth Menon" wrote: >On 11:17-2014, John Syn wrote: >> With the release of the Beagleboard-X15 in February 2015, I¹m trying to >> get a handle on the status of SGX support for the AM572x processor. Is >> anyone working on adding this support and is there any schedule for >> releasing SGX on AM572x? There is a lot of interest on the beagleboard >> mailing list, but SGX support seems to be a big stumbling block. > >1. Are you looking for SGX driver support in >https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ ? > >OR > >2. Are you looking for distro support? > >OR >3. Are you looking for what TI release(if any) will contain? > >for (1) you already have response from beagleboard mailing list - TI, to >my knowledge will not support IMG[1] drivers in kernel.org - at least no >known activity in the past present or future to do that. Yeah, I think this is clearly understood. > >For (2): as the distro folks how they want to do things - again depends >on where you are getting your distro from. The official distro for Beagleboard-X15 is Robert Nelson’s Debian distro, but as long as SGX is available for AM572x, I’m sure Robert will find a way to get this working. > >For (3): use TI support channel over e2e Phorums[2] and look at relevant >TI release's release notes. Things like [3] are handled properly that >way. I took a look in e2e and I did find one promising posting: http://e2e.ti.com/support/omap/f/885/t/366372.aspx However, this article and your reference [3] are for V3.8 and I believe BeagleBoard-X15 will be released with V3.14 or V3.18. So my question is related to [3] and SGX support for either V3.14 or V3.18. Regards, John > > >Other recent references: >https://plus.google.com/100242854243155306943/posts/TKX7GfHkTow >http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F1t3yxkPY >SB8%2FxCbkoWC_GhQJ > > >[1] http://www.imgtec.com/community/ >[2] e2e.ti.com >[3] >http://git.omapzoom.org/?p=device/ti/proprietary-open.git;a=tree;f=jacinto >6;h=6203e0dfe7cf89456517a1b877610f8ac2b4fd86;hb=refs/heads/d-lollipop-rele >ase >-- >Regards, >Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SGX support on AM572x
On 11:17-2014, John Syn wrote: > With the release of the Beagleboard-X15 in February 2015, I¹m trying to > get a handle on the status of SGX support for the AM572x processor. Is > anyone working on adding this support and is there any schedule for > releasing SGX on AM572x? There is a lot of interest on the beagleboard > mailing list, but SGX support seems to be a big stumbling block. 1. Are you looking for SGX driver support in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ ? OR 2. Are you looking for distro support? OR 3. Are you looking for what TI release(if any) will contain? for (1) you already have response from beagleboard mailing list - TI, to my knowledge will not support IMG[1] drivers in kernel.org - at least no known activity in the past present or future to do that. For (2): as the distro folks how they want to do things - again depends on where you are getting your distro from. For (3): use TI support channel over e2e Phorums[2] and look at relevant TI release's release notes. Things like [3] are handled properly that way. Other recent references: https://plus.google.com/100242854243155306943/posts/TKX7GfHkTow http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2F1t3yxkPYSB8%2FxCbkoWC_GhQJ [1] http://www.imgtec.com/community/ [2] e2e.ti.com [3] http://git.omapzoom.org/?p=device/ti/proprietary-open.git;a=tree;f=jacinto6;h=6203e0dfe7cf89456517a1b877610f8ac2b4fd86;hb=refs/heads/d-lollipop-release -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGX support on AM572x
With the release of the Beagleboard-X15 in February 2015, I¹m trying to get a handle on the status of SGX support for the AM572x processor. Is anyone working on adding this support and is there any schedule for releasing SGX on AM572x? There is a lot of interest on the beagleboard mailing list, but SGX support seems to be a big stumbling block. Regards, John -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API
Hi Mauro, On 11/11/2014 12:07 PM, Mauro Carvalho Chehab wrote: > Em Tue, 21 Oct 2014 17:07:00 +0200 > Sebastian Reichel escreveu: > >> This switches back to the normal regulator API (but use >> managed variant) in preparation for device tree support. > > This patch broke compilation. Please be sure that none of the patches in > the series would break it, as otherwise git bisect would be broken. Weird, as reported by Sebastian, it works for me. However, after applying this patch I get these new warnings: CC drivers/media/radio/si4713/radio-usb-si4713.o drivers/media/radio/si4713/si4713.c: In function ‘si4713_probe’: drivers/media/radio/si4713/si4713.c:1617:1: warning: label ‘free_gpio’ defined but not used [-Wunused-label] free_gpio: ^ drivers/media/radio/si4713/si4713.c:1451:12: warning: unused variable ‘i’ [-Wunused-variable] int rval, i; ^ So it's probably not a good idea to merge this patch anyway until this is fixed. Sebastian, can you fix these warnings and repost? Thanks! Hans > > Thanks, > Mauro > > drivers/media/radio/si4713/si4713.c: In function 'si4713_powerup': > drivers/media/radio/si4713/si4713.c:369:10: error: 'struct si4713_device' has > no member named 'supplies' > > ^ > drivers/media/radio/si4713/si4713.c:370:35: error: 'struct si4713_device' has > no member named 'supplies' > if (sdev->vdd) { >^ > drivers/media/radio/si4713/si4713.c:370:51: error: 'struct si4713_device' has > no member named 'supply_data' > if (sdev->vdd) { >^ > drivers/media/radio/si4713/si4713.c:402:10: error: 'struct si4713_device' has > no member named 'supplies' >v4l2_dbg(1, debug, &sdev->sd, "Device in power up mode\n"); > ^ > drivers/media/radio/si4713/si4713.c:403:36: error: 'struct si4713_device' has > no member named 'supplies' >sdev->power_state = POWER_ON; > ^ > drivers/media/radio/si4713/si4713.c:403:52: error: 'struct si4713_device' has > no member named 'supply_data' >sdev->power_state = POWER_ON; > ^ > drivers/media/radio/si4713/si4713.c: In function 'si4713_powerdown': > drivers/media/radio/si4713/si4713.c:435:11: error: 'struct si4713_device' has > no member named 'supplies' > int err; >^ > drivers/media/radio/si4713/si4713.c:436:37: error: 'struct si4713_device' has > no member named 'supplies' > u8 resp[SI4713_PWDN_NRESP]; > ^ > drivers/media/radio/si4713/si4713.c:437:16: error: 'struct si4713_device' has > no member named 'supply_data' > > ^ > drivers/media/radio/si4713/si4713.c: In function 'si4713_probe': > drivers/media/radio/si4713/si4713.c:1444:7: error: 'struct si4713_device' has > no member named 'supplies' > /* si4713_probe - probe for the device */ >^ > drivers/media/radio/si4713/si4713.c:1447:22: error: 'struct si4713_device' > has no member named 'supplies' > { > ^ > drivers/media/radio/si4713/si4713.c:1448:7: error: 'struct si4713_device' has > no member named 'supply_data' > struct si4713_device *sdev; >^ > drivers/media/radio/si4713/si4713.c:1450:46: error: 'struct si4713_device' > has no member named 'supplies' > struct v4l2_ctrl_handler *hdl; > ^ > drivers/media/radio/si4713/si4713.c:1451:11: error: 'struct si4713_device' > has no member named 'supply_data' > int rval, i; >^ > drivers/media/radio/si4713/si4713.c:1583:26: error: 'struct si4713_device' > has no member named 'supplies' > > ^ > drivers/media/radio/si4713/si4713.c:1583:42: error: 'struct si4713_device' > has no member named 'supply_data' > > ^ > drivers/media/radio/si4713/si4713.c: In function 'si4713_remove': > drivers/media/radio/si4713/si4713.c:1607:26: error: 'struct si4713_device' > has no member named 'supplies' >goto free_irq; > ^ > drivers/media/radio/si4713/si4713.c:1607:42: error: 'struct si4713_device' > has no member named 'supply_data' >goto free_irq; > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2/2] omap prcm clean-up for v3.19
The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/prcm-cleanup for you to fetch changes up to 61c8621e2bd14faad9b89ab2284955b28000bcd5: ARM: OMAP2+: PRM: provide generic API for system reset (2014-10-27 08:39:26 -0700) Clean-up series for omap PRCM (Power Reset Clock Module) from Tero Kristo to move things a bit closer to becoming a proper device driver. Tero Kristo (26): ARM: DRA7: PRM: add voltage processor check behind a prm_feature flag ARM: AM43XX: PRM: use OMAP4 PRM driver ARM: OMAP2/3: hwmod: merge wait_target_ready functions for omap2/3 ARM: AM33xx/OMAP4+: CM: remove cdoffs parameter from wait_module_idle/ready ARM: OMAP4/AM33xx: add cm_init / cm_exit calls for AM33xx and OMAP4+ ARM: OMAP2+: CM: add common API for cm_wait_module_ready ARM: OMAP4+/AM33xx: CM: add common API for cm_wait_module_idle ARM: OMAP2+: CM: make clkdm_hwsup operations static ARM: OMAP2+: CM: add common APIs for cm_module_enable/disable ARM: OMAP2/3: CM: make cm_split_idlest_reg SoC calls static ARM: AM33xx: hwmod: remove am33xx specific module SoC opts ARM: AM43xx: hwmod: use OMAP4 hardreset ops instead of the AM33xx version ARM: AM33xx: PRM: add support for prm_init ARM: OMAP2+: PRM: add generic API for asserting hardware reset ARM: OMAP2+: PRM: add generic API for deasserting hardware reset ARM: OMAP2+: PRM: add generic API for checking hardreset status ARM: OMAP4: CM: move public definitions from cminst44xx.h to cm44xx.h ARM: OMAP4: CM: make cminst direct register access functions static ARM: OMAP4+: CM: remove omap4_cm1/cm2_* functions ARM: AM33xx: PRM: move global warm reset implementation to driver ARM: AM33xx: PRM: make direct register access functions static ARM: OMAP4: PRM: make omap4_prm_read/write_inst_reg calls static ARM: OMAP3: PRM: make PRCM interrupt handler related functions static ARM: OMAP4: PRM: make PRCM interrupt handler related functions static ARM: OMAP3+: PRM: add generic API for reconfiguring I/O chain ARM: OMAP2+: PRM: provide generic API for system reset arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/am33xx-restart.c | 12 +- arch/arm/mach-omap2/clock.c | 3 +- arch/arm/mach-omap2/cm.h | 18 ++- arch/arm/mach-omap2/cm1_44xx.h | 2 - arch/arm/mach-omap2/cm1_54xx.h | 2 - arch/arm/mach-omap2/cm1_7xx.h| 2 - arch/arm/mach-omap2/cm2_44xx.h | 2 - arch/arm/mach-omap2/cm2_54xx.h | 2 - arch/arm/mach-omap2/cm2_7xx.h| 2 - arch/arm/mach-omap2/cm2xxx.c | 17 ++- arch/arm/mach-omap2/cm2xxx.h | 10 +- arch/arm/mach-omap2/cm33xx.c | 61 ++--- arch/arm/mach-omap2/cm33xx.h | 37 +- arch/arm/mach-omap2/cm3xxx.c | 19 +-- arch/arm/mach-omap2/cm3xxx.h | 12 -- arch/arm/mach-omap2/cm44xx.c | 49 --- arch/arm/mach-omap2/cm44xx.h | 3 + arch/arm/mach-omap2/cm_44xx_54xx.h | 36 - arch/arm/mach-omap2/cm_common.c | 82 +++- arch/arm/mach-omap2/cminst44xx.c | 80 ++- arch/arm/mach-omap2/cminst44xx.h | 43 -- arch/arm/mach-omap2/io.c | 11 +- arch/arm/mach-omap2/omap2-restart.c | 5 +- arch/arm/mach-omap2/omap3-restart.c | 7 +- arch/arm/mach-omap2/omap4-restart.c | 6 +- arch/arm/mach-omap2/omap_hwmod.c | 248 --- arch/arm/mach-omap2/prm.h| 16 +++ arch/arm/mach-omap2/prm2xxx.c| 6 +- arch/arm/mach-omap2/prm2xxx.h| 1 - arch/arm/mach-omap2/prm2xxx_3xxx.c | 19 ++- arch/arm/mach-omap2/prm2xxx_3xxx.h | 9 +- arch/arm/mach-omap2/prm33xx.c| 64 +++-- arch/arm/mach-omap2/prm33xx.h| 11 +- arch/arm/mach-omap2/prm3xxx.c| 32 ++--- arch/arm/mach-omap2/prm3xxx.h| 16 --- arch/arm/mach-omap2/prm44xx.c| 36 +++-- arch/arm/mach-omap2/prm44xx_54xx.h | 19 --- arch/arm/mach-omap2/prm_common.c | 99 ++ arch/arm/mach-omap2/prminst44xx.c| 10 +- arch/arm/mach-omap2/prminst44xx.h| 5 +- 41 files changed, 530 insertions(+), 586 deletions(-) delete mode 100644 arch/arm/mach-omap2/cm44xx.c delete mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h delete mode 100644 arch/arm/mach-omap2/cminst44xx.h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/2] omap non-urgent fixes for v3.19
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/fixes-not-urgent-part1 for you to fetch changes up to 7aff221c5dbe4f88930a64531df2236f303e1851: ARM: OMAP: serial: remove last vestige of DTR_gpio support. (2014-11-10 09:06:44 -0800) Fixes for omap3 that are not urgent. Mostly to remove unnecessary noise during the boot with pointless errors and warnings. Masanari Iida (1): ARM: OMAP2: Remove unnecessary KERN_* in omap_phy_internal.c NeilBrown (1): ARM: OMAP: serial: remove last vestige of DTR_gpio support. Roger Quadros (1): ARM: OMAP2+: gpmc: Get rid of "ti,elm-id not found" warning Tony Lindgren (5): ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree ARM: dts: Fix NAND last partition size on LDP ARM: dts: Add twl keypad map for LDP ARM: dts: Add twl keypad map for omap3 EVM ARM: OMAP4+: Remove unused omap_l3_noc platform init arch/arm/boot/dts/omap3-evm-common.dtsi | 21 ++ arch/arm/boot/dts/omap3-ldp.dts | 23 +++- arch/arm/boot/dts/omap3.dtsi | 2 +- arch/arm/mach-omap2/devices.c | 36 +-- arch/arm/mach-omap2/gpmc.c| 2 -- arch/arm/mach-omap2/omap_phy_internal.c | 8 --- arch/arm/mach-omap2/serial.c | 3 --- drivers/bus/omap_l3_smx.c | 26 +- include/linux/platform_data/serial-omap.h | 3 --- 9 files changed, 71 insertions(+), 53 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes against v3.18-rc4
The following changes since commit 4b91f7f3c8b20e073b7bfc098625b37f99789508: ARM: OMAP2+: Warn about deprecated legacy booting mode (2014-10-29 12:19:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-against-v3.18-rc4 for you to fetch changes up to 73b3a6657a88ef5348a0d69c9a8107d6f01ae862: pinctrl: dra: dt-bindings: Fix output pull up/down (2014-11-10 14:29:20 -0800) Few omap fixes for hangs and wrong pinctrl defines, and update MAINTAINERS file to avoid missing PMIC and SoC related patches: - Fix random hangs on am437x because of incorrect default value for the DDR regulator - Fix wrong partition name for NAND on am335x-evm - Fix wrong pinctrl defines for dra7xx - Update maintainers entries for PMICs and SoCs Felipe Balbi (1): MAINTAINERS: add more files under OMAP SUPPORT Keerthy (3): ARM: dts: AM43x-EPOS-EVM: Fix DCDC3 voltage ARM: dts: AM437x-GP-EVM: Fix DCDC3 voltage ARM: dts: AM437x-SK-EVM: Fix DCDC3 voltage Nishanth Menon (1): MAINTAINERS: Update entry for omap related .dts files to cover new SoCs Roger Quadros (2): ARM: dts: am335x-evm: Fix 5th NAND partition's name pinctrl: dra: dt-bindings: Fix output pull up/down MAINTAINERS | 20 arch/arm/boot/dts/am335x-evm.dts | 2 +- arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++-- arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++-- include/dt-bindings/pinctrl/dra.h| 4 ++-- 6 files changed, 29 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
* Igor Grinberg [14 08:41]: > On 11/11/14 16:49, Tony Lindgren wrote: > > * Igor Grinberg [14 04:04]: > >> Hi Tony, > >> > >> On 11/10/14 19:48, Tony Lindgren wrote: > >>> * Igor Grinberg [141102 04:08]: > On 11/02/14 13:19, Dmitry Lifshitz wrote: > > Add DSS related pinmux and display data nodes required to support > > DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. > > > > Signed-off-by: Dmitry Lifshitz > > Acked-by: Igor Grinberg > >>> > >>> Thanks applying into omap-for-v3.19/dt. > >>> > >>> Are we now ready to drop the board-cm-*.c files? > >> > >> Let's see, below is a list of things that are yet to be > >> supported in DT boot: > >> NAND, TV, LCD, Touchscreen, Audio (CM-T3x30), RTC (CM-T3517), CAN > >> (CM-3517). > > > > OK great, hopefully that's mostly just configuring the .dts > > files. > > Well, mostly... but not all of it. > > The LCD, RTC and CAN require bindings/drivers work. OK > >> We're rc4 now, so hopefully, we will be able to get all this in for 3.19 > >> and then have the board files removed for 3.20. > > > > Yes something like that sounds good to me. We should allow at > > least one release for people to change over. > > > >> This way we can have 3.19 with both ways supported and do last checks. > >> > >> Are you ok with this? > > > > Sure if you get the changes posted before -rc6, otherwise > > it will be too late for v3.19. > > I think, I was too optimistic about 3.19, but we can try. > Since drivers will require adaptation, I'm not sure > it will be merged for 3.19... Yes it might be a bit late for that, but if the changes are trivial, maybe not. > If we really want to make the DT boot for 3.19, we could work and > post the drivers adaptation patches and in parallel (to keep thing > going for board files removal) prepare patches for adding the > problematic stuff via quirks. This way we can keep only the DT missing > functionality in quirks and remove the board files. Once the drivers > are adjusted with new bindings, we can remove the quirks. Yes that's what we can do for sure. > Or if we are fine with keeping the board files for a little more, then > just add the DT functionality that is ready and keep working on drivers > until they are ready (hopefully, 1 - 2 releases). > > What do you think? It seems we can do both in parallel: We can use quirks for now, then remove the quirks when drivers have bindings. That removes a dependency between board-*.c files and the remaining few drivers. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
On 11/11/14 16:49, Tony Lindgren wrote: > * Igor Grinberg [14 04:04]: >> Hi Tony, >> >> On 11/10/14 19:48, Tony Lindgren wrote: >>> * Igor Grinberg [141102 04:08]: On 11/02/14 13:19, Dmitry Lifshitz wrote: > Add DSS related pinmux and display data nodes required to support > DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. > > Signed-off-by: Dmitry Lifshitz Acked-by: Igor Grinberg >>> >>> Thanks applying into omap-for-v3.19/dt. >>> >>> Are we now ready to drop the board-cm-*.c files? >> >> Let's see, below is a list of things that are yet to be >> supported in DT boot: >> NAND, TV, LCD, Touchscreen, Audio (CM-T3x30), RTC (CM-T3517), CAN (CM-3517). > > OK great, hopefully that's mostly just configuring the .dts > files. Well, mostly... but not all of it. The LCD, RTC and CAN require bindings/drivers work. > >> We're rc4 now, so hopefully, we will be able to get all this in for 3.19 >> and then have the board files removed for 3.20. > > Yes something like that sounds good to me. We should allow at > least one release for people to change over. > >> This way we can have 3.19 with both ways supported and do last checks. >> >> Are you ok with this? > > Sure if you get the changes posted before -rc6, otherwise > it will be too late for v3.19. I think, I was too optimistic about 3.19, but we can try. Since drivers will require adaptation, I'm not sure it will be merged for 3.19... If we really want to make the DT boot for 3.19, we could work and post the drivers adaptation patches and in parallel (to keep thing going for board files removal) prepare patches for adding the problematic stuff via quirks. This way we can keep only the DT missing functionality in quirks and remove the board files. Once the drivers are adjusted with new bindings, we can remove the quirks. Or if we are fine with keeping the board files for a little more, then just add the DT functionality that is ready and keep working on drivers until they are ready (hopefully, 1 - 2 releases). What do you think? -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: clock: remove unused function prototype
Remove unused function prototype that was left by commit 149c09d3a61d ("ARM: AM33xx: remove old clock data and link in new clock init code") which removed the definition. Signed-off-by: Johan Hovold --- arch/arm/mach-omap2/clock.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 4592a2762592..c81d6cc41891 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -269,8 +269,6 @@ extern const struct clksel_rate div31_1to31_rates[]; extern void __iomem *clk_memmaps[]; -extern int am33xx_clk_init(void); - extern int omap2_clkops_enable_clkdm(struct clk_hw *hw); extern void omap2_clkops_disable_clkdm(struct clk_hw *hw); -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Tue, 11 Nov 2014, Vignesh R wrote: > In one shot mode, sequencer automatically disables all enabled steps > at the end of each cycle. (both ADC steps and TSC steps) Hence these > steps need not be saved in reg_se_cache for clearing these steps at a > later stage. > Also, when ADC wakes up Sequencer should not be busy executing any of > the config steps except for the charge step. Previously charge step > was 1 ADC clock cycle and hence it was ignored. > > Signed-off-by: Vignesh R > --- You need to provide a changelog here when submitting new versions. I have included changelog in the cover page. Will include them in individual patches next time. > drivers/mfd/ti_am335x_tscadc.c | 7 +-- > include/linux/mfd/ti_am335x_tscadc.h | 1 + > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/mfd/ti_am335x_tscadc.c > b/drivers/mfd/ti_am335x_tscadc.c index d877e777cce6..110038859a8d > 100644 > --- a/drivers/mfd/ti_am335x_tscadc.c > +++ b/drivers/mfd/ti_am335x_tscadc.c > @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev > *tsadc) > spin_lock_irq(&tsadc->reg_lock); > finish_wait(&tsadc->reg_se_wait, &wait); > > + /* > + * Sequencer should either be idle or > + * busy applying the charge step. > + */ > reg = tscadc_readl(tsadc, REG_ADCFSM); > - WARN_ON(reg & SEQ_STATUS); > + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP)); > tsadc->adc_waiting = false; > } > tsadc->adc_in_use = true; > @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct > ti_tscadc_dev *tsadc) void am335x_tsc_se_set_once(struct > ti_tscadc_dev *tsadc, u32 val) { > spin_lock_irq(&tsadc->reg_lock); > - tsadc->reg_se_cache |= val; You didn't answer my question about this? I did reply to the question in the previous thread. Previously, TSC did not reliably re-enable its steps as the TSC irq handler received false pen up events. Hence, in order to use TSC after ADC operation, it was necessary to save and re-enable TSC steps (basically, to keep TSC steps enabled always). The change was more of a workaround to overcome limitation of TSC irq handler. With this series of patches, TSC irq handler is very reliable and the workaround is no longer required. > am335x_tscadc_need_adc(tsadc); > > tscadc_writel(tsadc, REG_SE, val); > diff --git a/include/linux/mfd/ti_am335x_tscadc.h > b/include/linux/mfd/ti_am335x_tscadc.h > index c99be5dc0f5c..fcce182e4a35 100644 > --- a/include/linux/mfd/ti_am335x_tscadc.h > +++ b/include/linux/mfd/ti_am335x_tscadc.h > @@ -128,6 +128,7 @@ > > /* Sequencer Status */ > #define SEQ_STATUS BIT(5) > +#define CHARGE_STEP 0x11 > > #define ADC_CLK 300 > #define TOTAL_STEPS 16 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog N�r��yb�X��ǧv�^�){.n�+{��f��{ay�ʇڙ�,j��f���h���z��w��� ���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH 3/4] arm: dts: omap3-gta04: Add handling for tv output
* Tomi Valkeinen [141110 23:44]: > Tony, > > On 11/11/14 01:30, Tony Lindgren wrote: > > * Marek Belisko [141103 14:01]: > >> Add handling for gta04 tv out chain: > >> venc -> opa362 -> svideo > >> > >> Signed-off-by: Marek Belisko > >> --- > >> arch/arm/boot/dts/omap3-gta04.dtsi | 48 > >> ++ > >> 1 file changed, 48 insertions(+) > > > > Applying this patch into omap-for-v3.19/dt thanks. > > There are changes needed for this series, so don't apply yet. > > I'll try to find the time to do a review and send comments soon. I've already pushed out the omap-for-v3.19/dt branch with this patch buried in it. I'd rather not start redoing the branch if the $subject patch is mostly correct and usable with changes to the driver patches. However, if the $subject patch needs to be redone for the driver changes, let me know and I'll redo the branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: fix twl4030 build regression
On Tue, Nov 11, 2014 at 10:36:09AM +0100, Arnd Bergmann wrote: > Recent changes to the common OTG handling broke building the twl4030 > OTG driver as found during an allmodconfig build of linux-next: > > drivers/phy/phy-twl4030-usb.c: In function 'twl4030_set_peripheral': > drivers/phy/phy-twl4030-usb.c:609:11: error: 'struct phy' has no member named > 'state' > drivers/phy/phy-twl4030-usb.c: In function 'twl4030_usb_probe': > drivers/phy/phy-twl4030-usb.c:679:12: warning: assignment from incompatible > pointer type > > This applies the same changes that were done to the other phy drivers > to get it to build cleanly. > > Signed-off-by: Arnd Bergmann > Fixes: 19c1eac2685b6 ("usb: rename phy to usb_phy in OTG") > Fixes: e47d92545c297 ("usb: move the OTG state from the USB PHY to the OTG > structure") on my testing/next already: commit 7e1bbeb4292783dcc079156b8fa08d66d17219e0 Author: Felipe Balbi Date: Fri Nov 7 19:43:45 2014 -0600 usb: host: ohci: omap: fix build breakage commit e47d925 (usb: move the OTG state from the USB PHY to the OTG structure) moved the OTG state field from struct usb_phy to struct usb_otg but, even though I fixed many other build breakages, I still missed one on ohci-omap.c. Fix the build breakage now. drivers/usb/host/ohci-omap.c: In function ‘start_hnp’: drivers/usb/host/ohci-omap.c:186:19: error: request for member ‘state’ in something not a structure or union hcd->usb_phy->otg.state = OTG_STATE_A_SUSPEND; Signed-off-by: Felipe Balbi diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c index cf89b4b1..3e5df5a 100644 --- a/drivers/usb/host/ohci-omap.c +++ b/drivers/usb/host/ohci-omap.c @@ -183,7 +183,7 @@ static void start_hnp(struct ohci_hcd *ohci) otg_start_hnp(hcd->usb_phy->otg); local_irq_save(flags); - hcd->usb_phy->otg.state = OTG_STATE_A_SUSPEND; + hcd->usb_phy->otg->state = OTG_STATE_A_SUSPEND; writel (RH_PS_PSS, &ohci->regs->roothub.portstatus [port]); l = omap_readl(OTG_CTRL); l &= ~OTG_A_BUSREQ; -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: phy: fix twl4030 build regression
On Tue, Nov 11, 2014 at 08:52:17AM -0600, Felipe Balbi wrote: > On Tue, Nov 11, 2014 at 10:36:09AM +0100, Arnd Bergmann wrote: > > Recent changes to the common OTG handling broke building the twl4030 > > OTG driver as found during an allmodconfig build of linux-next: > > > > drivers/phy/phy-twl4030-usb.c: In function 'twl4030_set_peripheral': > > drivers/phy/phy-twl4030-usb.c:609:11: error: 'struct phy' has no member > > named 'state' > > drivers/phy/phy-twl4030-usb.c: In function 'twl4030_usb_probe': > > drivers/phy/phy-twl4030-usb.c:679:12: warning: assignment from incompatible > > pointer type > > > > This applies the same changes that were done to the other phy drivers > > to get it to build cleanly. > > > > Signed-off-by: Arnd Bergmann > > Fixes: 19c1eac2685b6 ("usb: rename phy to usb_phy in OTG") > > Fixes: e47d92545c297 ("usb: move the OTG state from the USB PHY to the OTG > > structure") > > on my testing/next already: > > commit 7e1bbeb4292783dcc079156b8fa08d66d17219e0 > Author: Felipe Balbi > Date: Fri Nov 7 19:43:45 2014 -0600 > > usb: host: ohci: omap: fix build breakage wrong commit, here's the correct one: commit 8b9ca2767b2d1ea405287e530da3a7b234120b95 Author: Felipe Balbi Date: Fri Nov 7 09:06:04 2014 -0600 phy: twl4030: Fix build breakage commit e47d925 (usb: move the OTG state from the USB PHY to the OTG structure) moved the OTG state field from struct usb_phy to struct usb_otg but, even though I fixed many other build breakages, I still missed one on phy-twl4030-usb.c. Fix the build breakage now. While at that, also a build warning introduced by the same commit. Cc: Kishon Vijay Abraham I Cc: Antoine Tenart Signed-off-by: Felipe Balbi diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 7b04bef..e2698d29 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -606,7 +606,7 @@ static int twl4030_set_peripheral(struct usb_otg *otg, otg->gadget = gadget; if (!gadget) - otg->phy->state = OTG_STATE_UNDEFINED; + otg->state = OTG_STATE_UNDEFINED; return 0; } @@ -618,7 +618,7 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host) otg->host = host; if (!host) - otg->phy->state = OTG_STATE_UNDEFINED; + otg->state = OTG_STATE_UNDEFINED; return 0; } @@ -676,7 +676,7 @@ static int twl4030_usb_probe(struct platform_device *pdev) twl->phy.otg= otg; twl->phy.type = USB_PHY_TYPE_USB2; - otg->phy= &twl->phy; + otg->usb_phy= &twl->phy; otg->set_host = twl4030_set_host; otg->set_peripheral = twl4030_set_peripheral; -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
* Igor Grinberg [14 04:04]: > Hi Tony, > > On 11/10/14 19:48, Tony Lindgren wrote: > > * Igor Grinberg [141102 04:08]: > >> On 11/02/14 13:19, Dmitry Lifshitz wrote: > >>> Add DSS related pinmux and display data nodes required to support > >>> DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. > >>> > >>> Signed-off-by: Dmitry Lifshitz > >> > >> Acked-by: Igor Grinberg > > > > Thanks applying into omap-for-v3.19/dt. > > > > Are we now ready to drop the board-cm-*.c files? > > Let's see, below is a list of things that are yet to be > supported in DT boot: > NAND, TV, LCD, Touchscreen, Audio (CM-T3x30), RTC (CM-T3517), CAN (CM-3517). OK great, hopefully that's mostly just configuring the .dts files. > We're rc4 now, so hopefully, we will be able to get all this in for 3.19 > and then have the board files removed for 3.20. Yes something like that sounds good to me. We should allow at least one release for people to change over. > This way we can have 3.19 with both ways supported and do last checks. > > Are you ok with this? Sure if you get the changes posted before -rc6, otherwise it will be too late for v3.19. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API
Hi Mauro, On Tue, Nov 11, 2014 at 09:07:10AM -0200, Mauro Carvalho Chehab wrote: > Em Tue, 21 Oct 2014 17:07:00 +0200 > Sebastian Reichel escreveu: > > > This switches back to the normal regulator API (but use > > managed variant) in preparation for device tree support. > > This patch broke compilation. Please be sure that none of the patches in > the series would break it, as otherwise git bisect would be broken. > > [...] mh, the errors seem to be from the old code (without the patch applied to drivers/media/radio/si4713/si4713.c) and the inlined code fragment displayed by the compiler seems to be the new code (with the patch applied to drivers/media/radio/si4713/si4713.c). Possible reasons I can think of: * You are using some kind of object cache, which assumed it could link the previously compiled si4713.o * You started the kernel compilation before merging the patch and the commit was only half applied when the compilation reached the si4713 driver. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
On Mon, 10 Nov 2014, Russell King - ARM Linux wrote: > On Mon, Nov 10, 2014 at 12:40:19PM +, Lee Jones wrote: > > On Sun, 02 Nov 2014, Tony Lindgren wrote: > > > > > Commit e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset > > > configuration") enabled configuring the PM features for twl4030. > > > > > > This caused poweroff command to fail on devices that have the > > > BCI charger on twl4030 wired, or have power wired for VBUS. > > > Instead of powering off, the device reboots. This is because > > > voltage is detected on charger or VBUS with the default bits > > > enabled for the power transition registers. > > > > > > To fix the issue, let's just clear VBUS and CHG bits as we want > > > poweroff command to keep the system powered off. > > > > > > Fixes: e7cd1d1eb16f ("mfd: twl4030-power: Add generic reset > > > configuration") > > > Cc: sta...@vger.kernel.org # v3.16+ > > > Reported-by: Russell King > > > Signed-off-by: Tony Lindgren > > > > Applied to -fixes. > > > > Not sure whether that was an Ack from Russell or not? > > A Tested-by would've been more appropriate than an ack. Applied. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Tue, 11 Nov 2014, Vignesh R wrote: > In one shot mode, sequencer automatically disables all enabled steps at > the end of each cycle. (both ADC steps and TSC steps) Hence these steps > need not be saved in reg_se_cache for clearing these steps at a later > stage. > Also, when ADC wakes up Sequencer should not be busy executing any of the > config steps except for the charge step. Previously charge step was 1 ADC > clock cycle and hence it was ignored. > > Signed-off-by: Vignesh R > --- You need to provide a changelog here when submitting new versions. > drivers/mfd/ti_am335x_tscadc.c | 7 +-- > include/linux/mfd/ti_am335x_tscadc.h | 1 + > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c > index d877e777cce6..110038859a8d 100644 > --- a/drivers/mfd/ti_am335x_tscadc.c > +++ b/drivers/mfd/ti_am335x_tscadc.c > @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev > *tsadc) > spin_lock_irq(&tsadc->reg_lock); > finish_wait(&tsadc->reg_se_wait, &wait); > > + /* > + * Sequencer should either be idle or > + * busy applying the charge step. > + */ > reg = tscadc_readl(tsadc, REG_ADCFSM); > - WARN_ON(reg & SEQ_STATUS); > + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP)); > tsadc->adc_waiting = false; > } > tsadc->adc_in_use = true; > @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev > *tsadc) > void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val) > { > spin_lock_irq(&tsadc->reg_lock); > - tsadc->reg_se_cache |= val; You didn't answer my question about this? > am335x_tscadc_need_adc(tsadc); > > tscadc_writel(tsadc, REG_SE, val); > diff --git a/include/linux/mfd/ti_am335x_tscadc.h > b/include/linux/mfd/ti_am335x_tscadc.h > index c99be5dc0f5c..fcce182e4a35 100644 > --- a/include/linux/mfd/ti_am335x_tscadc.h > +++ b/include/linux/mfd/ti_am335x_tscadc.h > @@ -128,6 +128,7 @@ > > /* Sequencer Status */ > #define SEQ_STATUS BIT(5) > +#define CHARGE_STEP 0x11 > > #define ADC_CLK 300 > #define TOTAL_STEPS 16 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
Hi Tony, On 11/10/14 19:48, Tony Lindgren wrote: > * Igor Grinberg [141102 04:08]: >> On 11/02/14 13:19, Dmitry Lifshitz wrote: >>> Add DSS related pinmux and display data nodes required to support >>> DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517. >>> >>> Signed-off-by: Dmitry Lifshitz >> >> Acked-by: Igor Grinberg > > Thanks applying into omap-for-v3.19/dt. > > Are we now ready to drop the board-cm-*.c files? Let's see, below is a list of things that are yet to be supported in DT boot: NAND, TV, LCD, Touchscreen, Audio (CM-T3x30), RTC (CM-T3517), CAN (CM-3517). We're rc4 now, so hopefully, we will be able to get all this in for 3.19 and then have the board files removed for 3.20. This way we can have 3.19 with both ways supported and do last checks. Are you ok with this? -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 1/8] [media] si4713: switch to devm regulator API
Em Tue, 21 Oct 2014 17:07:00 +0200 Sebastian Reichel escreveu: > This switches back to the normal regulator API (but use > managed variant) in preparation for device tree support. This patch broke compilation. Please be sure that none of the patches in the series would break it, as otherwise git bisect would be broken. Thanks, Mauro drivers/media/radio/si4713/si4713.c: In function 'si4713_powerup': drivers/media/radio/si4713/si4713.c:369:10: error: 'struct si4713_device' has no member named 'supplies' ^ drivers/media/radio/si4713/si4713.c:370:35: error: 'struct si4713_device' has no member named 'supplies' if (sdev->vdd) { ^ drivers/media/radio/si4713/si4713.c:370:51: error: 'struct si4713_device' has no member named 'supply_data' if (sdev->vdd) { ^ drivers/media/radio/si4713/si4713.c:402:10: error: 'struct si4713_device' has no member named 'supplies' v4l2_dbg(1, debug, &sdev->sd, "Device in power up mode\n"); ^ drivers/media/radio/si4713/si4713.c:403:36: error: 'struct si4713_device' has no member named 'supplies' sdev->power_state = POWER_ON; ^ drivers/media/radio/si4713/si4713.c:403:52: error: 'struct si4713_device' has no member named 'supply_data' sdev->power_state = POWER_ON; ^ drivers/media/radio/si4713/si4713.c: In function 'si4713_powerdown': drivers/media/radio/si4713/si4713.c:435:11: error: 'struct si4713_device' has no member named 'supplies' int err; ^ drivers/media/radio/si4713/si4713.c:436:37: error: 'struct si4713_device' has no member named 'supplies' u8 resp[SI4713_PWDN_NRESP]; ^ drivers/media/radio/si4713/si4713.c:437:16: error: 'struct si4713_device' has no member named 'supply_data' ^ drivers/media/radio/si4713/si4713.c: In function 'si4713_probe': drivers/media/radio/si4713/si4713.c:1444:7: error: 'struct si4713_device' has no member named 'supplies' /* si4713_probe - probe for the device */ ^ drivers/media/radio/si4713/si4713.c:1447:22: error: 'struct si4713_device' has no member named 'supplies' { ^ drivers/media/radio/si4713/si4713.c:1448:7: error: 'struct si4713_device' has no member named 'supply_data' struct si4713_device *sdev; ^ drivers/media/radio/si4713/si4713.c:1450:46: error: 'struct si4713_device' has no member named 'supplies' struct v4l2_ctrl_handler *hdl; ^ drivers/media/radio/si4713/si4713.c:1451:11: error: 'struct si4713_device' has no member named 'supply_data' int rval, i; ^ drivers/media/radio/si4713/si4713.c:1583:26: error: 'struct si4713_device' has no member named 'supplies' ^ drivers/media/radio/si4713/si4713.c:1583:42: error: 'struct si4713_device' has no member named 'supply_data' ^ drivers/media/radio/si4713/si4713.c: In function 'si4713_remove': drivers/media/radio/si4713/si4713.c:1607:26: error: 'struct si4713_device' has no member named 'supplies' goto free_irq; ^ drivers/media/radio/si4713/si4713.c:1607:42: error: 'struct si4713_device' has no member named 'supply_data' goto free_irq; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: fix twl4030 build regression
Recent changes to the common OTG handling broke building the twl4030 OTG driver as found during an allmodconfig build of linux-next: drivers/phy/phy-twl4030-usb.c: In function 'twl4030_set_peripheral': drivers/phy/phy-twl4030-usb.c:609:11: error: 'struct phy' has no member named 'state' drivers/phy/phy-twl4030-usb.c: In function 'twl4030_usb_probe': drivers/phy/phy-twl4030-usb.c:679:12: warning: assignment from incompatible pointer type This applies the same changes that were done to the other phy drivers to get it to build cleanly. Signed-off-by: Arnd Bergmann Fixes: 19c1eac2685b6 ("usb: rename phy to usb_phy in OTG") Fixes: e47d92545c297 ("usb: move the OTG state from the USB PHY to the OTG structure") --- I have no idea if this is the correct fix, this is just a mechanical conversion, so please review carefully. diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 7b04befd5271..e2698d29f436 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -606,7 +606,7 @@ static int twl4030_set_peripheral(struct usb_otg *otg, otg->gadget = gadget; if (!gadget) - otg->phy->state = OTG_STATE_UNDEFINED; + otg->state = OTG_STATE_UNDEFINED; return 0; } @@ -618,7 +618,7 @@ static int twl4030_set_host(struct usb_otg *otg, struct usb_bus *host) otg->host = host; if (!host) - otg->phy->state = OTG_STATE_UNDEFINED; + otg->state = OTG_STATE_UNDEFINED; return 0; } @@ -676,7 +676,7 @@ static int twl4030_usb_probe(struct platform_device *pdev) twl->phy.otg= otg; twl->phy.type = USB_PHY_TYPE_USB2; - otg->phy= &twl->phy; + otg->usb_phy= &twl->phy; otg->set_host = twl4030_set_host; otg->set_peripheral = twl4030_set_peripheral; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Brad Griffis This patch makes the initial changes required to workaround TSC-false pen-up interrupts. It is required to implement these changes in order to remove udelay in the TSC interrupt handler and false pen-up events. The charge step is to be executed immediately after sampling X+. Hence TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate readouts, 4 wire TSC configuration) and ADC to use lower ones. Further X co-ordinate readouts must be the last to be sampled, thus co-ordinates are sampled in the order Y-Z-X. Signed-off-by: Brad Griffis [vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2] Signed-off-by: Vignesh R Acked-by: Jonathan Cameron --- drivers/iio/adc/ti_am335x_adc.c | 5 ++-- drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++- 2 files changed, 26 insertions(+), 21 deletions(-) diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c index b730864731e8..adba23246474 100644 --- a/drivers/iio/adc/ti_am335x_adc.c +++ b/drivers/iio/adc/ti_am335x_adc.c @@ -86,19 +86,18 @@ static void tiadc_step_config(struct iio_dev *indio_dev) { struct tiadc_device *adc_dev = iio_priv(indio_dev); unsigned int stepconfig; - int i, steps; + int i, steps = 0; /* * There are 16 configurable steps and 8 analog input * lines available which are shared between Touchscreen and ADC. * -* Steps backwards i.e. from 16 towards 0 are used by ADC +* Steps forwards i.e. from 0 towards 16 are used by ADC * depending on number of input lines needed. * Channel would represent which analog input * needs to be given to ADC to digitalize data. */ - steps = TOTAL_STEPS - adc_dev->channels; if (iio_buffer_enabled(indio_dev)) stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1 | STEPCONFIG_MODE_SWCNT; diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 2ce649520fe0..1aeac9675fe7 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev) { unsigned intconfig; int i; - int end_step; + int end_step, first_step, tsc_steps; u32 stepenable; config = STEPCONFIG_MODE_HWSYNC | @@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev) break; } - /* 1 … coordinate_readouts is for X */ - end_step = ts_dev->coordinate_readouts; - for (i = 0; i < end_step; i++) { + tsc_steps = ts_dev->coordinate_readouts * 2 + 2; + first_step = TOTAL_STEPS - tsc_steps; + /* Steps 16 to 16-coordinate_readouts is for X */ + end_step = first_step + tsc_steps; + for (i = end_step - ts_dev->coordinate_readouts; i < end_step; i++) { titsc_writel(ts_dev, REG_STEPCONFIG(i), config); titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY); } @@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev) break; } - /* coordinate_readouts … coordinate_readouts * 2 is for Y */ - end_step = ts_dev->coordinate_readouts * 2; - for (i = ts_dev->coordinate_readouts; i < end_step; i++) { + /* 1 ... coordinate_readouts is for Y */ + end_step = first_step + ts_dev->coordinate_readouts; + for (i = first_step; i < end_step; i++) { titsc_writel(ts_dev, REG_STEPCONFIG(i), config); titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY); } @@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev) titsc_writel(ts_dev, REG_CHARGECONFIG, config); titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY); - /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */ + /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */ config = STEPCONFIG_MODE_HWSYNC | STEPCONFIG_AVG_16 | ts_dev->bit_yp | ts_dev->bit_xn | STEPCONFIG_INM_ADCREFM | @@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev) titsc_writel(ts_dev, REG_STEPDELAY(end_step), STEPCONFIG_OPENDLY); - /* The steps1 … end and bit 0 for TS_Charge */ - stepenable = (1 << (end_step + 2)) - 1; + /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */ + stepenable = 1; + for (i = 0; i < tsc_steps; i++) + stepenable |= 1 << (first_step + i + 1); + ts_dev->step_mask = stepenable; am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask); } @@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev, unsigned int read, diff;
[PATCH v3 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Brad Griffis TSC interrupt handler had udelay to avoid reporting of false pen-up interrupt to user space. This patch implements workaround suggesting in Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay and touchscreen lag. This also improves performance of touchscreen and eliminates sudden jump of cursor at touch release. IDLECONFIG and CHARGECONFIG registers are to be configured with same values in order to eliminate false pen-up events. This workaround may result in false pen-down to be detected, hence considerable charge step delay needs to be added. The charge delay is set to 0xB000 (in terms of ADC clock cycles) by default. TSC steps are disabled at the end of every sampling cycle and EOS bit is set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin next sampling cycle. Signed-off-by: Brad Griffis [vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2] Signed-off-by: Vignesh R Acked-by: Lee Jones --- drivers/input/touchscreen/ti_am335x_tsc.c | 56 --- include/linux/mfd/ti_am335x_tscadc.h | 3 +- 2 files changed, 24 insertions(+), 35 deletions(-) diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 1aeac9675fe7..483fd97c0e0c 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -173,11 +173,9 @@ static void titsc_step_config(struct titsc *ts_dev) titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY); } - /* Charge step configuration */ - config = ts_dev->bit_xp | ts_dev->bit_yn | - STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR | - STEPCHARGE_INM_AN1 | STEPCHARGE_INP(ts_dev->inp_yp); + /* Make CHARGECONFIG same as IDLECONFIG */ + config = titsc_readl(ts_dev, REG_IDLECONFIG); titsc_writel(ts_dev, REG_CHARGECONFIG, config); titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY); @@ -264,9 +262,26 @@ static irqreturn_t titsc_irq(int irq, void *dev) unsigned int status, irqclr = 0; unsigned int x = 0, y = 0; unsigned int z1, z2, z; - unsigned int fsm; - status = titsc_readl(ts_dev, REG_IRQSTATUS); + status = titsc_readl(ts_dev, REG_RAWIRQSTATUS); + if (status & IRQENB_HW_PEN) { + ts_dev->pen_down = true; + titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00); + titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN); + irqclr |= IRQENB_HW_PEN; + } + + if (status & IRQENB_PENUP) { + ts_dev->pen_down = false; + input_report_key(input_dev, BTN_TOUCH, 0); + input_report_abs(input_dev, ABS_PRESSURE, 0); + input_sync(input_dev); + irqclr |= IRQENB_PENUP; + } + + if (status & IRQENB_EOS) + irqclr |= IRQENB_EOS; + /* * ADC and touchscreen share the IRQ line. * FIFO1 interrupts are used by ADC. Handle FIFO0 IRQs here only @@ -297,34 +312,6 @@ static irqreturn_t titsc_irq(int irq, void *dev) } irqclr |= IRQENB_FIFO0THRES; } - - /* -* Time for sequencer to settle, to read -* correct state of the sequencer. -*/ - udelay(SEQ_SETTLE); - - status = titsc_readl(ts_dev, REG_RAWIRQSTATUS); - if (status & IRQENB_PENUP) { - /* Pen up event */ - fsm = titsc_readl(ts_dev, REG_ADCFSM); - if (fsm == ADCFSM_STEPID) { - ts_dev->pen_down = false; - input_report_key(input_dev, BTN_TOUCH, 0); - input_report_abs(input_dev, ABS_PRESSURE, 0); - input_sync(input_dev); - } else { - ts_dev->pen_down = true; - } - irqclr |= IRQENB_PENUP; - } - - if (status & IRQENB_HW_PEN) { - - titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00); - titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN); - } - if (irqclr) { titsc_writel(ts_dev, REG_IRQSTATUS, irqclr); am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask); @@ -417,6 +404,7 @@ static int titsc_probe(struct platform_device *pdev) } titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES); + titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS); err = titsc_config_wires(ts_dev); if (err) { dev_err(&pdev->dev, "wrong i/p wire configuration\n"); diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index e2e70053470e..c99be5dc0f5c 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -52,6 +52,7 @@ /* IRQ enable */ #define IRQENB_HW_PEN BIT(0) +#define IRQENB_EOS BIT(1)
[PATCH v3 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
In one shot mode, sequencer automatically disables all enabled steps at the end of each cycle. (both ADC steps and TSC steps) Hence these steps need not be saved in reg_se_cache for clearing these steps at a later stage. Also, when ADC wakes up Sequencer should not be busy executing any of the config steps except for the charge step. Previously charge step was 1 ADC clock cycle and hence it was ignored. Signed-off-by: Vignesh R --- drivers/mfd/ti_am335x_tscadc.c | 7 +-- include/linux/mfd/ti_am335x_tscadc.h | 1 + 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c index d877e777cce6..110038859a8d 100644 --- a/drivers/mfd/ti_am335x_tscadc.c +++ b/drivers/mfd/ti_am335x_tscadc.c @@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev *tsadc) spin_lock_irq(&tsadc->reg_lock); finish_wait(&tsadc->reg_se_wait, &wait); + /* +* Sequencer should either be idle or +* busy applying the charge step. +*/ reg = tscadc_readl(tsadc, REG_ADCFSM); - WARN_ON(reg & SEQ_STATUS); + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP)); tsadc->adc_waiting = false; } tsadc->adc_in_use = true; @@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev *tsadc) void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val) { spin_lock_irq(&tsadc->reg_lock); - tsadc->reg_se_cache |= val; am335x_tscadc_need_adc(tsadc); tscadc_writel(tsadc, REG_SE, val); diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index c99be5dc0f5c..fcce182e4a35 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -128,6 +128,7 @@ /* Sequencer Status */ #define SEQ_STATUS BIT(5) +#define CHARGE_STEP0x11 #define ADC_CLK300 #define TOTAL_STEPS16 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/6] input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter
This patch reads charge delay from tsc DT node and writes to REG_CHARGEDELAY register. If the charge delay is not specified in DT then default value of 0xB000(CHARGEDLY_OPENDLY) is used. Signed-off-by: Vignesh R --- drivers/input/touchscreen/ti_am335x_tsc.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 483fd97c0e0c..20ce76b1b6e7 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -52,6 +52,7 @@ struct titsc { u32 bit_xp, bit_xn, bit_yp, bit_yn; u32 inp_xp, inp_xn, inp_yp, inp_yn; u32 step_mask; + u32 charge_delay; }; static unsigned int titsc_readl(struct titsc *ts, unsigned int reg) @@ -177,7 +178,7 @@ static void titsc_step_config(struct titsc *ts_dev) config = titsc_readl(ts_dev, REG_IDLECONFIG); titsc_writel(ts_dev, REG_CHARGECONFIG, config); - titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY); + titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev->charge_delay); /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */ config = STEPCONFIG_MODE_HWSYNC | @@ -361,6 +362,11 @@ static int titsc_parse_dt(struct platform_device *pdev, if (err < 0) return err; + err = of_property_read_u32(node, "ti,charge-delay", + &ts_dev->charge_delay); + if (err < 0) + ts_dev->charge_delay = CHARGEDLY_OPENDLY; + return of_property_read_u32_array(node, "ti,wire-config", ts_dev->config_inp, ARRAY_SIZE(ts_dev->config_inp)); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] ARM: dts: AM335x: Make charge delay a DT parameter for tsc
The charge delay value is by default 0xB000. But it can be set to lower values on some boards as long as false pen-ups are avoided. Lowering the value increases the sampling rate (though current sampling rate is sufficient for tsc operation). Hence charge delay has been made a DT parameter. Signed-off-by: Vignesh R --- .../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++ arch/arm/boot/dts/am335x-evm.dts | 1 + 2 files changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt index 878549ba814d..b87574bae009 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -28,6 +28,20 @@ Required properties: ti,adc-channels: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. +Optional properties: +- child "tsc" + ti,charge-delay: Length of touch screen charge delay step in terms of +ADC clock cycles. Charge delay value should be large +in order to avoid false pen-up events. This value +affects the overall sampling speed, hence need to be +kept as low as possible, while avoiding false pen-up +event. Start from a lower value, say 0x400, and +increase value until false pen-up events are avoided. +The pen-up detection happens immediately after the +charge step, so this does in fact function as a +hardware knob for adjusting the amount of "settling +time". + Example: tscadc: tscadc@44e0d000 { compatible = "ti,am3359-tscadc"; @@ -36,6 +50,7 @@ Example: ti,x-plate-resistance = <200>; ti,coordiante-readouts = <5>; ti,wire-config = <0x00 0x11 0x22 0x33>; + ti,charge-delay = <0xB000>; }; adc { diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index e2156a583de7..80be0462298b 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -641,6 +641,7 @@ ti,x-plate-resistance = <200>; ti,coordinate-readouts = <5>; ti,wire-config = <0x00 0x11 0x22 0x33>; + ti,charge-delay = <0xB000>; }; adc { -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] Touchscreen performance related fixes
This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. A DT parameter to configure the duration of tsc charge step. It represents number of ADC clock cycles to wait between applying the step configuration registers and going back to the IDLE state. The charge delay value can vary across boards. Configuring correct value of charge delay is important to avoid false pen-up events. Hence it is necessary to expose charge-delay value as DT parameter. The pen-up detection happens immediately after the charge step so this does in fact function as a hardware knob for adjusting the amount of settling time. After applying these changes false pen-up events have not be observed and smooth circles can be drawn on touch screen. The performance is much better in recognizing quick movement across the screen. No lag or cursor jump is observed. Change log: v3: - Replace delta filtering logic in TSC driver with median filtering as suggested by Richard. - Addressed Lee Jones comments. v2: - Addressed comments by Hartmut Knaack - patch 2 was split into two as per Lee Jones comment Brad Griffis (2): input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler Vignesh R (4): mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save ARM: dts: AM335x: Make charge delay a DT parameter for tsc input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering .../bindings/input/touchscreen/ti-tsc-adc.txt | 15 ++ arch/arm/boot/dts/am335x-evm.dts | 1 + drivers/iio/adc/ti_am335x_adc.c| 5 +- drivers/input/touchscreen/ti_am335x_tsc.c | 179 +++-- drivers/mfd/ti_am335x_tscadc.c | 7 +- include/linux/mfd/ti_am335x_tscadc.h | 4 +- 6 files changed, 121 insertions(+), 90 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/6] input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering
Previously, delta filtering was applied TSC co-ordinate readouts before reporting a single value to user space. This patch replaces delta filtering with median filtering. Median filtering sorts co-ordinate readouts, drops min and max values, and reports the average of remaining values. This method is more sensible than delta filering. Median filtering is applied only if number of readouts is greater than 3 else just average of co-ordinate readouts is reported. Signed-off-by: Vignesh R --- drivers/input/touchscreen/ti_am335x_tsc.c | 91 +-- 1 file changed, 51 insertions(+), 40 deletions(-) diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index 20ce76b1b6e7..e1df470946e6 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -26,6 +26,7 @@ #include #include #include +#include #include @@ -204,56 +205,61 @@ static void titsc_step_config(struct titsc *ts_dev) am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask); } +static int titsc_cmp_coord(const void *a, const void *b) +{ + return *(int *)a - *(int *)b; +} + static void titsc_read_coordinates(struct titsc *ts_dev, u32 *x, u32 *y, u32 *z1, u32 *z2) { - unsigned int fifocount = titsc_readl(ts_dev, REG_FIFO0CNT); - unsigned int prev_val_x = ~0, prev_val_y = ~0; - unsigned int prev_diff_x = ~0, prev_diff_y = ~0; - unsigned int read, diff; - unsigned int i, channel; + unsigned int yvals[7], xvals[7]; + unsigned int i, xsum = 0, ysum = 0; unsigned int creads = ts_dev->coordinate_readouts; - unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2); - *z1 = *z2 = 0; - if (fifocount % (creads * 2 + 2)) - fifocount -= fifocount % (creads * 2 + 2); - /* -* Delta filter is used to remove large variations in sampled -* values from ADC. The filter tries to predict where the next -* coordinate could be. This is done by taking a previous -* coordinate and subtracting it form current one. Further the -* algorithm compares the difference with that of a present value, -* if true the value is reported to the sub system. -*/ - for (i = 0; i < fifocount; i++) { - read = titsc_readl(ts_dev, REG_FIFO0); - - channel = (read & 0xf) >> 16; - read &= 0xfff; - if (channel > first_step + creads + 2) { - diff = abs(read - prev_val_x); - if (diff < prev_diff_x) { - prev_diff_x = diff; - *x = read; - } - prev_val_x = read; + for (i = 0; i < creads; i++) { + yvals[i] = titsc_readl(ts_dev, REG_FIFO0); + yvals[i] &= 0xfff; + } - } else if (channel == first_step + creads + 1) { - *z1 = read; + *z1 = titsc_readl(ts_dev, REG_FIFO0); + *z1 &= 0xfff; + *z2 = titsc_readl(ts_dev, REG_FIFO0); + *z2 &= 0xfff; - } else if (channel == first_step + creads + 2) { - *z2 = read; + for (i = 0; i < creads; i++) { + xvals[i] = titsc_readl(ts_dev, REG_FIFO0); + xvals[i] &= 0xfff; + } - } else if (channel > first_step) { - diff = abs(read - prev_val_y); - if (diff < prev_diff_y) { - prev_diff_y = diff; - *y = read; - } - prev_val_y = read; + /* +* If co-ordinates readouts is less than 4 then +* report the average. In case of 4 or more +* readouts, sort the co-ordinate samples, drop +* min and max values and report the average of +* remaining values. +*/ + if (creads <= 3) { + for (i = 0; i < creads; i++) { + ysum += yvals[i]; + xsum += xvals[i]; } + ysum /= creads; + xsum /= creads; + } else { + sort(yvals, creads, sizeof(unsigned int), +titsc_cmp_coord, NULL); + sort(xvals, creads, sizeof(unsigned int), +titsc_cmp_coord, NULL); + for (i = 1; i < creads - 1; i++) { + ysum += yvals[i]; + xsum += xvals[i]; + } + ysum /= creads - 2; + xsum /= creads - 2; } + *y = ysum; + *x = xsum; } static irqreturn_t titsc_irq(int irq, void *dev) @@ -362,6 +368,11 @@ static int titsc_parse_dt(struct platform_device *pdev, if (err < 0) return err; + if (ts_dev->coordi