Re: [PATCH v2 04/18] ARM: am57xx: cl-som-am57x: dts: add EEPROM support
On 11/30/15 16:33, Dmitry Lifshitz wrote:
> On-board EEPROM chip is used for storing a board production
> info.
>
> Add module EEPROM support (over I2C4 bus).
>
> Signed-off-by: Dmitry Lifshitz
Acked-by: Igor Grinberg
> ---
>
> v2:
>
>* Fix EEPROM chip model
>
> arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> index 9f15dda..695f250 100644
> --- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -290,6 +290,12 @@
> compatible = "emmicro,em3027";
> reg = <0x56>;
> };
> +
> + eeprom_module: atmel@50 {
> + compatible = "atmel,24c08";
> + reg = <0x50>;
> + pagesize = <16>;
> + };
> };
>
>
>
--
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: [PATCH 04/18] ARM: am57xx: cl-som-am57x: dts: add EEPROM support
Hi Dima,
On 11/25/15 08:39, Dmitry Lifshitz wrote:
> On-board EEPROM chip is used for storing a board production
> info.
>
> Add module EEPROM support (over I2C4 bus).
>
> Signed-off-by: Dmitry Lifshitz
> ---
> arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> index eb9b81b..b6919a7 100644
> --- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -289,6 +289,12 @@
> compatible = "emmicro,em3027";
> reg = <0x56>;
> };
> +
> + eeprom_module: atmel@50 {
> + compatible = "atmel,24c02";
If I'm not mistaken, the eeprom should be 24c08, no?
> + reg = <0x50>;
> + pagesize = <16>;
> + };
> };
>
>
>
--
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: [PATCH 1/6] ARM: OMAP2+: dts: cm-t335: add initial support
Hi Uri,
On 10/27/15 14:14, Uri Mashiach wrote:
> From: Ilya Ledvich
>
> Add basic support for CompuLab cm-t335 module based on AM335X SoC.
>
> CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
> The module is built around the Texas Instruments Sitara AM3352/4
> system-on-chip.
>
> The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
> NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
> Ethernet, CAN bus.
>
> Current patch adds support:
> UART0 and GPIO LED
>
> Detailed description can be found at the module site:
> http://www.compulab.co.il/products/computer-on-modules/cm-t335/
[...]
> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> new file mode 100644
> index 000..197d5ce
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -0,0 +1,62 @@
[...]
> +&am33xx_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + gpio_led_pins: pinmux_gpio_led_pins {
> + pinctrl-single,pins = <
> + 0x88 (PIN_OUTPUT | MUX_MODE7) /* gpmc_csn3.gpio2_0 */
> + >;
> + };
> +
> + uart0_pins: pinmux_uart0_pins {
> + pinctrl-single,pins = <
> + /* uart0_rxd.uart0_rxd */
> + 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)
> + /* uart0_txd.uart0_txd */
> + 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
Can we use AM33XX_IOPAD macro here?
and may be other patches too?
[...]
--
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: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
Hi Matt,
On 07/27/15 17:34, Matt Porter wrote:
> On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
>> phyCORE-AM335x is a SoM (System on Module) containing
>> a AM335x SOC. The module can be connected to different
>> carrier boards.
>>
>> Some hardware parts are configurable on the phyCORE-AM335x.
>> So they are disabled on default in this som dtsi file.
>> They will be enabled in the board dts files, when populated.
>>
>> * RAM up to 1GiB
>> * PMIC
>> * NAND flash up to 1GiB
>> * Eth PHY on SOM: 1x RMII
>> * SPI NOR flash 8MiB (optional)
>> * i2c RTC (optional)
>> * i2c EEPROM 4kiB (optional)
>>
>> Signed-off-by: Teresa Remmet
>> ---
>> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
>> ++
>> 1 file changed, 368 insertions(+)
>> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
>>
>> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
>> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
>> new file mode 100644
>> index 000..4d28fc3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
[...]
>> +#include "am33xx.dtsi"
>> +
>> +/ {
>> +model = "Phytec AM335x phyCORE";
>> +compatible = "phytec,am335x-phycore-som", "ti,am33xx";
>
> One minor thing here...wildcards in compatible strings aren't permitted.
> However, family compatibles like "ti,am33xx" that came in before this
> was enforced are grandfathered. Ideally, the newly introced board/som
> specific strings should not propagate that wildcard. i.e. something
> like "phytec,am3352-phycore-som" or whatever is the base family part
> on these SOMs.
>
I'm not sure this is wild card.
I tend to think that it is the real name of the som [1], no?
http://phytec.com/products/system-on-modules/phycore/am335x/
[...]
--
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: [rtc-linux] [PATCH] rtc: OMAP: Add external 32k clock feature
Hi,
On 04/07/15 06:29, Keerthy wrote:
> Hi Andrew,
>
> Apologies for replying late.
>
> On Wednesday 25 March 2015 04:29 AM, Andrew Morton wrote:
>> On Tue, 3 Mar 2015 15:12:02 +0530 Keerthy wrote:
>>
>>> Add external 32k clock feature. The internal clock will be gated during
>>> suspend.
>>> Hence make use of the external 32k clock so that rtc is functional accross
>>> suspend/resume.
>>>
>>> ...
>>>
>>> @@ -446,6 +449,7 @@ static const struct omap_rtc_device_type
>>> omap_rtc_default_type = {
>>>
>>> static const struct omap_rtc_device_type omap_rtc_am3352_type = {
>>> .has_32kclk_en= true,
>>> +.has_osc_ext_32k = true,
>>> .has_kicker= true,
>>> .has_irqwakeen= true,
>>> .has_pmic_mode= true,
>>> @@ -543,7 +547,16 @@ static int __init omap_rtc_probe(struct
>>> platform_device *pdev)
>>> if (rtc->type->has_32kclk_en) {
>>> reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
>>> rtc_writel(rtc, OMAP_RTC_OSC_REG,
>>> -reg | OMAP_RTC_OSC_32KCLK_EN);
>>> + reg | OMAP_RTC_OSC_32KCLK_EN);
>>> +}
>>> +
>>> +/* Enable External clock as the source */
>>> +
>>> +if (rtc->type->has_osc_ext_32k) {
>>> +rtc_writel(rtc, OMAP_RTC_OSC_REG,
>>> + (OMAP_RTC_OSC_EXT_32K |
>>> + rtc_read(rtc, OMAP_RTC_OSC_REG)) &
>>> + (~OMAP_RTC_OSC_OSC32K_GZ));
>>> }
>>
>> How do we know that all systems have this external clock and that it
>> works OK?
>>
>
> AM335 and AM43X have the external clock feature which we choose using
> RTC_OSC_REG. I verified it works OK by seeing the RTC seconds ticking
> even after switching the source to the external 32k Clock.
AFAIU, this is related to the external (outside of SoC) oscillator, right?
If so, there is a possibility to not assemble it on the board (at least
on AM335) and use the internal clock source instead.
There are dozens of boards out there that do not have the external
oscillator assembled.
Am I missing something?
--
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: [PATCH 06/15] omap3isp: Refactor device configuration structs for Device Tree
On 03/16/15 02:26, Sakari Ailus wrote: > Make omap3isp configuration data structures more suitable for consumption by > the DT by separating the I2C bus information of all the sub-devices in a > group and the ISP bus information from each other. The ISP bus information > is made a pointer instead of being directly embedded in the struct. > > In the case of the DT only the sensor specific information on the ISP bus > configuration is retained. The structs are renamed to reflect that. > > After this change the structs needed to describe device configuration can be > allocated and accessed separately without those needed only in the case of > platform data. The platform data related structs can be later removed once > the support for platform data can be removed. > > Signed-off-by: Sakari Ailus > Acked-by: Laurent Pinchart > Cc: Igor Grinberg For cm-t35 stuff: Acked-by: Igor Grinberg -- 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: [PATCH v2] ARM: dts: cm-t3x: add NAND support
On 12/28/14 16:30, Dmitry Lifshitz wrote: > CM-T3517, CM-T3530 and CM-T3730 features NAND storage chip connected to > GPMC bus. > > Add GPMC DT entry into the root DT file omap3-cm-t3x.dtsi, common for > all three modules. > > NAND timings are calculated to be safe for CM-T3x devices as it works > now in non DT boot (in this case the timings are updated by U-Boot). > > Update GPMC ranges in boards DT files to include all connected devices. > > Signed-off-by: Dmitry Lifshitz Acked-by: Igor Grinberg -- 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: [PATCH] ARM: dts: cm-t3x: add NAND support
Hi Dima, On 12/28/14 15:15, Dmitry Lifshitz wrote: > Add NAND support > > Signed-off-by: Dmitry Lifshitz > --- > arch/arm/boot/dts/omap3-cm-t3x.dtsi | 58 > + > arch/arm/boot/dts/omap3-sbc-t3517.dts |4 ++ > arch/arm/boot/dts/omap3-sbc-t3530.dts | 10 ++ > arch/arm/boot/dts/omap3-sbc-t3730.dts |5 ++- > 4 files changed, 68 insertions(+), 9 deletions(-) It seems that you have missed the omap3-cm-t3x30.dtsi. If after this patch you build omap3-cm-t3530.dts or omap3-cm-t3730.dts, it will not have NAND, while they should get it as well. -- 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: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/14 17:09, Felipe Balbi wrote: > Hi, > > On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote: >>>>>> Tony, your call. >>>>> >>>>> I think we should move omap2plus_defconfig to be mostly modular and >>>>> usable for distros as a base. Most distros prefer to build almost >>>>> everything as loadable modules. And my preference is that we should >>>>> only keep the minimum rootfs for devices and serial support as >>>>> built-in and rely on initramfs for most drivers. And slowly move >>>>> also the remaining built-in drivers to be loadable modules. >>>>> >>>>> The reasons for having drivers as loadable modules are many. It >>>>> allows distros to use the same kernel for all the devices without >>>>> bloating the kernel. It makes developing drivers easier as just the >>>>> module needs to be reloaded. And loadable modules protect us from >>>>> cross-framework spaghetti calls in the kernel as the interfaces are >>>>> clearly defined. >>>>> >>>>> Are there people really using SATA as rootfs right now on omaps? >>>> >>>> Yes. That is exactly my point. >>> >>> read your email, you said it *CAN* have rootfs on SATA. >> >> yep, it also *CAN* have rootfs on MMC and NFS and ... > > those we *know* people are using as rootfs. We know of several users who > are actually using it :-) I think we've had enough of the *can* or *cannot* stuff... So, just accept that people are using SATA as rootfs and will be using it in the future products too. > >>>>> If it's only something that will be more widely used in the future, >>>>> then I suggest we make it into a loadable module, and presume >>>>> initramfs and loadable module also for any new devices. The same >>>>> way x86 has been doing with distros for years. >>>> >>>> The difference from x86 is that we're in embedded here and >>> >>> bullshit, you would never ship a product with omap2plus_defconfig. You'd >>> build your own at which point you would switch SATA to built-in. >> >> Yep, that is one of the options indeed, but I'm not asking you to >> deal with my problems, right? >> I'm feeling like you are trying to insult me. >> Are you angry with me? Why? >> Is it because I have a different opinion? > > heh, cute :-) so this is what it takes to calm you down? good! > >>>> although initramfs is a kind of option, but it means, you need to >>>> load even more data during the boot process... it is annoying and >>>> I would not want to use it on embedded. >>> >>> make your own defconfig. >> >> This sounds like: mind your own business... >> Is that what you want to say? > > nope, not really. good! > Just saying that if you're really concerned about > being embedded and that initramfs takes that much more time to load, > you'd just make your own defconfig and maintain it out-of-tree. > > RMK does that for quite a few boards, I do it for my boards and also for > my x86 desktops/laptops. > > It's not really rocket science. Yes indeed. We do this *all* the time. To understand what is this about, first you need to make yourself familiar with the case. > >>>> (BTW, x86_64_defconfig has it compiled in...) >>>> >>>> We can also, split the defconfig as it was some time ago... but I >>>> would not want to go that direction... >>>> >>>> If we go the initramfs way, then why not also load MMC from it? >>>> That will also reduce kernel size... (but add initramfs size) >>> >>> I'm fine with that. The difference is that people have been relying on >>> MMC built-in for the past 10+ years, since the old OMAP1 MMC driver, >>> changing that now is likely to cause some "my board won't boot anymore" >>> bug reports. >> >> Yep. So there are exceptions, right? > > never claimed the contrary. So, those exactly kind of bug reports I'm expecting to get, once you compile out SATA... > >>>> I'm sure you will find making the MMC a loadable module inconvenient. >>>> That how I find making the SATA a loadable module... >>>> >>>> Right now, we tell our customers that they can use mainline with >>>> omap2plus_defconfig. >>> >>> that's the worst
Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/14 06:37, Felipe Balbi wrote: > Hi, > > On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote: >> * Felipe Balbi [141224 07:52]: >>> Hi, >>> >>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> On 12/23/14 18:19, Felipe Balbi wrote: >>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: >>>>>> Hi Felipe, >>>>>> >>>>>> On 12/22/14 20:05, Felipe Balbi wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> CONFIG_SCSI_SCAN_ASYNC=y >>>>>>> -CONFIG_ATA=y >>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y >>>>>>> -CONFIG_MD=y >>>>>>> +CONFIG_ATA=m >>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m >>>>>> >>>>>> Isn't this needed for the rootfs on SATA devices? >>>>> >>>>> there's no known boards with rootfs on SATA. Until then, we can reduce >>>>> the size. >>>> >>>> What makes you say so? >>>> The decision for rootfs on SATA is taken dynamically. >>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA... >>> >>> I'll leave the decision to Tony. Even though they _can_, they really >>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be >>> annoying to find that special device which works (e.g it can't negotiate >>> lower speeds with SATA III devices and it won't support SATA I). >>> >>> As of today, we don't know of anybody really shipping anything with >>> rootfs on SATA and distros would rather ship initiramfs than a giant >>> zImage anyway. >>> >>> Tony, your call. >> >> I think we should move omap2plus_defconfig to be mostly modular and >> usable for distros as a base. Most distros prefer to build almost >> everything as loadable modules. And my preference is that we should >> only keep the minimum rootfs for devices and serial support as >> built-in and rely on initramfs for most drivers. And slowly move >> also the remaining built-in drivers to be loadable modules. >> >> The reasons for having drivers as loadable modules are many. It >> allows distros to use the same kernel for all the devices without >> bloating the kernel. It makes developing drivers easier as just the >> module needs to be reloaded. And loadable modules protect us from >> cross-framework spaghetti calls in the kernel as the interfaces are >> clearly defined. >> >> Are there people really using SATA as rootfs right now on omaps? > > not that we know :-) The only platforms available today with SATA are > OMAP5432 uEVM and DRA7x EVM, I'm sorry... that is not true. > the latter being mostly used by TIers as of > now (at least from mainline point of view). the keyword is mostly... And I'm also not sure this is true these days... But, really, don't mind me. We will find our solutions (we always did). I mean, Felipe wants it out so badly... Who am I to say anything... > >> If it's only something that will be more widely used in the future, >> then I suggest we make it into a loadable module, and presume >> initramfs and loadable module also for any new devices. The same >> way x86 has been doing with distros for years. > > alright, as a module it shall remain. > - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUnU+qAAoJEBDE8YO64Efa8IgP/jQlP5nHLK8aWXpNIrRH3dri IzIDvWqUC+zYqIgg1JcPmxgfZ+5vhYgjCVx+q0m/81qk164QK4zGs6gDr8sDjK8O Q8rqujAbVFO2nmJHmq8VhTpapqTDtG5sH/HvtaWPtBxmBoA5yLdA8KObV9Gf2871 GvlP1WS/CUu6ClzEERsdWJkfpkqrJ1My1Ox7zCkL80uqM5z6jmje2sam4AiuGWSK Kb/Kdkmqae1lizjSnyW0ZckTyCuLUPdzvV+OCq3JrDDJV9W3hrA0KmYKUe4gO0JI Z2PNMKvbBuA9miY0IPsbILYkQ01OoKOwZXfDrhhK0k5FLPxSujc9NbfwqByTK2gi Ca5zZKoTaUN8A2YoxdNv+m9gILnlgDCtRjvc6elEYZBLZd+03TsxgWAB+aYfx03d 1W5+qp8jSGBRzsDg5o8ir6mS8xYM3Hpy7xDPT46BqjKzczMCdeXH5MqibL34kqtC mMhMw1UzZ5qGOyHXqYE9bosgfpbf+WxmVta7/RRgaJJwo7N41pf1sDyoJjczAfPo cAQNeIwPd1DxiS2nO46i4w8FUq10Lf3I7mXxabXIsU3YD81QpjxL5arlFXlPfDVg Ki8GW1yE81RepD5xuhhz3/U9pKvozSewH5BlHBo6h9rSBkyyBPs2NbxSxjSNct1H MKEG/rYHptCRIntrZ8pm =w62Y -END PGP SIGNATURE- -- 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] arm: omap: reduce zImage size on omap2plus_defconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/26/14 06:42, Felipe Balbi wrote: > Hi, > > On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote: >> Hi Tony, >> >> On 12/24/14 21:04, Tony Lindgren wrote: >>> * Felipe Balbi [141224 07:52]: >>>> Hi, >>>> >>>> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: >>>>> -BEGIN PGP SIGNED MESSAGE- >>>>> Hash: SHA1 >>>>> >>>>> On 12/23/14 18:19, Felipe Balbi wrote: >>>>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: >>>>>>> Hi Felipe, >>>>>>> >>>>>>> On 12/22/14 20:05, Felipe Balbi wrote: >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>>> CONFIG_SCSI_SCAN_ASYNC=y >>>>>>>> -CONFIG_ATA=y >>>>>>>> -CONFIG_SATA_AHCI_PLATFORM=y >>>>>>>> -CONFIG_MD=y >>>>>>>> +CONFIG_ATA=m >>>>>>>> +CONFIG_SATA_AHCI_PLATFORM=m >>>>>>> >>>>>>> Isn't this needed for the rootfs on SATA devices? >>>>>> >>>>>> there's no known boards with rootfs on SATA. Until then, we can reduce >>>>>> the size. >>>>> >>>>> What makes you say so? >>>>> The decision for rootfs on SATA is taken dynamically. >>>>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA... >>>> >>>> I'll leave the decision to Tony. Even though they _can_, they really >>>> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be >>>> annoying to find that special device which works (e.g it can't negotiate >>>> lower speeds with SATA III devices and it won't support SATA I). >> >> Yet, it is not that buggy and at least until now, I di not get any >> reports about badly working SATA from customers... >> >>>> >>>> As of today, we don't know of anybody really shipping anything with >>>> rootfs on SATA and distros would rather ship initiramfs than a giant >>>> zImage anyway. >> >> So, you just continue to ignore what I'm saying... even after I point >> to a device... > > you pointed a device which *can* have rootfs on SATA, not one which > *has* rootfs on SATA, there's a very big difference there. Yeah, I thought you will parse me in that way... > >> Is it SATA that makes it so giant? >> Because I find it worth having in SATA than spare some more k's... > > that's your point of view. As Tony mentioned, we have a very standard > way of dealing with this which is initramfs and x86 has been using that > for the past 15+ years. may be, but no... x86 has SATA built in... > >>>> Tony, your call. >>> >>> I think we should move omap2plus_defconfig to be mostly modular and >>> usable for distros as a base. Most distros prefer to build almost >>> everything as loadable modules. And my preference is that we should >>> only keep the minimum rootfs for devices and serial support as >>> built-in and rely on initramfs for most drivers. And slowly move >>> also the remaining built-in drivers to be loadable modules. >>> >>> The reasons for having drivers as loadable modules are many. It >>> allows distros to use the same kernel for all the devices without >>> bloating the kernel. It makes developing drivers easier as just the >>> module needs to be reloaded. And loadable modules protect us from >>> cross-framework spaghetti calls in the kernel as the interfaces are >>> clearly defined. >>> >>> Are there people really using SATA as rootfs right now on omaps? >> >> Yes. That is exactly my point. > > read your email, you said it *CAN* have rootfs on SATA. yep, it also *CAN* have rootfs on MMC and NFS and ... > >>> If it's only something that will be more widely used in the future, >>> then I suggest we make it into a loadable module, and presume >>> initramfs and loadable module also for any new devices. The same >>> way x86 has been doing with distros for years. >> >> The difference from x86 is that we're in embedded here and > > bullshit, you would never ship a product with omap2plus_defconfig. You'd > build your own at which point you would switch SATA to built-in. Yep, that is one of the options indeed, but I'm n
Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
Hi Tony, On 12/24/14 21:04, Tony Lindgren wrote: > * Felipe Balbi [141224 07:52]: >> Hi, >> >> On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 12/23/14 18:19, Felipe Balbi wrote: >>>> On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: >>>>> Hi Felipe, >>>>> >>>>> On 12/22/14 20:05, Felipe Balbi wrote: >>>>> >>>>> [...] >>>>> >>>>>> CONFIG_SCSI_SCAN_ASYNC=y >>>>>> -CONFIG_ATA=y >>>>>> -CONFIG_SATA_AHCI_PLATFORM=y >>>>>> -CONFIG_MD=y >>>>>> +CONFIG_ATA=m >>>>>> +CONFIG_SATA_AHCI_PLATFORM=m >>>>> >>>>> Isn't this needed for the rootfs on SATA devices? >>>> >>>> there's no known boards with rootfs on SATA. Until then, we can reduce >>>> the size. >>> >>> What makes you say so? >>> The decision for rootfs on SATA is taken dynamically. >>> OMAP5 boards (specifically cm-t54) can have rootfs on SATA... >> >> I'll leave the decision to Tony. Even though they _can_, they really >> don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be >> annoying to find that special device which works (e.g it can't negotiate >> lower speeds with SATA III devices and it won't support SATA I). Yet, it is not that buggy and at least until now, I di not get any reports about badly working SATA from customers... >> >> As of today, we don't know of anybody really shipping anything with >> rootfs on SATA and distros would rather ship initiramfs than a giant >> zImage anyway. So, you just continue to ignore what I'm saying... even after I point to a device... Is it SATA that makes it so giant? Because I find it worth having in SATA than spare some more k's... >> >> Tony, your call. > > I think we should move omap2plus_defconfig to be mostly modular and > usable for distros as a base. Most distros prefer to build almost > everything as loadable modules. And my preference is that we should > only keep the minimum rootfs for devices and serial support as > built-in and rely on initramfs for most drivers. And slowly move > also the remaining built-in drivers to be loadable modules. > > The reasons for having drivers as loadable modules are many. It > allows distros to use the same kernel for all the devices without > bloating the kernel. It makes developing drivers easier as just the > module needs to be reloaded. And loadable modules protect us from > cross-framework spaghetti calls in the kernel as the interfaces are > clearly defined. > > Are there people really using SATA as rootfs right now on omaps? Yes. That is exactly my point. > > If it's only something that will be more widely used in the future, > then I suggest we make it into a loadable module, and presume > initramfs and loadable module also for any new devices. The same > way x86 has been doing with distros for years. The difference from x86 is that we're in embedded here and although initramfs is a kind of option, but it means, you need to load even more data during the boot process... it is annoying and I would not want to use it on embedded. (BTW, x86_64_defconfig has it compiled in...) We can also, split the defconfig as it was some time ago... but I would not want to go that direction... If we go the initramfs way, then why not also load MMC from it? That will also reduce kernel size... (but add initramfs size) I'm sure you will find making the MMC a loadable module inconvenient. That how I find making the SATA a loadable module... Right now, we tell our customers that they can use mainline with omap2plus_defconfig. If you decide to drop SATA, we will not be able to do that anymore. Anyway, like Felipe said, it is your call. I will not interfere anymore... -- 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: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/14 18:19, Felipe Balbi wrote: > On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: >> Hi Felipe, >> >> On 12/22/14 20:05, Felipe Balbi wrote: >> >> [...] >> >>> CONFIG_SCSI_SCAN_ASYNC=y >>> -CONFIG_ATA=y >>> -CONFIG_SATA_AHCI_PLATFORM=y >>> -CONFIG_MD=y >>> +CONFIG_ATA=m >>> +CONFIG_SATA_AHCI_PLATFORM=m >> >> Isn't this needed for the rootfs on SATA devices? > > there's no known boards with rootfs on SATA. Until then, we can reduce > the size. What makes you say so? The decision for rootfs on SATA is taken dynamically. OMAP5 boards (specifically cm-t54) can have rootfs on SATA... > >>> CONFIG_NETDEVICES=y >>> # CONFIG_NET_VENDOR_ARC is not set >>> # CONFIG_NET_CADENCE is not set >>> @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y >>> # CONFIG_NET_VENDOR_WIZNET is not set >>> CONFIG_AT803X_PHY=y >>> CONFIG_SMSC_PHY=y >>> -CONFIG_USB_USBNET=y >>> -CONFIG_USB_NET_SMSC95XX=y >>> +CONFIG_USB_USBNET=m >>> +CONFIG_USB_NET_SMSC95XX=m >> >> What about the NFS root for boards with only USB eth? > > USB is a module already and it breaks PM when enabled. Well, USB is not a module currently, but after reading below I understand you mean HCDs are either disabled or modules. Ok that's fine with me. [...] >>> -CONFIG_USB=y >>> +CONFIG_HID_GENERIC=m >>> +CONFIG_USB_HIDDEV=y >>> +CONFIG_USB_KBD=m >>> +CONFIG_USB_MOUSE=m >>> +CONFIG_USB=m >> >> So, you don't consider USB a valid rootfs storage option? > > read the original defconfig. This is *only* for usbcore.ko, EHCI is > disabled, XHCI is a module, MUSB is disabled. What will you use for > rootfs ? Yes, thanks for pointing. Now I see indeed this is a sensible thing to do and probably should have been done a while ago. Might be worth addressing/explaining this in the commit message. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUmqlKAAoJEBDE8YO64EfaifUQAIdwJFKPozpzVeKJjIYKQgzy 4axv2/Z2TBybF6dlxykrjWwUIX8e24bAtG8uyhnQ/l6NPWVqNqwM/DHALyPBgjMV EXciALKHyx6DiHoeoTEhhCCocekI/fM9o0mqQHpqzp2M+/UAnHq2Px0pK6Cfk84y RoyrunlOKOe1rZSbcgZKoZDuMV0qYK2ULpMl3c7QL5sPIGrkWIGe2eTil3/m6jvu qDaVzGxsBmmCFVxMKv/cXysBd88cswg8sd2ptX7skgptB7lpSKRiAT69c3MXaJyM zsbE4AE9fiYb0/aZO3hmmWlNp6OM1hxY/8IjL92Sydys/bXxDHQj1fePr9ofsFYM vSohR6IOopv1xwr6PIKyL+brWJ0p07qKNWA5vrG21D/U0B6H/IPcSbneQtHnMkJl jf6GccX5gG49MSTDWryFOtErsNXRf6Q5zaZGYTpEsDMXhCKTYJgBhoFX5i3fW4wH kV/doXku38SAmwRBU0oLjNs07y1I0ijgBHLTtx3XZSd7fkM3CAWsToDapz7df+bx FAi0+DZk3DVNhJoAeyaRauZQlLU//3McM2zFX8/11K9BP76n6OTanYnjVoJq0SNo JIjEjmFMFtIF7Zke4JpUCkYlpcW17gQLfUCrcIW1WUq6i0TAGyILmDvZPgMp6+yk bqMgzSs8ZRXyjqm6Uj7O =UcBr -END PGP SIGNATURE- -- 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] arm: omap: reduce zImage size on omap2plus_defconfig
Hi Felipe, On 12/22/14 20:05, Felipe Balbi wrote: [...] > CONFIG_SCSI_SCAN_ASYNC=y > -CONFIG_ATA=y > -CONFIG_SATA_AHCI_PLATFORM=y > -CONFIG_MD=y > +CONFIG_ATA=m > +CONFIG_SATA_AHCI_PLATFORM=m Isn't this needed for the rootfs on SATA devices? > CONFIG_NETDEVICES=y > # CONFIG_NET_VENDOR_ARC is not set > # CONFIG_NET_CADENCE is not set > @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y > # CONFIG_NET_VENDOR_WIZNET is not set > CONFIG_AT803X_PHY=y > CONFIG_SMSC_PHY=y > -CONFIG_USB_USBNET=y > -CONFIG_USB_NET_SMSC95XX=y > +CONFIG_USB_USBNET=m > +CONFIG_USB_NET_SMSC95XX=m What about the NFS root for boards with only USB eth? [...] > CONFIG_DEBUG_GPIO=y > CONFIG_GPIO_SYSFS=y > -CONFIG_GPIO_TWL4030=y > -CONFIG_W1=y > +CONFIG_GPIO_TWL4030=m w/o this devices wired to twl gpios will not come up and likely will miss the enumeration... > -CONFIG_USB=y > +CONFIG_HID_GENERIC=m > +CONFIG_USB_HIDDEV=y > +CONFIG_USB_KBD=m > +CONFIG_USB_MOUSE=m > +CONFIG_USB=m So, you don't consider USB a valid rootfs storage option? > CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > -CONFIG_USB_MON=y > +CONFIG_USB_MON=m > CONFIG_USB_XHCI_HCD=m > -CONFIG_USB_WDM=y > -CONFIG_USB_STORAGE=y > +CONFIG_USB_WDM=m > +CONFIG_USB_STORAGE=m > +CONFIG_USB_MUSB_HDRC=m > +CONFIG_USB_MUSB_OMAP2PLUS=m > +CONFIG_USB_MUSB_AM35X=m > +CONFIG_USB_MUSB_DSPS=m [...] -- 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: OMAP baseline test results for v3.18-rc7
Hi Paul, On 12/02/14 20:39, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.18-rc7. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.18-rc7/20141201203859/ > > > Test summary > > [...] > Build: uImage+dtb: > Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, > omap2plus_defconfig/omap4-panda, > omap2plus_defconfig/omap4-panda-es, > omap2plus_defconfig/omap4-var-som, > omap2plus_defconfig/omap3-evm-37xx, > omap2plus_defconfig_n800_only_a/omap2420-n800, > omap2plus_defconfig/omap2430-sdp, > omap2plus_defconfig/am3517-evm, > omap2plus_defconfig/omap3-beagle, > omap2plus_defconfig/omap3-beagle-xm, > omap2plus_defconfig/omap3-sbc-t3517, > omap2plus_defconfig/omap5-uevm, > omap2plus_defconfig/omap5-sbc-t54 > [...] > Boot to userspace: > FAIL ( 1/16): 2430sdp > skip ( 2/16): 5912osk, 3517evm > Pass (13/16): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, > 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, > 3730beaglexm, 3730es12beaglexm, 5430es2uevm, > 5430es2sbct54, 2420n800 I've looked at the boot log and it seems cm-t3517 is booting just fine... A problem with the test/report collecting script? 5912osk is not listed by the link above, but there are indeed 16 entries... [...] -- 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: [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
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: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
On 11/04/14 17:42, Tony Lindgren wrote:
> * Igor Grinberg [141104 05:22]:
>> Hi Tony,
>>
>> On 11/02/14 20:07, 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.
>>
>> What about devices that really need to start once VBUS or CHG is connected?
>
> More handling can be added for some cases. With this patch the
> poweron bits will clear to defaults if power is completely removed.
> So start-up with VBUS and CHG works in that case.
>
> However, if you have a battery connected, and you poweroff, with
> this patch the device won't power up with VBUS or CHG connected.
>
> Note that most battery operated devices are not using the charger
> on twl4030 because it has issues charging a completely empty
> battery AFAIK. So most battery powered devices have been using an
> external USB charger chip that's not affected by this patch.
>
> We could consider exporting a function for the charger driver to
> configure the poweron mask. And we could also consider passing a
> mask in ti,use_poweroff = 0xff.
Ok. That sounds better to me.
Yet, if you say there are no such devices in practice,
IMHO, we can merge this.
>
>> It seems to me that forcing these bits on power off can break that kind of
>> devices and these settings should really be board specific.
>> What do you think?
>
> There's a patch series for "[RFC,01/16] kernel: Add support for
> poweroff handler call chain" that should help with that. For sure
> the poweroff handling needs to be board specific as some systems
> may need to use a GPIO to shut off a regulator powering something
> before powering off the SoC.
Yes, I've seen this series.
I'm not sure though that I understand how is this supposed
to be used with DT...
Through the regulator bindings?
Which will tell it to hook up on the call chain?
--
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: [PATCH] mfd: twl4030-power: Fix poweroff with PM configuration enabled
Hi Tony,
On 11/02/14 20:07, 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.
What about devices that really need to start once VBUS or CHG is connected?
It seems to me that forcing these bits on power off can break that kind of
devices and these settings should really be board specific.
What do you think?
>
> 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
>
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -44,6 +44,15 @@ static u8 twl4030_start_script_address = 0x2b;
> #define PWR_DEVSLP BIT(1)
> #define PWR_DEVOFF BIT(0)
>
> +/* Register bits for CFG_P1_TRANSITION (also for P2 and P3) */
> +#define STARTON_SWBUGBIT(7) /* Start on watchdog */
> +#define STARTON_VBUS BIT(5) /* Start on VBUS */
> +#define STARTON_VBAT BIT(4) /* Start on battery insert */
> +#define STARTON_RTC BIT(3) /* Start on RTC */
> +#define STARTON_USB BIT(2) /* Start on USB host */
> +#define STARTON_CHG BIT(1) /* Start on charger */
> +#define STARTON_PWON BIT(0) /* Start on PWRON button */
> +
> #define SEQ_OFFSYNC (1 << 0)
>
> #define PHY_TO_OFF_PM_MASTER(p) (p - 0x36)
> @@ -606,6 +615,44 @@ twl4030_power_configure_resources(const struct
> twl4030_power_data *pdata)
> return 0;
> }
>
> +static int twl4030_starton_mask_and_set(u8 bitmask, u8 bitvalues)
> +{
> + u8 regs[3] = { TWL4030_PM_MASTER_CFG_P1_TRANSITION,
> +TWL4030_PM_MASTER_CFG_P2_TRANSITION,
> +TWL4030_PM_MASTER_CFG_P3_TRANSITION, };
> + u8 val;
> + int i, err;
> +
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
> +TWL4030_PM_MASTER_PROTECT_KEY);
> + if (err)
> + goto relock;
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
> +TWL4030_PM_MASTER_KEY_CFG2,
> +TWL4030_PM_MASTER_PROTECT_KEY);
> + if (err)
> + goto relock;
> +
> + for (i = 0; i < sizeof(regs); i++) {
> + err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER,
> + &val, regs[i]);
> + if (err)
> + break;
> + val = (~bitmask & val) | (bitmask & bitvalues);
> + err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
> +val, regs[i]);
> + if (err)
> + break;
> + }
> +
> + if (err)
> + pr_err("TWL4030 Register access failed: %i\n", err);
> +
> +relock:
> + return twl_i2c_write_u8(TWL_MODULE_PM_MASTER, 0,
> + TWL4030_PM_MASTER_PROTECT_KEY);
> +}
> +
> /*
> * In master mode, start the power off sequence.
> * After a successful execution, TWL shuts down the power to the SoC
> @@ -615,6 +662,11 @@ void twl4030_power_off(void)
> {
> int err;
>
> + /* Disable start on charger or VBUS as it can break poweroff */
> + err = twl4030_starton_mask_and_set(STARTON_VBUS | STARTON_CHG, 0);
> + if (err)
> + pr_err("TWL4030 Unable to configure start-up\n");
> +
> err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, PWR_DEVOFF,
> TWL4030_PM_MASTER_P1_SW_EVENTS);
> if (err)
> --
> 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
>
--
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: [PATCH v2] ARM: dts: sbc-t3x: add DVI display data
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 -- 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: [PATCH] ARM: dts: sbc-t3x: add DVI display data
Hi Dmitry,
On 10/15/14 12:09, 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
> ---
> arch/arm/boot/dts/omap3-cm-t3517.dts | 22 +++
> arch/arm/boot/dts/omap3-cm-t3530.dts | 22 +++
> arch/arm/boot/dts/omap3-cm-t3730.dts | 24
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 28 +++
> arch/arm/boot/dts/omap3-sb-t35.dtsi | 49
> +
> arch/arm/boot/dts/omap3-sbc-t3517.dts | 14 +
> arch/arm/boot/dts/omap3-sbc-t3530.dts | 14 +
> arch/arm/boot/dts/omap3-sbc-t3730.dts | 14 +
> 8 files changed, 187 insertions(+), 0 deletions(-)
[...]
> diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
> b/arch/arm/boot/dts/omap3-cm-t3730.dts
> index b3f9a50..4b36d80 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3730.dts
> +++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
> @@ -31,6 +31,19 @@
> };
> };
>
> +&omap3_pmx_wkup {
> + dss_dpi_pins_cm_t3730: pinmux_dss_dpi_pins_cm_t3730 {
> + pinctrl-single,pins = <
> + 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18
> */
> + 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19
> */
> + 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20
> */
> + 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21
> */
> + 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22
> */
> + 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23
> */
Can't you use macros here as well?
> + >;
> + };
> +};
> +
[...]
> diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> index c671a22..6b6c2f4 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> +++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
> @@ -76,6 +76,34 @@
> OMAP3_CORE1_IOPAD(0x21e2, PIN_OUTPUT | MUX_MODE4)
> /* sys_clkout2.gpio_186 */
> >;
> };
> +
> + dss_dpi_pins_common: pinmux_dss_dpi_pins_common {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)
> /* dss_pclk.dss_pclk */
> + OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)
> /* dss_hsync.dss_hsync */
> + OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)
> /* dss_vsync.dss_vsync */
> + OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)
> /* dss_acbias.dss_acbias */
> +
> + OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)
> /* dss_data6.dss_data6 */
> + OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)
> /* dss_data7.dss_data7 */
> + OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)
> /* dss_data8.dss_data8 */
> + OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)
> /* dss_data9.dss_data9 */
> + OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)
> /* dss_data10.dss_data10 */
> + OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)
> /* dss_data11.dss_data11 */
> + OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)
> /* dss_data12.dss_data12 */
> + OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)
> /* dss_data13.dss_data13 */
> + OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)
> /* dss_data14.dss_data14 */
> + OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)
> /* dss_data15.dss_data15 */
> + OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)
> /* dss_data16.dss_data16 */
> + OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)
> /* dss_data17.dss_data17 */
> + OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE0)
> /* dss_data18.dss_data18 */
> + OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE0)
> /* dss_data19.dss_data19 */
> + OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE0)
> /* dss_data20.dss_data20 */
> + OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE0)
> /* dss_data21.dss_data21 */
> + OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE0)
> /* dss_data22.dss_data22 */
> + OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE0)
> /* dss_data23.dss_data23 */
> + >;
> + };
I would also define the second set of pins used for cm-t3530 and cm-t3517 here.
So you will not have to duplicate them too.
[...]
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
Re: OMAP baseline test results for v3.17-rc3
Hi Paul, On 09/03/14 02:52, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.17-rc3. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.17-rc3/20140902165525/ > > > Test summary > [...] > Boot to userspace: > FAIL ( 2/15): 2430sdp, 5430es2sbct54 > skip ( 1/15): 5912osk > Pass (12/15): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, > 37xxevm, 4430es2panda, 4460pandaes, am335xbone, > am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm [...] > A Compulab SBC-T54 (OMAP5432) has been added to the testbed, graciously > donated by Compulab and Igor Grinberg. It currently isn't booting to > userspace in the current mainline kernel, but if the 'ldo8' regulator is > modified to be always-on in the omap5-sbc-t54.dts file, it will. Thanks for the heads up! Yes, indeed ldo8 powers the serial port transceiver, led and touch screen controller. We intend to send fixes in a short while. -- 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: [PATCH] arm: omap: cm-t3530: Add MMC2/SDIO/WLAN support
On 03/12/14 19:44, Tony Lindgren wrote:
> * Stefan Roese [140312 03:52]:
>> Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
>> on the CM-T3530 SOM.
>>
>> Signed-off-by: Stefan Roese
>> Cc: Dmitry Lifshitz
>> Cc: Igor Grinberg
>> Cc: Tony Lindgren
Acked-by: Igor Grinberg
>> ---
>> This patch is based on current mainline (v3.14-rc6) plus this compulab patch
>> series from Dmitry:
>>
>> [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
>> http://www.spinics.net/lists/arm-kernel/msg300078.html
>
> Thanks applying into omap-for-v3.15/dt, no guarantees it gets merged though
> as it's getting so close to the merge window.
>
> Regards,
>
> Tony
>
>> arch/arm/boot/dts/omap3-cm-t3530.dts | 36
>>
>> 1 file changed, 36 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
>> b/arch/arm/boot/dts/omap3-cm-t3530.dts
>> index 9faf1cd..d145849 100644
>> --- a/arch/arm/boot/dts/omap3-cm-t3530.dts
>> +++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
>> @@ -9,4 +9,40 @@
>> / {
>> model = "CompuLab CM-T3530";
>> compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
>> +
>> +/* Regulator to trigger the reset signal of the Wifi module */
>> +mmc2_sdio_reset: regulator-mmc2-sdio-reset {
>> +compatible = "regulator-fixed";
>> +regulator-name = "regulator-mmc2-sdio-reset";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +gpio = <&twl_gpio 2 GPIO_ACTIVE_HIGH>;
>> +enable-active-high;
>> +};
>> +};
>> +
>> +&omap3_pmx_core {
>> +mmc2_pins: pinmux_mmc2_pins {
>> +pinctrl-single,pins = <
>> +OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_clk.sdmmc2_clk */
>> +OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_cmd.sdmmc2_cmd */
>> +OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_dat0.sdmmc2_dat0 */
>> +OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_dat1.sdmmc2_dat1 */
>> +OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_dat2.sdmmc2_dat2 */
>> +OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
>> /* sdmmc2_dat3.sdmmc2_dat3 */
>> +OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
>> /* sdmmc2_dat4.sdmmc2_dir_dat0 */
>> +OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
>> /* sdmmc2_dat5.sdmmc2_dir_dat1 */
>> +OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
>> /* sdmmc2_dat6.sdmmc2_dir_cmd */
>> +OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
>> /* sdmmc2_dat7.sdmmc2_clkin */
>> +>;
>> +};
>> +};
>> +
>> +&mmc2 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&mmc2_pins>;
>> +vmmc-supply = <&mmc2_sdio_reset>;
>> +non-removable;
>> +bus-width = <4>;
>> +cap-power-off-card;
>> };
>> --
>> 1.8.5.5
>>
>
--
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: Help needed USB hub disconnected at resume
On 03/03/14 16:11, Marc Murphy wrote: > Hi Igor > > The Hub is a Microchip USB2513B-AEZG and is connected to EHCI controller port > via the DUP_P and DUP_N pins. There is a reset applied to the chip at power > on. > If the reset signal is sw controllable, you might want to toggle it before the EHCI controller resumes. There is also a USB phy on the way from EHCI controller to the hub. You might also want to check if the phy resumes correctly. Which phy do you use and how is it reset? > Regards > Marc > ____ > From: Igor Grinberg [grinb...@compulab.co.il] > Sent: 03 March 2014 12:16 > To: Roger Quadros; Marc Murphy; linux-omap@vger.kernel.org > Subject: Re: Help needed USB hub disconnected at resume > > On 03/03/14 13:06, Roger Quadros wrote: >> Hi Marc, >> >> On 03/03/2014 12:04 PM, Marc Murphy wrote: >>> Hi, >>> I am using the latest stable 3.4.80 kernel with some changes to get the >>> EMAC Phy to initialise correctly after a suspend/resume. The platform is >>> AM3517 with most of the system working nice and smoothly. I have 1 issue >>> though and need some advice/help to get the system to use the USB hub I >>> have connected to the EHCI controller after a suspend to memory and resume. >>> >>> At boot all is recognised; >>> >>> [1.486816] usbcore: registered new interface driver cdc_ether >>> [1.493255] usbcore: registered new interface driver cdc_ncm >>> [1.499450] usbcore: registered new interface driver qmi_wwan >>> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >>> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator >>> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller >>> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus >>> number 1 >>> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 >>> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 >>> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >>> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, >>> SerialNumber=1 >>> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller >>> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd >>> [2.585296] usb usb1: SerialNumber: ehci-omap.0 >>> [2.591278] hub 1-0:1.0: USB hub found >>> [2.595306] hub 1-0:1.0: 3 ports detected >>> >>> And I can see everything OK. >>> >>> # lsusb >>> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub >>> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. >>> # >>> # >>> # echo mem > /sys/power/state >>> [ 73.736572] PM: Syncing filesystems ... done. >>> [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) >>> done. >>> [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 >>> seconds) done. >>> [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle >>> [ 73.968872] PM: suspend of devices complete after 170.410 msecs >>> [ 73.975433] PM: late suspend of devices complete after 0.305 msecs >>> [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs >>> [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 >>> [ 83.436737] Could not enter target state in pm_suspend >>> [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs >>> [ 83.450164] PM: early resume of devices complete after 0.274 msecs >>> [ 83.457336] <6>Waiting for PHY clock good... >>> [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller >>> [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] >>> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >>> [ 84.771881] PM: resume of devices complete after 1315.185 msecs >>> [ 84.778472] Restarting tasks ... >>> [ 84.782379] usb 1-1: USB disconnect, device number 2 >>> [ 84.790557] done. >>> [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz >>> sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 >>> Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister &
Re: Help needed USB hub disconnected at resume
On 03/03/14 13:06, Roger Quadros wrote: > Hi Marc, > > On 03/03/2014 12:04 PM, Marc Murphy wrote: >> Hi, >> I am using the latest stable 3.4.80 kernel with some changes to get the EMAC >> Phy to initialise correctly after a suspend/resume. The platform is AM3517 >> with most of the system working nice and smoothly. I have 1 issue though and >> need some advice/help to get the system to use the USB hub I have connected >> to the EHCI controller after a suspend to memory and resume. >> >> At boot all is recognised; >> >> [1.486816] usbcore: registered new interface driver cdc_ether >> [1.493255] usbcore: registered new interface driver cdc_ncm >> [1.499450] usbcore: registered new interface driver qmi_wwan >> [1.506622] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver >> [1.513580] ehci-omap.0 supply hsusb0 not found, using dummy regulator >> [2.521881] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller >> [2.528411] ehci-omap ehci-omap.0: new USB bus registered, assigned bus >> number 1 >> [2.536468] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 >> [2.553070] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 >> [2.559295] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >> [2.566436] usb usb1: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [2.574035] usb usb1: Product: OMAP-EHCI Host Controller >> [2.579620] usb usb1: Manufacturer: Linux 3.4.80 ehci_hcd >> [2.585296] usb usb1: SerialNumber: ehci-omap.0 >> [2.591278] hub 1-0:1.0: USB hub found >> [2.595306] hub 1-0:1.0: 3 ports detected >> >> And I can see everything OK. >> >> # lsusb >> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 003: ID 1199:68a2 Sierra Wireless, Inc. >> # >> # >> # echo mem > /sys/power/state >> [ 73.736572] PM: Syncing filesystems ... done. >> [ 73.743530] Freezing user space processes ... (elapsed 0.01 seconds) done. >> [ 73.766784] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) >> done. >> [ 73.959289] davinci_mdio davinci_mdio.0: timed out waiting for idle >> [ 73.968872] PM: suspend of devices complete after 170.410 msecs >> [ 73.975433] PM: late suspend of devices complete after 0.305 msecs >> [ 73.982635] PM: noirq suspend of devices complete after 0.732 msecs >> [ 83.430450] Powerdomain (core_pwrdm) didn't enter target state 1 >> [ 83.436737] Could not enter target state in pm_suspend >> [ 83.443176] PM: noirq resume of devices complete after 0.915 msecs >> [ 83.450164] PM: early resume of devices complete after 0.274 msecs >> [ 83.457336] <6>Waiting for PHY clock good... >> [ 83.463287] davinci_mdio davinci_mdio.0: resetting idled controller >> [ 83.471343] net eth0: attached PHY driver [SMSC LAN8710/LAN8720] >> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >> [ 84.771881] PM: resume of devices complete after 1315.185 msecs >> [ 84.778472] Restarting tasks ... >> [ 84.782379] usb 1-1: USB disconnect, device number 2 >> [ 84.790557] done. >> [ 84.792938] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz >> sh: write error:[ 84.800781] usb 1-1.1: USB disconnect, device number 3 >> Operation not p[ 84.808349] qmi_wwan 1-1.1:1.8: wwan0: unregister >> 'qmi_wwan' usb-ehci-omap.0-1.1, Sierra Wireless wwan/QMI device >> ermitted >> [ 84.859191] mmc1: mmc_rescan_try_freq: trying to init card at 40 Hz >> [ 86.490356] PHY: davinci_mdio-0:00 - Link is Up - 100/Full >> # >> # >> # lsusb >> Bus 002 Device 002: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> # >> >> Is there any relevant patch out there that would address the issue that I >> see ? > > Does this happen because of OFF mode? > Can you please try the tests with off mode disabled? > > e.g. > mount -t debugfs none /sys/kernel/debug > echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > suspend & resume AFAIK, AM3517 does not have OFF mode. We had something similar with runtime pm... It might be useful to know which hub is this and how is it connected... > > Also please send the output of /sys/kernel/debug/pm_debug/count > before suspend and after resume. Thanks. -- 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: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
On 03/01/14 00:12, Tony Lindgren wrote: > * Igor Grinberg [140223 04:33]: >> ping x2! > > Thanks applying into omap-for-v3.15/dt finally. Thanks! > > Is it OK to remove the board-cm-*.c files for v3.15? Hmmm I thought we will have a transition release with both ways and similar functionality available... For this to happen, we need to extend the DT support to the stuff board-cm-t*.c files cover before removing them... We should be able to send additional patches in 3-5 weeks. Since rc4 is out a week ago, and rc5 is coming, we won't be able to prepare the extension in time for 3.15... So, can we postpone the board-cm-t*.c files removal to 3.16? Or does it make too much trouble for you? -- 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: [PATCH] arm: dts: Add support for Compulab sbc-t3530 with cm-t35
Hi Stefan,
Have you seen the series sent by Dmitry on 12-Jan-2014?
It is called "ARM: dts: sbc-t3x: add support for more boards",
or you can check it out here:
http://www.spinics.net/lists/arm-kernel/msg300078.html
On 02/21/14 14:36, Stefan Roese wrote:
> The cm-t3530 SOM is equipped with the OMAP3530 and does not boot with
> the cm-t3730 dts file as it used the omap36xx.dtsi. Add a separate
> dts/dtsi for this board to support it correctly.
>
> I moved some common parts into omap3-cm-t3x30.dtsi. And removed
> the SDIO/WLAN support for now. As I don't know exactly how this
> should be done. Perhaps somebody else might jump in here...
>
> Signed-off-by: Stefan Roese
> Cc: Igor Grinberg
> Cc: Dmitry Lifshitz
> Cc: Tony Lindgren
> ---
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/omap3-cm-t3530.dts | 29 +++
> arch/arm/boot/dts/omap3-cm-t3730.dts | 54
> ---
> arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 44
> arch/arm/boot/dts/omap3-sbc-t3530.dts | 30 +++
> 5 files changed, 110 insertions(+), 48 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 6d1e43d..6fd1b34 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -200,6 +200,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3430-sdp.dtb \
> omap3-beagle.dtb \
> omap3-cm-t3730.dtb \
> + omap3-sbc-t3530.dtb \
> omap3-sbc-t3730.dtb \
> omap3-devkit8000.dtb \
> omap3-beagle-xm.dtb \
> diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
> b/arch/arm/boot/dts/omap3-cm-t3530.dts
> new file mode 100644
> index 000..35a1fc2
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
> @@ -0,0 +1,29 @@
> +/*
> + * Support for CompuLab CM-T3530
> + */
> +/dts-v1/;
> +
> +#include "omap34xx-hs.dtsi"
> +#include "omap3-cm-t3x30.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T3530";
> + compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + bus-width = <4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> +};
> +
> +&smsc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&smsc1_pins>;
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins>;
> +};
> diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
> b/arch/arm/boot/dts/omap3-cm-t3730.dts
> index 486f4d6..3e05b11 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3730.dts
> +++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
> @@ -32,39 +32,14 @@
> };
>
> &omap3_pmx_core {
> - mmc1_pins: pinmux_mmc1_pins {
> - pinctrl-single,pins = <
> - 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
> sdmmc1_clk.sdmmc1_clk */
> - 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc1_cmd.sdmmc1_cmd */
> - 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc1_dat0.sdmmc1_dat0 */
> - 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc1_dat1.sdmmc1_dat1 */
> - 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc1_dat2.sdmmc1_dat2 */
> - 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc1_dat3.sdmmc1_dat3 */
> - >;
> - };
> -
> mmc2_pins: pinmux_mmc2_pins {
> pinctrl-single,pins = <
> - 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_clk.sdmmc2_clk */
> - 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_cmd.sdmmc2_cmd */
> - 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_dat0.sdmmc2_dat0 */
> - 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_dat1.sdmmc2_dat1 */
> - 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_dat2.sdmmc2_dat2 */
> - 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> sdmmc2_dat3.sdmmc2_dat3 */
> - >;
> - };
> -
> - smsc1_pins: pinmux_smsc1_pins {
> - pinctrl-single,pins = <
> - 0x88 (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_ncs5.gpmc_ncs5 */
> - 0x16a (PIN_INPUT_PULLUP | MUX_MODE4)/*
> uart3_cts_rctx.gpio_
Re: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
ping x2! On 02/12/14 14:38, Igor Grinberg wrote: > ping! > > On 01/12/14 15:22, Dmitry Lifshitz wrote: >> Add support for CompuLab SBC-T3530 and SBC-T3517 boards: >> >> https://compulab.co.il/products/sbcs/sbc-t3530/ >> https://compulab.co.il/products/sbcs/sbc-t3517/ >> >> along with respective CoMs - CM-T3530 and CM-T3517: >> >> https://compulab.co.il/products/computer-on-modules/cm-t3530/ >> https://compulab.co.il/products/computer-on-modules/cm-t3517/ >> >> The device tree files have the following structure: >> >> omap3-cm-t3x.dtsi >> | >> |<-- omap3-cm-t3x30.dtsi >> | | >> | | >> | | - --- >> | || CoM || Board || Base board | >> | | - --- >> | |omap3-sb-t35.dtsi >> | | | >> | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->| >> | | | >> | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->| >> || >> |< omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->| >> >> >> where omap3-cm-t3730.dts, omap3-cm-t3530.dts, omap3-cm-t3517.dts >> contain CoMs specific data, while omap3-sbc-t3730.dts, omap3-sbc-t3530.dts, >> omap3-sbc-t3517.dts represent eval boards with respective core modules. >> >> This series is based on Tony's omap-for-v3.14/dt branch >> >> Dmitry Lifshitz (11): >> ARM: dts: sbc-t3x: refactor DT support >> ARM: dts: sbc-t3x: disable mmc3 >> ARM: dts: sb-t35: fix Ethernet power supply >> ARM: dts: cm-t3x: add gpio-led pinmux >> ARM: dts: cm-t3x30: add twl4030 gpio pullups >> ARM: dts: cm-t3x30: add HS USB Host support >> ARM: dts: sbc-t3730: add pinmux for usb hub reset >> ARM: dts: cm-t3x30: add USB OTG support >> ARM: dts: sbc-t3530: add support for sbc-t3530 >> ARM: dts: sbc-t3517: add support for sbc-t3517 >> ARM: OMAP2+: make reset pulse for sbc-t3x usb hubs >> >> arch/arm/boot/dts/Makefile|4 + >> arch/arm/boot/dts/omap3-cm-t3517.dts | 137 >> + >> arch/arm/boot/dts/omap3-cm-t3530.dts | 13 +++ >> arch/arm/boot/dts/omap3-cm-t3730.dts | 40 -- >> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 112 +++ >> arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 74 +- >> arch/arm/boot/dts/omap3-sb-t35.dtsi | 30 +++- >> arch/arm/boot/dts/omap3-sbc-t3517.dts | 44 +++ >> arch/arm/boot/dts/omap3-sbc-t3530.dts | 37 + >> arch/arm/boot/dts/omap3-sbc-t3730.dts | 24 +++--- >> arch/arm/mach-omap2/pdata-quirks.c| 67 - >> 11 files changed, 506 insertions(+), 76 deletions(-) >> create mode 100644 arch/arm/boot/dts/omap3-cm-t3517.dts >> create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts >> create mode 100644 arch/arm/boot/dts/omap3-cm-t3x.dtsi >> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts >> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts >> > -- 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: [PATCH 1/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor
Hi Laurent,
On 02/18/14 14:47, Laurent Pinchart wrote:
> Mauro, Tony,
>
> On Monday 10 February 2014 22:54:40 Laurent Pinchart wrote:
>> The camera sensor will soon require regulators and clocks. Register
>> fixed regulators for its VAA and VDD power supplies and a fixed rate
>> clock for its master clock.
>
> This patch is a prerequisite for a set of 4 patches that need to go through
> the linux-media tree. It would simpler if it could go through the same tree
> as
> well. Given that arch/arm/mach-omap2/board-cm-t35.c has seen very little
> activity recently I believe the risk of conflict is pretty low.
Indeed, as we work on DT stuff of cm-t35/3730 and pretty much stopped
updating the board-cm-t35.c file.
> Tony, would
> that be fine with you ?
>
>> Signed-off-by: Laurent Pinchart
Acked-by: Igor Grinberg
>> ---
>> arch/arm/mach-omap2/board-cm-t35.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
>> b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..018353d 100644
>> --- a/arch/arm/mach-omap2/board-cm-t35.c
>> +++ b/arch/arm/mach-omap2/board-cm-t35.c
>> @@ -16,6 +16,8 @@
>> *
>> */
>>
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -542,8 +544,22 @@ static struct isp_platform_data cm_t35_isp_pdata = {
>> .subdevs = cm_t35_isp_subdevs,
>> };
>>
>> +static struct regulator_consumer_supply cm_t35_camera_supplies[] = {
>> +REGULATOR_SUPPLY("vaa", "3-005d"),
>> +REGULATOR_SUPPLY("vdd", "3-005d"),
>> +};
>> +
>> static void __init cm_t35_init_camera(void)
>> {
>> +struct clk *clk;
>> +
>> +clk = clk_register_fixed_rate(NULL, "mt9t001-clkin", NULL, CLK_IS_ROOT,
>> + 4800);
>> +clk_register_clkdev(clk, NULL, "3-005d");
>> +
>> +regulator_register_fixed(2, cm_t35_camera_supplies,
>> + ARRAY_SIZE(cm_t35_camera_supplies));
>> +
>> if (omap3_init_camera(&cm_t35_isp_pdata) < 0)
>> pr_warn("CM-T3x: Failed registering camera device!\n");
>> }
>
--
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: [PATCH] arm: omap3: cm-t35: remove MACH_CM_T3730
Hi Paul, On 02/16/14 19:26, Paul Bolle wrote: > The Kconfig symbol MACH_CM_T3730 was added in v3.1. It has never been > used. Setting it has no effect. There are no calls for > machine_is_cm_t3730(). This symbol can safely be removed. Indeed... Is it such a burden to keep it just until we switch OMAP3 to DT? Because, it makes a bit harder to hack on the kernel. Well, not too much as it can be reverted, but still one needs to remember to do this... I'd like to keep it just until we remove the board files, please. > > Signed-off-by: Paul Bolle > --- > Tested only with "git grep". > > arch/arm/mach-omap2/Kconfig | 4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 66da3f5..7d4934e 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -292,7 +292,6 @@ config MACH_CM_T35 > bool "CompuLab CM-T35/CM-T3730 modules" > depends on ARCH_OMAP3 > default y > - select MACH_CM_T3730 > select OMAP_PACKAGE_CUS > > config MACH_CM_T3517 > @@ -301,9 +300,6 @@ config MACH_CM_T3517 > default y > select OMAP_PACKAGE_CBB > > -config MACH_CM_T3730 > - bool > - > config MACH_SBC3530 > bool "OMAP3 SBC STALKER board" > depends on ARCH_OMAP3 > -- 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: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
ping! On 01/12/14 15:22, Dmitry Lifshitz wrote: > Add support for CompuLab SBC-T3530 and SBC-T3517 boards: > > https://compulab.co.il/products/sbcs/sbc-t3530/ > https://compulab.co.il/products/sbcs/sbc-t3517/ > > along with respective CoMs - CM-T3530 and CM-T3517: > > https://compulab.co.il/products/computer-on-modules/cm-t3530/ > https://compulab.co.il/products/computer-on-modules/cm-t3517/ > > The device tree files have the following structure: > > omap3-cm-t3x.dtsi > | > |<-- omap3-cm-t3x30.dtsi > | | > | | > | | - --- > | || CoM || Board || Base board | > | | - --- > | |omap3-sb-t35.dtsi > | | | > | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->| > | | | > | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->| > || > |< omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->| > > > where omap3-cm-t3730.dts, omap3-cm-t3530.dts, omap3-cm-t3517.dts > contain CoMs specific data, while omap3-sbc-t3730.dts, omap3-sbc-t3530.dts, > omap3-sbc-t3517.dts represent eval boards with respective core modules. > > This series is based on Tony's omap-for-v3.14/dt branch > > Dmitry Lifshitz (11): > ARM: dts: sbc-t3x: refactor DT support > ARM: dts: sbc-t3x: disable mmc3 > ARM: dts: sb-t35: fix Ethernet power supply > ARM: dts: cm-t3x: add gpio-led pinmux > ARM: dts: cm-t3x30: add twl4030 gpio pullups > ARM: dts: cm-t3x30: add HS USB Host support > ARM: dts: sbc-t3730: add pinmux for usb hub reset > ARM: dts: cm-t3x30: add USB OTG support > ARM: dts: sbc-t3530: add support for sbc-t3530 > ARM: dts: sbc-t3517: add support for sbc-t3517 > ARM: OMAP2+: make reset pulse for sbc-t3x usb hubs > > arch/arm/boot/dts/Makefile|4 + > arch/arm/boot/dts/omap3-cm-t3517.dts | 137 > + > arch/arm/boot/dts/omap3-cm-t3530.dts | 13 +++ > arch/arm/boot/dts/omap3-cm-t3730.dts | 40 -- > arch/arm/boot/dts/omap3-cm-t3x.dtsi | 112 +++ > arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 74 +- > arch/arm/boot/dts/omap3-sb-t35.dtsi | 30 +++- > arch/arm/boot/dts/omap3-sbc-t3517.dts | 44 +++ > arch/arm/boot/dts/omap3-sbc-t3530.dts | 37 + > arch/arm/boot/dts/omap3-sbc-t3730.dts | 24 +++--- > arch/arm/mach-omap2/pdata-quirks.c| 67 - > 11 files changed, 506 insertions(+), 76 deletions(-) > create mode 100644 arch/arm/boot/dts/omap3-cm-t3517.dts > create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts > create mode 100644 arch/arm/boot/dts/omap3-cm-t3x.dtsi > create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts > create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts > -- 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: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
On 12/18/13 23:16, Tony Lindgren wrote: [...] > > I've kept your Ack as the changes were minor. If no other > comments, I will apply this into omap-for-v3.14/dt probably > on Thursday. Looks great! Thanks! -- 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: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
On 12/17/13 21:31, Tony Lindgren wrote:
> * Igor Grinberg [131216 23:16]:
>> On 12/16/13 21:17, Tony Lindgren wrote:
>>> * Igor Grinberg [131216 05:57]:
>>>> On 12/13/13 21:22, Tony Lindgren wrote:
[...]
>
>> I think we can drop the different memory sizes and
>> let boot loader adjust the blob. This will make the list shorter:
>> omap3-cm-t3x.dtsi- common to cm-t3x cpu boards
>> omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
>> omap3-cm-t3730.dtsi - cm-t3730 specific
>> omap3-cm-t3530.dtsi - cm-t3530 specific
>> omap3-cm-t3517.dtsi - cm-t3517 specific
>> omap3-sb-t35.dtsi- sb-t35 specific
>> omap3-cb-t3.dtsi - cb-t3 specific
>> omap3-sbc-t3730.dts - sb-t35 with cm-t3730 and default memory size
>> omap3-sbc-t3530.dts - sb-t35 with cm-t3530 and default memory size
>> omap3-sbc-t3517.dts - sb-t35 with cm-t3517 and default memory size
>> omap3-em-t3730.dts - cb-t3 with cm-t3730 and default memory size
>> omap3-em-t3530.dts - cb-t3 with cm-t3530 and default memory size
>>
>> So what do you think?
>
> Makes sense to me. I've updated the patch below to use the following:
>
> omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
> omap3-cm-t3730.dts- cm-t3730 specific, should work on it's own too, not a
> .dtsi
> omap3-sb-t35.dtsi - sb-t35 specific
> omap3-sbc-t3730.dts - sb-t35 with cm-t3730 and default memory size
>
> So the only changes compared to your naming are to not use .dtsi
> extension for omap3-cm-t3730.dts, and I did not add omap3-cm-t3x.dtsi
> as I don't know the details.
Ok.
>
> It's probably best that you guys take over this patch from here and
> add omap3-cm-t3x30.dtsi if needed.
Ok.
>
> I got the basic stuff working for what I need right now for my router
> to work, which is MMC, both Ethernet controllers and wl12xx. So I'm
> not going to tweak this patch further. Of course having the battery
> charging working would be nice for a router to have a backup battery :)
>
> There are still some issues I've noticed:
>
> 1. Removing and reinserting the wl12xx modules seems to kill the
>WLAN
>
> 2. Ethernet interfaces only come up if there's a cable connected
I see. Ok then, we'll try to figure those things out.
[...]
>>>>> + mmc2_pins: pinmux_mmc2_pins {
>>>>> + pinctrl-single,pins = <
>>>>> + 0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_clk.sdmmc2_clk */
>>>>> + 0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_cmd.sdmmc2_cmd */
>>>>> + 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_dat0.sdmmc2_dat0 */
>>>>> + 0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_dat1.sdmmc2_dat1 */
>>>>> + 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_dat2.sdmmc2_dat2 */
>>>>> + 0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>>>>> sdmmc2_dat3.sdmmc2_dat3 */
>>>>
>>>> Here the following is missing:
>>>> 0x134 (PIN_OUTPUT | MUX_MODE1) /* sdmmc2_dat4.sdmmc2_dir_dat0 */
>>>
>>> That seems to be used for the wl12xx GPIO, so it's listed at
>>> wl12xx_gpio below.
>>
>> Yes, but only on cm-t3730 (and actually starting from revision 1.2),
>> not cm-t3530...
>
> Sounds like that needs another set of .dts files, or patching in the
> bootloader.
Yep, IMO, .dts will be better, as I think pinmux is something
the kernel should be aware of...
[...]
> 8< --
> From: Tony Lindgren
> Date: Tue, 10 Dec 2013 15:03:34 -0800
> Subject: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
>
> This adds support for CompuLab SBC-T3530, also known as cm-t3730:
>
> http://compulab.co.il/products/sbcs/sbc-t3530/
>
> It seems that with the sbc-3xxx mainboard is also used on
> SBC-T3517 and SBC-T3730 with just a different CPU module:
>
> http://compulab.co.il/products/sbcs/sbc-t3517/
> http://compulab.co.il/products/sbcs/sbc-t3730/
>
> So let's add a common omap3-sb-t35.dtsi and then separate SoC
> specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
> omap3-sbc-t3517.dts.
>
> I've tested this with SBC-T3730 as that's the only one I have.
> At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
> work.
>
> Note that WLAN seems to be different for SBC-T3530. And SBC-T3517
> may need some changes for the EMAC Ethernet if that's used
Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
On 12/16/13 21:17, Tony Lindgren wrote:
> * Igor Grinberg [131216 05:57]:
>> On 12/13/13 21:22, Tony Lindgren wrote:
>>
>> SB-T35 has only one SMSC Ethernet on-board (smsc2),
>> while the first one is on the cm-t3530 and cm-t3730 modules.
>> SBC-T3517 has only one _SMSC_ Ethernet and it is on the SB-T35 base board.
>> cm-t3517 has EMAC Ethernet on-board instead of the SMSC.
>
> OK, I'll move that.
>
>> There is also another base board - CB-T3, which turns into
>> EM-T3530 and EM-T3730 once you plug the cm-t3530 or cm-t3730 into CB-T3.
>>
>> http://compulab.co.il/products/handheld-computers/em-t3730/
>> http://compulab.co.il/products/handheld-computers/em-t3530/
>>
>> The CB-T3 base board does not have any Ethernet controllers on it,
>> so the EM-T3x systems have only one Ethernet controller - the one on the
>> CPU board - SMSC.
>
> OK
>
>> This makes it four boards:
>> sb-t35 - base board has only one Ethernet controller (SMSC)
>> cb-t3 - base board has no Ethernet controllers
>> cm-t3530 - CPU board (plugged into sb-t35) has only one Ethernet controller
>> (SMSC)
>> cm-t3730 - CPU board (plugged into sb-t35) has only one Ethernet controller
>> (SMSC)
>> cm-t3537 - CPU board (plugged into sb-t35) has only one Ethernet controller
>> (EMAC)
>>
>> The SBC-Txxx and EM-Txxx- means both boards connected (base board with CPU
>> board).
>
> OK
>
>>> +
>>> + cpus {
>>> + cpu@0 {
>>> + cpu0-supply = <&vcc>;
>>> + };
>>> + };
>>> +
>>> + leds {
>>> + compatible = "gpio-leds";
>>> + ledb {
>>> + label = "cm-t35:green";
>>> + gpios = <&gpio6 26 GPIO_ACTIVE_HIGH>; /* gpio186 */
>>> + linux,default-trigger = "heartbeat";
>>
>> Although all CPU boards have the same GPIO routed to the heartbeat LED,
>> this property is related to the CPU board and not to the base (mother) board.
>> The same GPIO is used intensionally for s/w simplicity.
>> If we are about to save code duplication, I'd like to have a common
>> to CPU boards file, say omap3-cm-t3x.dtsi - that way it will better reflect
>> the actual hardware.
>
> OK will move.
>
>>> +&i2c1 {
>>> + clock-frequency = <260>;
>>> +
>>> + twl: twl@48 {
>>> + reg = <0x48>;
>>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>>> + interrupt-parent = <&intc>;
>>> + };
>>> +};
>>
>> This one should be a part of the common file.
>
> OK
>
>>> +#include "twl4030.dtsi"
>>> +#include "twl4030_omap3.dtsi"
>>> +
>>> +&i2c3 {
>>> + clock-frequency = <40>;
>>> +};
>>> +
>>> +&mmc1 {
>>> + vmmc-supply = <&vmmc1>;
>>> + vmmc_aux-supply = <&vsim>;
>>
>> Is it essential to always provide vmmc_aux-supply property?
>> In fact, the TPS65930 does not have the VSIM supply...
>> It is a mistake in the upstream board file.
>
> OK
>
>> I fixed this locally a while ago, but haven't submitted upstream...
>> So we should either leave this property unpopulated (if we can...) or
>> provide a fixed regulator to populate it.
>>
>>> + bus-width = <8>;
>>
>> I'm not sure what this property should reflect.
>> Both cm-t3530 and cm-t3730 use 4 bit MMC1 bus.
>
> Hmm except with the muxing it seems to work just fine with 8-bit :)
Yes, this is because they are just not connected on sb-t35.
> I noticed that by accident as I copied the entry from omap3-evm.
>
> So it seems that all the 8 lines are available for the MMC1, but can
> be optionally also routed somewhere else?
The concept of having CPU board and base (mother) board implies
that our customers build a base board of their own.
This way, the customer decides what to do with those lines.
cm-t3x just makes them available on the connector, while
neither sb-t35, nor cb-t3 uses them.
>
>>> +++ b/arch/arm/boot/dts/omap3-sbc-t3517.dts
>>> @@ -0,0 +1,18 @@
>>> +/*
>>> + * Suppport for CompuLab SBC-T3517 with CM-T3517
>>> + */
>>> +/dts-v1/;
>>> +
>>> +#include "am3517.dtsi"
>>> +#include "omap3-sb-t35.dtsi"
>>> +
>>> +
>>> +/ {
>>>
Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
Hi Tony,
On 12/13/13 21:22, Tony Lindgren wrote:
> This adds support for CompuLab SBC-T3530, also known as cm-t3730:
>
> http://compulab.co.il/products/sbcs/sbc-t3530/
>
> It seems that with the sbc-3xxx mainboard is also used on
> SBC-T3517 and SBC-T3730 with just a different CPU module:
>
> http://compulab.co.il/products/sbcs/sbc-t3517/
> http://compulab.co.il/products/sbcs/sbc-t3730/
>
> So let's add a common omap3-sb-t35.dtsi and then separate SoC
> specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
> omap3-sbc-t3517.dts.
>
> I've tested this with SBC-T3730 as that's the only one I have.
> At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
> work.
>
> Note that WLAN seems to be different for SBC-T3530.
Yes, it is Marvell 8686 chipset using the libertas driver.
> And SBC-T3517
> may need some changes for the EMAC Ethernet if that's used
> instead of the smsc911x.
>
> Cc: devicet...@vger.kernel.org
> Cc: Igor Grinberg
> Cc: Mike Rapoport
> Signed-off-by: Tony Lindgren
Great job!
I'm sorry I couldn't make it in time with the conversion... :-(
> ---
> arch/arm/boot/dts/Makefile| 3 +
> arch/arm/boot/dts/omap3-sb-t35.dtsi | 135
> ++
> arch/arm/boot/dts/omap3-sbc-t3517.dts | 18 +
> arch/arm/boot/dts/omap3-sbc-t3530.dts | 18 +
> arch/arm/boot/dts/omap3-sbc-t3730.dts | 130
> arch/arm/mach-omap2/pdata-quirks.c| 7 ++
> 6 files changed, 311 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3-sb-t35.dtsi
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3730.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index fc37bca..41370d2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -179,6 +179,9 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap2420-n810-wimax.dtb \
> omap3430-sdp.dtb \
> omap3-beagle.dtb \
> + omap3-sbc-t3530.dtb \
> + omap3-sbc-t3730.dtb \
> + omap3-sbc-t3517.dtb \
> omap3-devkit8000.dtb \
> omap3-beagle-xm.dtb \
> omap3-evm.dtb \
> diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi
> b/arch/arm/boot/dts/omap3-sb-t35.dtsi
> new file mode 100644
> index 000..fc676c5
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
> @@ -0,0 +1,135 @@
> +/*
> + * Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
> SBC-T3730
> + */
> +
> +/ {
> + aliases {
> + ethernet0 = &smsc1;
> + ethernet1 = &smsc2;
> + };
SB-T35 has only one SMSC Ethernet on-board (smsc2),
while the first one is on the cm-t3530 and cm-t3730 modules.
SBC-T3517 has only one _SMSC_ Ethernet and it is on the SB-T35 base board.
cm-t3517 has EMAC Ethernet on-board instead of the SMSC.
There is also another base board - CB-T3, which turns into
EM-T3530 and EM-T3730 once you plug the cm-t3530 or cm-t3730 into CB-T3.
http://compulab.co.il/products/handheld-computers/em-t3730/
http://compulab.co.il/products/handheld-computers/em-t3530/
The CB-T3 base board does not have any Ethernet controllers on it,
so the EM-T3x systems have only one Ethernet controller - the one on the
CPU board - SMSC.
This makes it four boards:
sb-t35 - base board has only one Ethernet controller (SMSC)
cb-t3 - base board has no Ethernet controllers
cm-t3530 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3730 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3537 - CPU board (plugged into sb-t35) has only one Ethernet controller
(EMAC)
The SBC-Txxx and EM-Txxx- means both boards connected (base board with CPU
board).
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <&vcc>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + ledb {
> + label = "cm-t35:green";
> + gpios = <&gpio6 26 GPIO_ACTIVE_HIGH>; /* gpio186 */
> + linux,default-trigger = "heartbeat";
Although all CPU boards have the same GPIO routed to the heartbeat LED,
this property is related to the CPU board and not to the base (mother) board.
The same GPIO is used intensionally for s/w simplicity.
If we are about to save code duplication, I'd like to have a common
to CPU boards file, say omap3-cm-t3x.dtsi - that way it will better reflect
the actual hardware.
> + };
> + };
> +
> + vddvario
Re: [PATCH] ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init()
On 10/25/13 11:31, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function platform_device_register_resndata()
> returns ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
Acked-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/gpmc-smsc911x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
> b/arch/arm/mach-omap2/gpmc-smsc911x.c
> index ef99011..2757504 100644
> --- a/arch/arm/mach-omap2/gpmc-smsc911x.c
> +++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
> @@ -83,7 +83,7 @@ void __init gpmc_smsc911x_init(struct
> omap_smsc911x_platform_data *gpmc_cfg)
> pdev = platform_device_register_resndata(NULL, "smsc911x", gpmc_cfg->id,
>gpmc_smsc911x_resources, ARRAY_SIZE(gpmc_smsc911x_resources),
>&gpmc_smsc911x_config, sizeof(gpmc_smsc911x_config));
> - if (!pdev) {
> + if (IS_ERR(pdev)) {
> pr_err("Unable to register platform device\n");
> gpio_free(gpmc_cfg->gpio_reset);
> goto free2;
>
> --
> 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
>
--
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: Request for OMAPDSS testing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/13 10:08, Tomi Valkeinen wrote:
> On 16/06/13 15:28, Igor Grinberg wrote:
>
>>>> Although one thing is missing from the tfp410 driver is
>>>> the PD GPIO polarity. I had to adjust it locally to get the DVI working.
>>>> The original polarity was high = disabled, low = enabled.
>>
>>> Hmm, but this is missing from the old driver also, isn't it? At least
>>> with a quick glance the old and new tfp410 drivers do the same thing
>>> with the PD gpio.
>>
>> Well, we were driving the PD GPIO from the board file...
>
> Ah, I see. That was inverted PD handling was removed in 3.5, by accident
> as far as I see. So DVI on cm-t35 has been broken since?
Well, we have applied the below patches since then (the patches are against
3.7),
but haven't had time to send it upstream...
>
> I wonder how that should be fixed... The tfp410 driver handles it
> correctly, as the PD gpio is active low (i.e. high == tfp410 enabled),
> so having it inverted is a board specific thing. Do you know what is the
> reason to have it inverted?
Yes, the reason for this is the sb-t35 (the baseboard) which has the TFP410
in 3.3V domain, but the cm-t3530/3730 are in 1.8V domain.
This means that the line must be shifted.
Now for some reason hardware guys used an inverter as the level shifter
instead of a simple buffer. So now it is shifted and inverted...
>
> There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be
> used, as I don't see anyone setting that flag... And supporting that
> would mean, in principle, that every driver should support inverting the
> gpio with every gpio they have.
Might be worth to consider adding this functionality to the GPIOLIB?
Meanwhile, I think the simplest way would be to add a boolean
like OF_GPIO_ACTIVE_LOW, as we have hardware that needs it.
If you think the patches are conceptually fine,
I can rebase them on top of your tree with the new drivers and
submit properly.
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAEBAgAGBQJRvstaAAoJEBDE8YO64EfatIMQAJbAO7rkQNTlTwL4qkANZV7h
v1msnUbjuiGr5hb34UX07b3lBoIXkI9Uqt6rC25vbIDZPW8EaKmMwLle87aXpAVI
QsA8wujQx7p1S9oLjVSdu1AZeQZv4vHBZPU5R/xlOGocbs2TgJ1/Pn4eYVKDHW9Q
Sv3wHwiZgkwOT+7nAe7mAmuLsWl62rxF94Psw4imC9M35wpxat9hXWaIJPu6WwRS
DdaySlfxasG9aMg/CMCxf8Cjcmk4cKjJ8vRVhmW0J1ISuUofSfxiL6K611bTjaqb
oCO8qTxThLebTlvW6LrVZ8Etcr4HAp2zG6o0ZZmdYxMROJ9feMhJgZ7dIwUSOlK5
OSwAyfGsG1m4EqnfokgRx6Eg+ur2VirqZ6NcXEt5ljHHfnu4VeY/glHpSnfuwsN8
e27tSlJXv15EXEcASFqaujDUzV7qPYYcLYy5Wssjg9V/RTZoT3kHhouNnE5/doP+
d7qC/nheG6O3iT2cT4OMcnBi9nywaOR7ogMgauGZjDCB9pLrvTe4iBJFgfa2CkC3
QlB8lD8+tUXC6kGhlYv9RaZy/MP8CQWAYCel0k4vbjAB/KvY0KNHMpwmTzfGALhB
LI2/swhSpE6+0q3M3tylds15HQCmNSmO/1AVRdvgrJQXZbGz8PBCuxH7QqInS/ob
JXjx9lUaw9tRsVQKcqPp
=5nPt
-END PGP SIGNATURE-
>From 4eaa3d23ba484370c6b709ff21ca764a47033f34 Mon Sep 17 00:00:00 2001
From: Dmitry Lifshitz
Date: Wed, 9 Jan 2013 14:04:08 +0200
Subject: [PATCH] OMAPDSS: TFP410: support edge select pin strap
Pin 9 (EDGE/HTPLG) of tfp410 DVI transmitter is used (when I2C is
disabled) to control the data sampling on the rising or falling
edge of the pixel clock.
OMAP DSS timings for tfp410 should be adjusted according to
the chip pin strap to avoid various visual artifacts in the DVI output.
Enhance the tfp410 driver platform data with the flag to modify
default tfp410 timing settings according to the chip pin strap.
Signed-off-by: Dmitry Lifshitz
Signed-off-by: Igor Grinberg
---
drivers/video/omap2/displays/panel-tfp410.c |8
include/video/omap-panel-tfp410.h |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index e611ebd..77ce139 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -115,6 +115,14 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
ddata->pd_gpio = pdata->power_down_gpio;
ddata->invert_pd_gpio = pdata->invert_pd_gpio;
i2c_bus_num = pdata->i2c_bus_num;
+
+ /*
+ * If the data latch occur on the rising edge of the pixel
+ * clock, then the data strobe should be on the falling edge.
+ */
+ if (pdata->latch_on_rising_edge)
+ dssdev->panel.timings.data_pclk_edge =
+ OMAPDSS_DRIVE_SIG_FALLING_EDGE;
} else {
ddata->pd_gpio = -EINVAL;
i2c_bus_num = -1;
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
index cd1061e..f5424aa 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -27,11 +27,14 @@ struct omap_dss_device;
* @i2c_bus_num: i2c bus id for the panel
* @power_down_gpio: gpio number for PD pin (or -EINVAL if not available)
* @invert_pd_gpio:
Re: Request for OMAPDSS testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/13/13 19:01, Tomi Valkeinen wrote: > On 13/06/13 18:51, Igor Grinberg wrote: >> Hi Tomi, >> >> On 06/04/13 10:40, Tomi Valkeinen wrote: >>> Hi guys, >> >>> I've made some big changes on the omapdss device model, which involves >>> converting all the panel drivers. I've got only a bunch of boards, so I >>> hope some of you can perhaps do some minimal tests on some other boards. >> >>> I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43. >> >>> The code can be found from the below git branch. It's based on 3.10-rc1. >> >>> git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model >> >> Works on cm-t3730. >> Tested with tdo24m LCD and DVI. > > Thanks! > >> Although one thing is missing from the tfp410 driver is >> the PD GPIO polarity. I had to adjust it locally to get the DVI working. >> The original polarity was high = disabled, low = enabled. > > Hmm, but this is missing from the old driver also, isn't it? At least > with a quick glance the old and new tfp410 drivers do the same thing > with the PD gpio. Well, we were driving the PD GPIO from the board file... - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRva9qAAoJEBDE8YO64EfayBcP/iE1iVjdcYgf6SCw7IyrXHpC CUEroVpfQiLP8MwJ/ZNuGWwsFWbrD+Q8j5vSLJapjn1QPD3VEH830FXfWNzxxvhD ZWk5C3rsXy9q7FWonHixpbdPQnEptCBKkHqgpVPuLTaywC2h2jUxZoVLmBhbSoBo TQG210CxxE18qK+ztolxScA4ZlYwOAUPSNNJ2zE9UGI2n/8UrW9y0PJLluM2cAOd odlEuDNGmVmkbPsnRTI52r8IqhprrWC7S+5J1rsprJylgrudQXW0cSKJ7wi2bxy4 JWJd3C+pD7ocyRp76pm/kXD6NSAgrhqqHnbXK82DDlJvewAUOlF23iOIiXnsEDIY Uui4EvGVrzQl0Pe8eIxRIZzhJ2n7ryZ7360w0xiKc++X3s34kJ/mATlQi8Sm4Ve/ gbIqJRirdsvTDbxSwUOTX14qJvkZBvPA6Os1qSXmLsF7/DDUf3OreWL7JksKuxlI 1sGtvS7Y7IP7Wyr4PcEC6cb8Dy6GLT0o5GZWSC/VIPwHl+MlZMsMz4sp9AbuDrjQ TsoBmPpGi2/1i9+aCIeTzzgK9dZ320PlEYClXXvWOlG9YRqD01PIfhm4YfbCw0Dc /wr5mjTxkCvtcYY2uSbW0+xlBFNwPFinRGw+tXv5q/6xjh27BNmyVNLlvGawcKgc NrkwMGcNV0txD8TFhnEh =IxQT -END PGP SIGNATURE- -- 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: Request for OMAPDSS testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tomi, On 06/04/13 10:40, Tomi Valkeinen wrote: > Hi guys, > > I've made some big changes on the omapdss device model, which involves > converting all the panel drivers. I've got only a bunch of boards, so I > hope some of you can perhaps do some minimal tests on some other boards. > > I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43. > > The code can be found from the below git branch. It's based on 3.10-rc1. > > git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model Works on cm-t3730. Tested with tdo24m LCD and DVI. Although one thing is missing from the tfp410 driver is the PD GPIO polarity. I had to adjust it locally to get the DVI working. The original polarity was high = disabled, low = enabled. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRuep6AAoJEBDE8YO64EfaXsIP/19xfE9BlqtswMRgr3uOEaJf gnh9JcwMebMWiCFcyCw96EP7C/oW6GmVdyGDLnZmjJ9ZqA1al0I4Lia1LDJDNxtZ EDLIAaY1Wf4JN0wcVVAy1o4jHiYu6jpLLME3JNXGU6HwUgrSEcXOBd62veIjHcE3 f1p3HvGvfXJxU0/7JCohpRteTIqXjmG9BxBcyAnes0lhBozOwIOO0uLtiH+XeSJe Sn907bkdFk6qG8m+FSQWyJZMKLGZuE0nNOQ2obMeXk6nvj8TnO9x4W51I5DnsfgT ZnCtcnuC3RGLo1YmUBFSBDLsd9VZgD3K2c/ysfpwM9Os2XvImGbUkX6ToJ4iMr0T Ika2ljsMCbObbqQGiSbEM7JiOOc5QL6AB4b+uwD8VEDd4JwzkaMugBSYn8B38y5u PxCFWMihZGlyWVHS+qwON+cS59Y1xj0b7pvQRlar+ufQDk/gQBPNbJFnzIaU8B3D 6qx9TL7QmPJ172+dVIbcWLMMLLwa5ityajIaETgmQw6GMNLyUghf50I6k8rRHnzc JA3UFkeYGplYfVPHpWM2fNvSDin9yTELbGty0QzszlUWRHqpmXlyEYk/VMShWE8h LNKv+FZ1VwNFD3PmZINVB4IWflT9X/52hgrrACxBVAPG7xhahGA+XV6e10zc1cPd 7dnQIlL7OugAAWC5ttaw =sLEz -END PGP SIGNATURE- -- 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: Request for OMAPDSS testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tomi, On 06/04/13 10:40, Tomi Valkeinen wrote: > Hi guys, > > I've made some big changes on the omapdss device model, which involves > converting all the panel drivers. I've got only a bunch of boards, so I > hope some of you can perhaps do some minimal tests on some other boards. > > I've got: Beagle (old one), Panda, 4430SDP, Overo with LCD43. > > The code can be found from the below git branch. It's based on 3.10-rc1. > > git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model > > All you need to do to get things working is to enable the new panel > drivers from kernel config, under Device drivers/Graphics support/OMAP2+ > Display Subsystem support/OMAP Display Device Drivers/ Thanks for the patches. I still had no chance to look into them. Hopefully, I will be able to do some tests on the next week. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRsHK8AAoJEBDE8YO64EfaSj8P/ilqGfiSYkZG/ZM4hwv+MFt+ 0DllzT8zyHIPZVW7vzP2kCeBymZztpjrEYLkqnnXnv255EcYkAoDEPViHqv0L1h6 dQXSmMOsz9pgYANeDVhNG+PoP0DaBKWihZ7GVZ5MCROW+vSWLRpCIp8fIl7N+EGu XzFkMSCApuKxFMDOcLppSXAQLdFDcjAeUIiMsYOdnjeNtOy1iXb4metqZ/Ckm7lM KGP7H5eoHacrDwFZtmy7Glo4L+JEKzCkMfBr1tnMR5uTBDOzQAHDx0EP9mJ7Pjug gSADHCMa63cCFkXaLKtptBOF8Lgb165XBhs3yRVY/WKm15l815tHQ8rOpWoiaSkx LR65zuNsYTjMlaLNjJjVtpTb38+v/+IgMZzb7ALJJxsnSYDIXIx2qJkpVy7DVawK G0Z1xO6xzaxjua0PFv0QWcH7ayI9HKsFr346e2Wk5gNvHTJzQfXN8P/CuMmgeU3o KNCl+zMQ45bq4U9DfxlNjaswnWiY2GHaN3N8zjgVJCBXEHK7TJ4PSGhzpC262BwL jKFxebzIPEMJDq1fBu5OQiHx8lyUw+fu0Z64O0x/O2fwYep2/bP3pWUcloLKVK1y WmUcsl2P7lScchhqNHPYABEDiQDzT+ghp4nX5/WCRdy7qXskO1WPkrZjQaIKBFsX zwx9ysTRKOYxn0ESCsPw =QlvU -END PGP SIGNATURE- -- 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] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
On 04/17/13 11:38, Roger Quadros wrote:
> On 04/17/2013 10:56 AM, Igor Grinberg wrote:
>> On 04/17/13 04:30, Robert Nelson wrote:
>>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren wrote:
>>>> * Roger Quadros [130415 05:44]:
>>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>>>>>> Provide RESET and Power regulators for the USB PHY,
>>>>>> the USB Host port mode and the PHY device.
>>>>>>
>>>>>> Also provide pin multiplexer information for USB host
>>>>>> pins.
>>>>>>
>>>>>> This will not work for Rev Cx boards because of reversed logic
>>>>>> for USB_POWER_Enable.
>>>>>>
>>>>>> CC: Benoît Cousson
>>>>>> Signed-off-by: Roger Quadros
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap3-beagle-xm.dts | 62
>>>>>> +
>>>>>> 1 files changed, 62 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> index 5a31964..d394c51 100644
>>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> @@ -57,6 +57,60 @@
>>>>>> ti,mcbsp = <&mcbsp2>;
>>>>>> ti,codec = <&twl_audio>;
>>>>>> };
>>>>>> +
>>>>>> + /* HS USB Port 2 RESET */
>>>>>> + hsusb2_reset: hsusb2_reset_reg {
>>>>>> + compatible = "regulator-fixed";
>>>>>> + regulator-name = "hsusb2_reset";
>>>>>> + regulator-min-microvolt = <330>;
>>>>>> + regulator-max-microvolt = <330>;
>>>>>> + gpio = <&gpio5 19 0>; /* gpio_147 */
>>>>>> + startup-delay-us = <7>;
>>>>>> + enable-active-high;
>>>>>> + };
>>>>>> +
>>>>>> + /* HS USB Port 2 Power */
>>>>>> + hsusb2_power: hsusb2_power_reg {
>>>>>> + compatible = "regulator-fixed";
>>>>>> + regulator-name = "hsusb2_vbus";
>>>>>> + regulator-min-microvolt = <330>;
>>>>>> + regulator-max-microvolt = <330>;
>>>>>> + gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
>>>>>> + startup-delay-us = <7>;
>>>>>> + enable-active-high; /* FIXME: active-low for Rev. C */
>>>>>
>>>>> Benoit & Tony,
>>>>>
>>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>>>
>>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
>>>
>>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
>>> there is the "rev c" variant of the original beagle...
>>>
>>> It's too bad we can't read the 3 gpio pin states in the device tree
>>> and make a decision.
>>
>> I would recommend to move the detection to the boot loader and
>> adjust the DT blob at run time (in the boot loader).
>> This way, we will not need to deal with all the (sub)revision stuff.
>>
>>
> Moving the detection to bootloader is fine, but modifying the DT at
> runtime would create a debug/maintenance issue. Instead it could just
> pick one of the .DTBs and pass it to kernel.
Like this will not create create any debug/maintenance issues ;-)
We have no problem with debug, as all the DT nodes can be seen in
both U-Boot (with fdt commands) and Linux through procfs...
I've just dropped my 2 cents and I don't really insist...
>
> Since most users will be using rev-c, I think we should keep the original
> file 'omap3-beagle-xm.dts" as it is for rev-c boards.
> I can just create a new dts file for Revisions A and B that will be
> like so.
>
> +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
> @@ -0,0 +1,6 @@
> +/include/ "omap3-beagle-xm.dts"
> +
> +/* On Rev A/B USBHOST_PWR_EN is active high */
> +&hsusb2_power {
> + enable-active-high;
> +};
>
> Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
> quite many differences, I don't think it is a good idea to create a common
> file between the two.
>
> cheers,
> -roger
>
--
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: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
On 04/17/13 04:30, Robert Nelson wrote:
> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren wrote:
>> * Roger Quadros [130415 05:44]:
>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
ti,mcbsp = <&mcbsp2>;
ti,codec = <&twl_audio>;
};
+
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio5 19 0>; /* gpio_147 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = "regulator-fixed";
+ regulator-name = "hsusb2_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
+ startup-delay-us = <7>;
+ enable-active-high; /* FIXME: active-low for Rev. C */
>>>
>>> Benoit & Tony,
>>>
>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>
>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
>
> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
> there is the "rev c" variant of the original beagle...
>
> It's too bad we can't read the 3 gpio pin states in the device tree
> and make a decision.
I would recommend to move the detection to the boot loader and
adjust the DT blob at run time (in the boot loader).
This way, we will not need to deal with all the (sub)revision stuff.
--
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: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[...]
>>> Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
>>> backlight will supposedly be always on. Is it just a simple switch for
>>> the BL power, which does not affect the SPI in any way?
>>
>> Yes, it can for now.
>> Also, I think we should also take into account the backlight framework,
>> including PMW.
>
> I've updated this patch to set the LCD EN gpio once at boot time, and pass the
> LCD BL gpio to the panel driver. Updated patch below.
>
> ---
>
> commit a58a72363aa4359cdb75878de1517bd50faf9eb4
> Author: Tomi Valkeinen
> Date: Mon Dec 3 16:05:06 2012 +0530
>
> arm: omap: board-cm-t35: use generic dpi panel's gpio handling
>
> The cm-t35 board file currently requests gpios required to configure the
> tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and
> shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: Only BL enable gpio is handled in the panel driver. The LCD enable
> GPIO is handled in the board file at init time, as there's a 50 ms delay
> required when using the GPIO, and the panel driver doesn't know about
> that.
>
> Cc: Tony Lindgren
> Cc: Igor Grinberg
> Signed-off-by: Tomi Valkeinen
Looks good, thanks!
Acked-by: Igor Grinberg
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index bccd3e5..cccbfea 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -190,32 +190,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -227,8 +201,10 @@ static void cm_t35_panel_disable_tv(struct
> omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable= cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 1,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -292,11 +268,6 @@ static struct spi_board_info cm_t35_lcd_spi_board_info[]
> __initdata = {
> },
> };
>
> -static struct gpio cm_t35_dss_gpios[] __initdata = {
> - { CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW, "lcd enable"},
> - { CM_T35_LCD_BL_GPIO, GPIOF_OUT_INIT_LOW, "lcd bl enable" },
> -};
> -
> static void __init cm_t35_init_display(void)
> {
> int err;
> @@ -304,23 +275,21 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> +
> + err = gpio_request_one(CM_T35_LCD_EN_GPIO, GPIOF_OUT_INIT_LOW,
> + "lcd bl enable");
> if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> + pr_err("CM-T35: failed to request LCD EN GPIO\n");
> return;
> }
>
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> msleep(50);
> gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
>
> err = omap_display_init(&cm_t35_dss_data);
&
Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/13 11:07, Tomi Valkeinen wrote: > On 2013-03-31 12:17, Igor Grinberg wrote: >> >> >> On 03/28/13 19:02, Tomi Valkeinen wrote: >>> On 2013-03-28 18:09, Igor Grinberg wrote: >>>> On 03/28/13 14:49, Tomi Valkeinen wrote: >>>>> Boards with multiple display options for the same video bus have all the >>>>> possible linux display devices present at the same time. Only one of >>>>> those devices should be used at a time, as the video bus cannot be >>>>> shared. >>>> >>>> Yes, only one can be used at a time, but you can switch at runtime... >> >>> Yep. But the panel drivers need to know about this, and they cannot do >>> more or less anything in the driver probe function, which I think should >>> be the place to reserve resources and do initialization. With the >>> current model that would lead to multiple drivers trying to acquire the >>> same resources. >> >> Yep, this is a problem, but it only means that probably >> the platform device framework is not suitable for this. >> >> What about having some kind of display manager which will have a private >> list of registered devices and will instantiate only those that are marked >> active? >> This also might be useful with DT. > > We can't have a generic manager that handles instantiating the devices, > as we don't know what device they are. They could be platform devices, > i2c, anything. There could even be a single device that creates multiple > displays. Unless, the registered device node is descriptive enough, or the device node can "instantiate itself". We use the "ops" structures all over the kernel. What about the capebus? Can it help with abstracting such things? > >>>>> This model is hacky, and will be changed in the forthcoming DSS patches >>>>> to a model where only one display device can be present on a single >>>>> video bus. >>>> >>>> What do you mean by "present"? >>>> Is it active? or registered? or compiled in? >> >>> I mean that only one device can be registered. Well, nothing strictly >>> prevents having multiple devices registered, but if the devices have >>> matching drivers, the drivers would acquire the same resources. Possibly >>> the same gpios, but at least the same video bus. >> >> Well, I think, we should follow/extend the already existing EDID concept... >> Instantiate a display device only when one has been "plugged in". >> By "plugged in" I mean enabled - made active. > > This brings the complication that we need a way to make the display > active even if the display device doesn't exist. So we need to know > about the display even if it's not there. Yes, well, I mean that the process of making the display active can involve registering the display device, no? And yes, it does bring the complication, but I don't really see a way we can avoid such complications and yet support the modern hardware. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRWr8VAAoJEBDE8YO64Efa5sgP/ArPjYtGakOnWkbFah5ClnPH sOMDwnTEW76rLpXzPE63dTBIImiBhKpaKNKK3pxdPH7uhZ5qr1usi/s/W59MPrYA 7lsZnkdsJLk/piFKk1IdB9Q+ke7qftCEmVTrv9fXtYrojZ9NHH1yGqmjQIINyzUm hGTbplKUldfMSh9z+XszUcGgBkkZQgMd435eJKOYw9Bny56u0ekOfPIo5pHTJioc F4gQybWQ41hpBVWe8OkYH8tN9hOnujbdgQ+K4K5JYizJV0NYnGgxESvescieAINn 0INEYhiyD97Fcr6sFFjOSqkLTZoBaXFLDl0EPWqasImf5sCLapmtkqfpMRlUjoiW MiVv6XACE5AmFicivjPowDn01HurH0Q8aXXhvhtSEu8oLePN3gH5PW9P6VIjAUbM 85OT+VkPfWIUupw2aeygy+ePoBpjj4NtZWzhpxzdDi/k5HkrZvSh3uGernCbAsYj /JV4wZRQQVml7j65uYRLmnKx+tMbBnd/QU96OLdSOdGaNor+bY0x0zDcy4DAKuw3 /W0HPGMr6dctBOb26ofYn97jxjLAcULKTWffykxktNyB1ODzN2NdEUnUv6rtq4Bv 6EA7EaK1dehM2TV4eVNiCxxvv88Kk58uJqzuxvx2BHGtDkbygJGxkBZ41/MNWQOT 3UMYsUEKecOie5cT+JtG =IrRQ -END PGP SIGNATURE- -- 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 00/28] OMAP: DSS related board file changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/13 11:01, Tomi Valkeinen wrote: > On 2013-03-31 11:39, Igor Grinberg wrote: >> On 03/28/13 18:48, Tomi Valkeinen wrote: >>> On 2013-03-28 17:31, Igor Grinberg wrote: >>>> On 03/28/13 14:48, Tomi Valkeinen wrote: >>>>> So here are the DSS related board file changes for 3.10. >>>>> >>>>> First there are a bunch of patches adding the Kconfig options so that >>>>> only one >>>>> display device is created for a single video bus. Only Overo had more >>>>> than two >>>>> displays on the same bus, but unfortunately there were multiple boards >>>>> with a >>>>> setup that puts an LCD and DVI output on the same video bus. >>>> >>>> Hmmm, so basically, if one could switch the display at runtime... >>>> This cannot be done anymore... >>>> This sounds like feature removal, no? >>>> I know several of our clients who used this feature >>>> (at least for evaluation purposes). >> >>> At some point in time it was possible to have multiple displays for the >>> same bus, and switch them at runtime. >> >>> Sometime later it was changed so that the board file adds all the >>> displays, but only one (per bus) is actually added to the list of >>> panels, but you could still set the default display in the kernel args, >>> and thus you could select which display gets added. >> >> Yeah, I remember we had to hack this to have the functionality back... > > Ok. You could've informed me so that I knew it's needed =). I've > received no complaints about it, so I thought nobody is even using it. Yeah, I know, we wanted to make sure that this is not our fault and when we did and it worked, I've lost in the amount of patches for DSS that were sent and what are the real intentions (also taking into account that it all was post factum). > >>> The reason why the multiple-displays-per-bus is problematic is that the >>> video bus cannot be shared, and if we have multiple devices on the same >>> bus, the drivers need extra trickery, delaying initializations, etc, to >>> handle this. And it still doesn't work right, as it's easy to get two >>> displays enabled at the same time, configuring the same video bus, >>> creating a mess. >> >> Yep, looks like additional display manager framework is needed. >> Which will manage the displays on per bus basis? >> >> >>> Quite often the case is that the other displays are not even present >>> physically. But it is true that some boards have gpio switches that can >>> be used to change the display during runtime. >> >> I don't think the runtime switch requirement will ever go away, so we'd >> better prepare for it wisely. >> >> >>>> Is there any strong pros you obtain while removing this feature? >> >>> For an user, only indirectly. The change will make things sane on the >>> display side, and will thus make it much easier to proceed towards DT >>> adaptation, and Common Display Framework. While I can't say it's a >>> strict must to remove this feature, I can say that it's been a constant >>> headache for me for, well, ever. And I presume CDF would not have this >>> feature anyway, as it's rather bad design. >> >> Well, I don't know about the CDF, but the runtime switch was there >> for ages... Think of a DVI or an HDMI... they have the EDID stuff >> to make the switch work as expected and it really brings multiple >> displays to the same video bus. >> I see this is only a meter of how we represent things. >> Instead of real EDID (or in addition), that comes with the display, >> currently we have the panel info already in the kernel and >> panel driver with board specific callbacks to make it work. >> So abstracting the above (in the long run) to CDF or some other >> framework, should suit everybody's needs. >> Probably, we will need board specific drivers, but that never >> was a problem... > > Comparing desktop DVI/HDMI to our case is not a very good comparison. > For desktop DVI/HDMI there are no panel devices or such, so it's trivial > to manage multiple outputs in the display driver. Well, reading EDID can sometimes involve additional hackery, but you are right in the general case. > > We need panel device hotplug/unplug support to make this work properly, > and as there's no generic way to do that, we need board specific dri
Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/13 19:02, Tomi Valkeinen wrote: > On 2013-03-28 18:09, Igor Grinberg wrote: >> On 03/28/13 14:49, Tomi Valkeinen wrote: >>> Boards with multiple display options for the same video bus have all the >>> possible linux display devices present at the same time. Only one of >>> those devices should be used at a time, as the video bus cannot be >>> shared. >> >> Yes, only one can be used at a time, but you can switch at runtime... > > Yep. But the panel drivers need to know about this, and they cannot do > more or less anything in the driver probe function, which I think should > be the place to reserve resources and do initialization. With the > current model that would lead to multiple drivers trying to acquire the > same resources. Yep, this is a problem, but it only means that probably the platform device framework is not suitable for this. What about having some kind of display manager which will have a private list of registered devices and will instantiate only those that are marked active? This also might be useful with DT. > >>> This model is hacky, and will be changed in the forthcoming DSS patches >>> to a model where only one display device can be present on a single >>> video bus. >> >> What do you mean by "present"? >> Is it active? or registered? or compiled in? > > I mean that only one device can be registered. Well, nothing strictly > prevents having multiple devices registered, but if the devices have > matching drivers, the drivers would acquire the same resources. Possibly > the same gpios, but at least the same video bus. Well, I think, we should follow/extend the already existing EDID concept... Instantiate a display device only when one has been "plugged in". By "plugged in" I mean enabled - made active. > >>> This patch creates Kconfig options to select which of the display >>> devices is present on the board. While this model is also somewhat >>> hacky, and prevents us from using a single kernel image for all the >>> display options, it allows us to make the DSS driver changes for DT >>> adaptation. And with DT, the information about display devices can be >>> passed from the bootloader, solving the mess. >> >> Hmmm, the fact that we cannot use the same binary for multiple displays... >> This does not sound right and good at all... >> While we try to move to support multiple platforms in the same binary, we >> cannot support multiple displays? I agree that the multiplatform stuff is >> not really related, but you know what I mean... > > Yes, I quite agree that this sucks =). There are a few reasons I chose > to try this approach: > > - The whole multi-display feature is hacky > > - DT support for DSS has been in development too long time. We really > need it, preferably yesterday. This change helps getting DT support ready. Yes, but I don't think this should involve removing the existing functionality.. Let me exaggerate a bit: this is like removing ARM support from mainline, so it will make less noise and headache to Linus... > > - Common Display Framework won't (most likely) support this kind of > feature, as the feature itself is rather hacky, so this would anyway > disappear. Hmmm, I don't think it will disappear, but instead you will keep receiving hacky patches to bring that support in... So, IMO, it would be better designed to support this or at least keep it in mind, so there will no necessity for hacky patches... > > - DT support should solve this (except for runtime switching), and the > board files are on the way out (as far as I understand). So in that > sense this is temporary. But not the runtime switching... The runtime switching should be done in the framework. > > - Keeping this feature functional consumes considerable amount of > man-hours, which are in short supply. This is where you should request some help from the interested sides... And mailing lists are quite handy. > > I still feel quite bad about this, though. Any ideas how to manage this > better are appreciated. > >> I bet there must be a much better solution for DT support. > > Yes, I think I covered that in the last email. DT will solve the issue, > except for runtime switching, which is still open. I'm not sure how > these board specific drivers would be implemented. Well, at least the generic kernel display parameter will do more than half of the job. We can discuss the runtime switch stuff, but it is really a non-sense to compile a kernel for specific display... - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment:
Re: [PATCH 00/28] OMAP: DSS related board file changes
On 03/28/13 18:57, Tony Lindgren wrote: > * Tomi Valkeinen [130328 09:53]: >> On 2013-03-28 17:31, Igor Grinberg wrote: >>> On 03/28/13 14:48, Tomi Valkeinen wrote: >>> >>> I've missed this discussion, can you please point to it? >> >> Well, not so much discussion, but a few mails under "Display related >> board specific boot args" subject on l-o. I proposed a board specific >> kernel argument to select the displays present, Tony was less than >> enthusiastic about that. > > If we can come up with a Linux generic command line option to select > the panel that can be supported also in the long run, I have no > objections to that naturally. What I'm against is a temporary > custom cmdline option until the board-*.c files go away as we > don't want to support it in the long run. Agreed totally, the panel select option does not have to be board specific (and it better not be...). -- 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: [PATCH 00/28] OMAP: DSS related board file changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/13 18:48, Tomi Valkeinen wrote: > On 2013-03-28 17:31, Igor Grinberg wrote: >> On 03/28/13 14:48, Tomi Valkeinen wrote: >>> So here are the DSS related board file changes for 3.10. >>> >>> First there are a bunch of patches adding the Kconfig options so that only >>> one >>> display device is created for a single video bus. Only Overo had more than >>> two >>> displays on the same bus, but unfortunately there were multiple boards with >>> a >>> setup that puts an LCD and DVI output on the same video bus. >> >> Hmmm, so basically, if one could switch the display at runtime... >> This cannot be done anymore... >> This sounds like feature removal, no? >> I know several of our clients who used this feature >> (at least for evaluation purposes). > > At some point in time it was possible to have multiple displays for the > same bus, and switch them at runtime. > > Sometime later it was changed so that the board file adds all the > displays, but only one (per bus) is actually added to the list of > panels, but you could still set the default display in the kernel args, > and thus you could select which display gets added. Yeah, I remember we had to hack this to have the functionality back... > > The reason why the multiple-displays-per-bus is problematic is that the > video bus cannot be shared, and if we have multiple devices on the same > bus, the drivers need extra trickery, delaying initializations, etc, to > handle this. And it still doesn't work right, as it's easy to get two > displays enabled at the same time, configuring the same video bus, > creating a mess. Yep, looks like additional display manager framework is needed. Which will manage the displays on per bus basis? > > Quite often the case is that the other displays are not even present > physically. But it is true that some boards have gpio switches that can > be used to change the display during runtime. I don't think the runtime switch requirement will ever go away, so we'd better prepare for it wisely. > >> Is there any strong pros you obtain while removing this feature? > > For an user, only indirectly. The change will make things sane on the > display side, and will thus make it much easier to proceed towards DT > adaptation, and Common Display Framework. While I can't say it's a > strict must to remove this feature, I can say that it's been a constant > headache for me for, well, ever. And I presume CDF would not have this > feature anyway, as it's rather bad design. Well, I don't know about the CDF, but the runtime switch was there for ages... Think of a DVI or an HDMI... they have the EDID stuff to make the switch work as expected and it really brings multiple displays to the same video bus. I see this is only a meter of how we represent things. Instead of real EDID (or in addition), that comes with the display, currently we have the panel info already in the kernel and panel driver with board specific callbacks to make it work. So abstracting the above (in the long run) to CDF or some other framework, should suit everybody's needs. Probably, we will need board specific drivers, but that never was a problem... > >>> So the ifdeffery is not very nice. But, as discussed, this is the best way >>> forward, and should be seen as a temporary solution until we get full DT >>> support. >> >> I've missed this discussion, can you please point to it? > > Well, not so much discussion, but a few mails under "Display related > board specific boot args" subject on l-o. I proposed a board specific > kernel argument to select the displays present, Tony was less than > enthusiastic about that. Yes, I can understand that ;-) > >> And what will change with full DT support? >> Will we be able to define several displays through DT and >> select and active one during runtime? > > No, not as such. DT will let the bootloader pass the DT data, thus > telling which displays are present. So we can have single kernel binary, > which will work for all the cases. IMO, single kernel binary is a must. > > Dynamic switching during runtime will still be missing. This is not good, as it removes a functionality that worked before... > For that I think > we need board specific drivers. That driver should know about board > specific restrictions etc (which are rather missing currently), remove > the old display device, and create the new one. Well, yes we need a board specific drivers, but we need even more... Board specific driver should not poke with devices... I think for that we will need some kind of generic
Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options
On 03/28/13 14:49, Tomi Valkeinen wrote: > Boards with multiple display options for the same video bus have all the > possible linux display devices present at the same time. Only one of > those devices should be used at a time, as the video bus cannot be > shared. Yes, only one can be used at a time, but you can switch at runtime... > > This model is hacky, and will be changed in the forthcoming DSS patches > to a model where only one display device can be present on a single > video bus. What do you mean by "present"? Is it active? or registered? or compiled in? > > This patch creates Kconfig options to select which of the display > devices is present on the board. While this model is also somewhat > hacky, and prevents us from using a single kernel image for all the > display options, it allows us to make the DSS driver changes for DT > adaptation. And with DT, the information about display devices can be > passed from the bootloader, solving the mess. Hmmm, the fact that we cannot use the same binary for multiple displays... This does not sound right and good at all... While we try to move to support multiple platforms in the same binary, we cannot support multiple displays? I agree that the multiplatform stuff is not really related, but you know what I mean... I bet there must be a much better solution for DT support. -- 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: [PATCH 00/28] OMAP: DSS related board file changes
On 03/28/13 14:48, Tomi Valkeinen wrote: > So here are the DSS related board file changes for 3.10. > > First there are a bunch of patches adding the Kconfig options so that only one > display device is created for a single video bus. Only Overo had more than two > displays on the same bus, but unfortunately there were multiple boards with a > setup that puts an LCD and DVI output on the same video bus. Hmmm, so basically, if one could switch the display at runtime... This cannot be done anymore... This sounds like feature removal, no? I know several of our clients who used this feature (at least for evaluation purposes). Is there any strong pros you obtain while removing this feature? > > So the ifdeffery is not very nice. But, as discussed, this is the best way > forward, and should be seen as a temporary solution until we get full DT > support. I've missed this discussion, can you please point to it? And what will change with full DT support? Will we be able to define several displays through DT and select and active one during runtime? -- 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: [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices
On 03/28/13 14:48, Tomi Valkeinen wrote: > From: Archit Taneja > > The omap_dss_device's platform_enable/disable callbacks don't do anything for > any of the boards. The platform calls from the VENC driver will also be > removed > in the future. Remove these calls from boards which have a VENC device. > > Signed-off-by: Archit Taneja > Signed-off-by: Tomi Valkeinen This should have been done long long time ago... Thanks! Acked-by: Igor Grinberg -- 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: OMAP baseline test results for v3.9-rc1
On 03/12/13 18:40, Paul Walmsley wrote: > > Here are some basic OMAP test results for Linux v3.9-rc1. > Logs and other details at: > > http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/ [...] > Failing tests: needing investigation > [...] > * CM-T3517: boot hangs with MMC root > - Due to missing MMC setup in board file > - http://www.spinics.net/lists/arm-kernel/msg211471.html > - Longstanding bug This should have been fixed by: ff95793 (ARM: OMAP3: cm-t3517: add MMC support) I also can't find the MMC rootfs boot log on your website. -- 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: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/13 14:52, Tomi Valkeinen wrote: > On 2013-02-14 14:37, Igor Grinberg wrote: >> On 02/14/13 12:59, Tomi Valkeinen wrote: >>> On 2013-02-14 11:43, Igor Grinberg wrote: >> >>>>> True, it's generic, but does it work reliably? The panel hardware is now >>>>> partly handled in the backlight driver, and partly in the omap's panel >>>>> driver (and wherever on other platforms). >>>> >>>> It works reliably on other platforms, but not on OMAP - because >>>> we need to cope with the OMAP specific framework... >> >>> How do you handle the gpios on other platform? Those are the ones >>> causing the issues here, right? >> >> Well, I'm also talking about something that is a history already. >> Remember, we had multiple panel drivers inside the >> video/omap2/displays and then they were consolidated into the >> "generic dpi/dsi/whatever". > > Sorry, I miss the point. Was that a bad thing? Didn't it simplify the > task for you with simple panels? It could've been taken even further, > though (see below). Yes it was a good thing (I have already told this below). > >> And yes you are right, on the platforms I'm aware of, the GPIO is not >> handled. Apparently its hardware default (pull resistor) is always on... > > Ok, so the simple fix of setting the GPIOs only in the board file is > acceptable for now. Yep. I also told this already in one of the previous emails. > > Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the > backlight will supposedly be always on. Is it just a simple switch for > the BL power, which does not affect the SPI in any way? Yes, it can for now. Also, I think we should also take into account the backlight framework, including PMW. > >>> Or is there something else with OMAP DSS that you need to specifically >>> cope with? >> >> The fact there is a need to create a OMAP specific driver. >> I'm not talking about the generic driver which only needs to have the >> controller specific data (e.g. porches, pixel clock, bus width). >> The generic driver was one of the good ways to go. > > Well, we could also have an even more generic driver that takes the > video timings from the board file as platform data. Then all you would > need to do is to define the timings in the board file, as I think is > done for other platforms also. Yep. That sounds reasonable also for cases where the bus width is the hardware (board) property. > > I'm not very fond of that idea, as I think hardcoded device specific > data should not be given as parameters, but they should be handled by > the device driver internally, as it should know that device specific > data already. Yes, that is why I think the generic driver for "simple" panels was a good idea. There was some flexibility missing though. For example the resolution setting which in turn drags another set of timings and pixel clock. There are panels that support more than one resolution. > > But, in practice, making this kind of even more generic panel driver > will probably make life easier for everyone, so I think we'll have one > with CDF. I'm looking forward to see it happening! - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHOvEAAoJEBDE8YO64EfaCZ0P/32SYC7MZRJMfUVrnzZtJZpn 9BKzrvO0h/GKZMbKoKKNFwmvlTxEocELLkljF35ipbc51C/dpD45ZmMBvu4s8owE 6bopGw6ssTahTKk0zY5PekTamZT7UlY86hI9ZcZBxSzY8xaj7UCSPnJ3qzY2ZGzA 4heJW01mlHr9i1qkOzxz0IHA2CdQmQltAsW12NFCWYBRpDfhrYtECwhlnvLXHEzy nqXNpRHOnrL/hqvJwor1X+D/O1JlyxUiVr6+7sAZqXxvv/iMX8Nc1XeTObgGbse6 1bpipPD57etqISsN1g9ur1tU5f6KvoR4IA35RaCCkBFINIXMEBl7kr5X9Bcg3giE 3pz23k91KRloOcXJ0OvLHp7RnSrwswU/4C3Cse+95cY0wyChaVlwJtySEnfGALWV aiuw89v6DXaC5WDQq55UtTc3qjc23Ehut8i184PAv5HKrDHLLjVg4HqgGjC9uGEn JKOxOnfMTstqyKC2whW+Pep3g4npJAHsn/0QmpdSJQ/vEwm7CmXBZeR6DwcTSLAT xR1SUWwHav2HqpYUz4y7TgIPuwsR+VNKn/mSOTbhbLB4s9bowPMxMiqz2AQn3ige YyMTo7KnObivXZydrVrx0/e/DJC4ENGpE3macVQytr0BpjJhK1+XiNMHa17+Mymm U45VDKrUgaYcYXW2L4JN =xeSz -END PGP SIGNATURE- -- 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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/13 12:59, Tomi Valkeinen wrote: > On 2013-02-14 11:43, Igor Grinberg wrote: > >>> True, it's generic, but does it work reliably? The panel hardware is now >>> partly handled in the backlight driver, and partly in the omap's panel >>> driver (and wherever on other platforms). >> >> It works reliably on other platforms, but not on OMAP - because >> we need to cope with the OMAP specific framework... > > How do you handle the gpios on other platform? Those are the ones > causing the issues here, right? Well, I'm also talking about something that is a history already. Remember, we had multiple panel drivers inside the video/omap2/displays and then they were consolidated into the "generic dpi/dsi/whatever". And yes you are right, on the platforms I'm aware of, the GPIO is not handled. Apparently its hardware default (pull resistor) is always on... > > Or is there something else with OMAP DSS that you need to specifically > cope with? The fact there is a need to create a OMAP specific driver. I'm not talking about the generic driver which only needs to have the controller specific data (e.g. porches, pixel clock, bus width). The generic driver was one of the good ways to go. > >>> Thinking about it, if you do move the gpio handling to the backlight >>> driver, the panel driver will only handle the DPI video stream. Then it >>> should not have any effect on the SPI side (presuming the panel doesn't >>> use the pixel clock as func clock), although there's probably still >>> possibility for display artifacts on enable and disable, if the order of >>> operations goes the wrong way. >> >> Yep, again, that is correct. > > It's correct that there may be artifacts? How do you manage the ordering > of the operations on other platforms? Yep, there might be artifacts if the ordering is incorrect. The ordering is something that should be solved by the CDF. > >>>> And since the toppoly was and is used on other systems, why the hell >>>> should anyone duplicate the driver just to please the OMAP specific >>>> panel framework? The real problem is that this framework should not be >> >>> Not to please. To make it reliable. >> >> Well, there are multiple ways to make it reliable. >> And I don't think that the best would be: make it OMAP specific. > > I'm not saying it's the best option. I'm saying it's a realistic option > to get it working. > >>> Well, if duplicating the code gives us reliable drivers, versus >>> unreliable without duplicating, then... I don't see it as that bad. >> >> Hmmm... I don't think this fits the mainline (upstream) philosophy. >> This can be also extrapolated into: let's make our own Linux ARM fork >> so it will be more reliable... >> This is the way how vendor specific kernel releases work. > > Well, we are talking about a smallish driver here. Not an arch fork. If > the options are a) platform specific driver that works, or b) generic > driver that's not reliable, or c) no driver at all, I can't really see > why a) would be such a horrible option for the time being. I think there is b.5) where the driver is both generic and reliable, but I haven't looked into this deep enough. > > But this discussion is getting a bit out of hand. It sounds to me that > for this panel in question we can manage with the current approach, so > this whole line of discussion doesn't matter for this specific problem. > >>> If it was easy, somebody would've done it. >> >> In fact this is done all the time on multiple drivers and frameworks. >> Also, I don't say this is easy, but I also don't think this too hard. >> It is also a function of resources (time/will/experience/etc.). > > I think the CDF discussions have already proven that it is quite hard. > But feel free to contribute. I will contribute as much as I can in terms of my paid work. I always do... > > And I've talked about a common display framework already years ago, and > I've tried to design OMAP DSS panels from start in such a way that they > try to depend on OMAP DSS features as little as possible, to make it > easier to generalize them. Just to prove I'm not indifferent about the > issue =). Yep, your work was fruitful and no one can take it from you! That's why I said that I'm not trying to blame or accuse anyone. That is more of a wish that the CDF will come as quickly as it can. Because currently it is clear that there are cases where we don't have a
Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/13 11:09, Tomi Valkeinen wrote: > On 2013-02-14 10:37, Igor Grinberg wrote: >> On 02/14/13 09:09, Tomi Valkeinen wrote: >>> On 2013-02-14 08:56, Igor Grinberg wrote: >>>> On 02/13/13 17:59, Tomi Valkeinen wrote: >> >>>>> Okay, so I just realized there's an spi backlight driver used here, and >>>>> that backlight driver is actually handling the SPI transactions with the >>>>> panel, instead of the panel driver. So this looks quite messed up. >>>> >>>> Yep, it always was. >>>> The whole DSS specific panel handling inside the >>>> drivers/video/omap2/displays is a mess. >> >>> Well, that's not mess itself, it's just omap specific panel framework. >>> But dividing single device handling into two separate places is a mess. >> >> Yes, you are right it is not the mess, but it prevents the panel to >> be used on other systems and that is BAD. >> At the very least, drivers/video/backlight is a generic place that can be >> used not just on OMAP. > > True, it's generic, but does it work reliably? The panel hardware is now > partly handled in the backlight driver, and partly in the omap's panel > driver (and wherever on other platforms). It works reliably on other platforms, but not on OMAP - because we need to cope with the OMAP specific framework... > > At least currently there's a dependency between the two, as the LCD_EN > gpio is handled by the panel driver, which affects the functioning of > the backlight driver. Is it ensured that the panel driver does not > disable the panel when the backlight driver does spi transactions? > > That's what I meant with the mess, it's difficult to make it work > reliably. I know that for some panels such a two-driver approach would > not work at all. Although I guess it's working well enough for you for > this panel. Yep, that is correct - this is the mess. > > Thinking about it, if you do move the gpio handling to the backlight > driver, the panel driver will only handle the DPI video stream. Then it > should not have any effect on the SPI side (presuming the panel doesn't > use the pixel clock as func clock), although there's probably still > possibility for display artifacts on enable and disable, if the order of > operations goes the wrong way. Yep, again, that is correct. > >> And since the toppoly was and is used on other systems, why the hell >> should anyone duplicate the driver just to please the OMAP specific >> panel framework? The real problem is that this framework should not be > > Not to please. To make it reliable. Well, there are multiple ways to make it reliable. And I don't think that the best would be: make it OMAP specific. > >> OMAP specific... >> Of course I'm aware of the fact that currently there is no generic >> panel framework, but forging something OMAP specific which is obviously >> used on most of the other architectures/platforms (and I mean >> panel<->controller relations), is not a good way to go. > > Well, if duplicating the code gives us reliable drivers, versus > unreliable without duplicating, then... I don't see it as that bad. Hmmm... I don't think this fits the mainline (upstream) philosophy. This can be also extrapolated into: let's make our own Linux ARM fork so it will be more reliable... This is the way how vendor specific kernel releases work. > >> Although, I'm also aware of the fact that most things are done this way: >> do several specific drivers/frameworks, find the common stuff, and extract >> it into a core driver/framework. So I don't want to blame anyone - that's >> just the way how we do things, right? > > If it was easy, somebody would've done it. In fact this is done all the time on multiple drivers and frameworks. Also, I don't say this is easy, but I also don't think this too hard. It is also a function of resources (time/will/experience/etc.). > >>>>> For a quick solution, can we just set the LCD_EN at boot time (with the >>>>> msleep), and not touch it after that? >>>> >>>> That would be sensible for now, so this series can be merged. >>>> As a more appropriate (and long term) solution, >>>> I plan on moving the panel reset pin handling to the spi backlight >>>> driver itself. >> >>> Well, if you must. But I suggest moving the whole panel handling into a >>> (omap specific) panel driver, as it's done for other panels. That way >>> you'll have a prope
Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/13 09:09, Tomi Valkeinen wrote: > On 2013-02-14 08:56, Igor Grinberg wrote: >> On 02/13/13 17:59, Tomi Valkeinen wrote: > >>> Okay, so I just realized there's an spi backlight driver used here, and >>> that backlight driver is actually handling the SPI transactions with the >>> panel, instead of the panel driver. So this looks quite messed up. >> >> Yep, it always was. >> The whole DSS specific panel handling inside the >> drivers/video/omap2/displays is a mess. > > Well, that's not mess itself, it's just omap specific panel framework. > But dividing single device handling into two separate places is a mess. Yes, you are right it is not the mess, but it prevents the panel to be used on other systems and that is BAD. At the very least, drivers/video/backlight is a generic place that can be used not just on OMAP. And since the toppoly was and is used on other systems, why the hell should anyone duplicate the driver just to please the OMAP specific panel framework? The real problem is that this framework should not be OMAP specific... Of course I'm aware of the fact that currently there is no generic panel framework, but forging something OMAP specific which is obviously used on most of the other architectures/platforms (and I mean panel<->controller relations), is not a good way to go. Although, I'm also aware of the fact that most things are done this way: do several specific drivers/frameworks, find the common stuff, and extract it into a core driver/framework. So I don't want to blame anyone - that's just the way how we do things, right? > >> Those panels can be (and are) used not only with OMAP based boards. > > True, but as there's no generic panel framework, that's the best we can > do. But see CDF (common display framework) discussions if you're > interested in what's hopefully coming soon. Yep, I've seen the CDF discussion and I think this is a good way to go. > >>> For a quick solution, can we just set the LCD_EN at boot time (with the >>> msleep), and not touch it after that? >> >> That would be sensible for now, so this series can be merged. >> As a more appropriate (and long term) solution, >> I plan on moving the panel reset pin handling to the spi backlight >> driver itself. > > Well, if you must. But I suggest moving the whole panel handling into a > (omap specific) panel driver, as it's done for other panels. That way > you'll have a proper panel driver for it, for omap, and when CDF comes, > you'll get a platform independent panel driver for it. You can't just move generic architecture/platform independent stuff into OMAP specific framework... Just think about this... It's insane. > > Of course, if you have multiple platforms already using that backlight > driver, the omap specific approach may not be enticing. So perhaps it's > easier to just do the quick fix and wait for CDF. That is exactly what I am talking about. In addition, AFAIR, the reset pin is the property of the toppoly panel hardware, so that is why I think, we should let the toppoly driver (currently spi backlight, later hopefully CDF) handle it correctly along with the spi sequences. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHKJGAAoJEBDE8YO64EfacksP/j79jaDbnXpFcwT9KlInp8OE e+XNi5Vt8zbqhj4gHtxZlN/eIQsVRfuivm9CTp5aJSZHBDAJlPNKobmwjFrDLO9V RtYTwLAcuWyOdnutIQ52xNwXSntQknd8yxm1qJZMEBjEP+mcQxISWXXMsdxlQEiT emNtU42W16ZOR34kHUoVfYLkV0v02/JVygt3oaU71+mrNBOt+5L6cHcXaQZPKSes LUOcyz0qJfzKbnmmZnP/+clTIids83u8rVCNZ1/JoIIlR4rvtNcxRM8Apa8KFJx/ PVT38ds62F0L0qbxL3UmI1uJS2KuEHuJyjYo0uDeQqeeSyz7Q3ZG4TwAJYkWZdWQ TdFbVrsXbK408FT33VIP4rOzDjqO93IK6f5ld0tZoIvL59NLwgXIejJn6jTNNcU4 p25mUXGSDnaZrNU5cC7d/MzSMt60XQx3UiHjEXD3eJAT33yb+DdBaQwloMCXJQOx vnseFqhuAzgFHd9LEl47LBg7eXudjaSvWYfJOV0SoB9s7QM8m/YUhnmqmtvdCqZL fKMJcAjCgm0BG2P6ss79sl6P4XDoBF1LOwSwz4dRmocA3TP7vBNkuRoK08vQe6gv Qi7hJ05ioa8THt77FxMHtf+ZrO34/L6gHxZqrOD++OgPPdL6qtegemyp4IaKKbUg q3Mpgsr4ODyStdjEXxTC =lIHm -END PGP SIGNATURE- -- 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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/13/13 17:59, Tomi Valkeinen wrote: > On 2013-02-13 17:28, Tomi Valkeinen wrote: >> On 2013-02-13 17:16, Igor Grinberg wrote: >>> Hi Archit, >>> >>> On 02/13/13 16:21, Archit Taneja wrote: >>>> The cm-t35 board file currently requests gpios required to configure the >>>> tdo35s >>>> panel, and provides platform_enable/disable callbacks to configure them. >>>> >>>> These tasks have been moved to the generic dpi panel driver itself and >>>> shouldn't >>>> be done in the board files. >>>> >>>> Remove the gpio requests and the platform callbacks from the board file. >>>> Add the gpio information to generic dpi panel's platform data so that it's >>>> passed to the panel driver. >>>> >>>> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN >>>> gpio was >>>> enabled after a 50 millisecond delay. This code has been removed and is not >>>> taken care of in the generic panel driver. The impact of this needs to be >>>> tested. The panel's gpios are also not exported any more. Hence, they >>>> can't be >>>> accessed via sysfs interface. >>> >>> Indeed, there is an impact - the LCD no longer works. >>> The reason for the LCD_EN gpio being pushed high after the 50ms delay, >>> is to get the LCD out of reset, so the SPI transaction will succeed >>> and initialize the LCD. >>> Now, when you remove the gpio handling for the LCD_EN pin, >>> the LCD no longer works. >> >> So between what is the sleep done? It's not clear from the code. LCD_EN >> needs to be 0 for 50ms, or...? >> >> If the panel requires specific reset handling, does it work right even >> currently when the panel is turned off and later turned on? The msleep >> is only used at boot time. > > Okay, so I just realized there's an spi backlight driver used here, and > that backlight driver is actually handling the SPI transactions with the > panel, instead of the panel driver. So this looks quite messed up. Yep, it always was. The whole DSS specific panel handling inside the drivers/video/omap2/displays is a mess. Those panels can be (and are) used not only with OMAP based boards. > > For a quick solution, can we just set the LCD_EN at boot time (with the > msleep), and not touch it after that? That would be sensible for now, so this series can be merged. As a more appropriate (and long term) solution, I plan on moving the panel reset pin handling to the spi backlight driver itself. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHIqCAAoJEBDE8YO64Efamw0P/R2wt0tpCI1ecrnutVGMX4bF Pyjk2B65uDWqoqZ/cpJUqnvmupXl5UdrA7eqKjTBh1A+g81UVFcNDMuJsbPIIiYI 1pimZieAq0T6Vag00PKImKlkhJYfC7JVBbESij/NONlzYtPkbZ91Y+Ik4DZXnyZf 1TS4GbHQ25tjl73PkwlzLUcJIDIogsimSrkM+aWXPE8LmvrBEQs0LhAObPsAFtgL 1An3hvA2Tkhh9QgerWQd9YiqX994tv1PGRLBEXTbjh1yihzKSNleuvw3NdM+wf9i 9Y5l9IV6L2dtYBMLCpzkiGQBDdOzoq+fObRnSgK6Kr1mfXot+MAlLrk9gCeWcq1b c2oU/imKWB4sZys21pTnjIxAIzzRDoGW40qXuibTW4DoAYaVHuEBPtphjMVCBCcQ sJaIVXpsChQ3vvtHOgllnInMjCnlXJ3Piqr4y5glTPxu9mZHdPr6VDpWdqRmvyr9 V7fRQztwXB3Td+SZVDD1yBqoXKlKCX4QPlLAqH3FI9s1WhDHcJePcoDJY0/QyXB1 IeQRlEwBBEZAYy/kr9/pwbZzXeh5V5dK6wAq8aT+thS22zl3nJbKjW//vN06+ib+ WAnHRSZ8iCbUX2cRVF1k+DCQOTi8QCbI6WTcLsgenLeSrbEuzilfgsrsvd6LHfjD oTODiiD9QInP2sBfknUp =tWsB -END PGP SIGNATURE- -- 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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling
Hi Archit,
On 02/13/13 16:21, Archit Taneja wrote:
> The cm-t35 board file currently requests gpios required to configure the
> tdo35s
> panel, and provides platform_enable/disable callbacks to configure them.
>
> These tasks have been moved to the generic dpi panel driver itself and
> shouldn't
> be done in the board files.
>
> Remove the gpio requests and the platform callbacks from the board file.
> Add the gpio information to generic dpi panel's platform data so that it's
> passed to the panel driver.
>
> Note: In cm_t35_init_display(), the gpios were disabled, and the LCD_EN gpio
> was
> enabled after a 50 millisecond delay. This code has been removed and is not
> taken care of in the generic panel driver. The impact of this needs to be
> tested. The panel's gpios are also not exported any more. Hence, they can't be
> accessed via sysfs interface.
Indeed, there is an impact - the LCD no longer works.
The reason for the LCD_EN gpio being pushed high after the 50ms delay,
is to get the LCD out of reset, so the SPI transaction will succeed
and initialize the LCD.
Now, when you remove the gpio handling for the LCD_EN pin,
the LCD no longer works.
I don't agree with this breakage.
>
> Cc: Tony Lindgren
> Signed-off-by: Archit Taneja
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 46
>
> 1 file changed, 5 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t35.c
> b/arch/arm/mach-omap2/board-cm-t35.c
> index f940a79..563d5ab 100644
> --- a/arch/arm/mach-omap2/board-cm-t35.c
> +++ b/arch/arm/mach-omap2/board-cm-t35.c
> @@ -189,32 +189,6 @@ static inline void cm_t35_init_nand(void) {}
> #define CM_T35_LCD_BL_GPIO 58
> #define CM_T35_DVI_EN_GPIO 54
>
> -static int lcd_enabled;
> -static int dvi_enabled;
> -
> -static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
> -{
> - if (dvi_enabled) {
> - printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
> - return -EINVAL;
> - }
> -
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
> -
> - lcd_enabled = 1;
> -
> - return 0;
> -}
> -
> -static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
> -{
> - lcd_enabled = 0;
> -
> - gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
> -}
> -
> static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
> {
> return 0;
> @@ -226,8 +200,11 @@ static void cm_t35_panel_disable_tv(struct
> omap_dss_device *dssdev)
>
> static struct panel_generic_dpi_data lcd_panel = {
> .name = "toppoly_tdo35s",
> - .platform_enable= cm_t35_panel_enable_lcd,
> - .platform_disable = cm_t35_panel_disable_lcd,
> + .num_gpios = 2,
> + .gpios = {
> + CM_T35_LCD_BL_GPIO,
> + CM_T35_LCD_EN_GPIO
> + },
> };
>
> static struct omap_dss_device cm_t35_lcd_device = {
> @@ -303,19 +280,6 @@ static void __init cm_t35_init_display(void)
> spi_register_board_info(cm_t35_lcd_spi_board_info,
> ARRAY_SIZE(cm_t35_lcd_spi_board_info));
>
> - err = gpio_request_array(cm_t35_dss_gpios,
> - ARRAY_SIZE(cm_t35_dss_gpios));
> - if (err) {
> - pr_err("CM-T35: failed to request DSS control GPIOs\n");
> - return;
> - }
> -
> - gpio_export(CM_T35_LCD_EN_GPIO, 0);
> - gpio_export(CM_T35_LCD_BL_GPIO, 0);
> -
> - msleep(50);
> - gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
> -
> err = omap_display_init(&cm_t35_dss_data);
> if (err) {
> pr_err("CM-T35: failed to register DSS device\n");
>
--
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: [PATCH V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/05/13 18:49, Jon Hunter wrote:
>
> On 02/05/2013 02:39 AM, Igor Grinberg wrote:
[...]
>>
>> Hmmm...
>> Do I miss something or you have forgot to update the commit message?
>
> Ugh you are right :-(
>
> Some how yesterday when rebasing the series and adding a couple more
> patches, I royally screwed it up. How about the following ...
Yep, that should do.
Thanks!
>
> Cheers
> Jon
>
>>From c82699e94d0255b3b1524e0d5ff4fd1f5852de69 Mon Sep 17 00:00:00 2001
> From: Jon Hunter
> Date: Mon, 28 Jan 2013 17:53:57 -0600
> Subject: [PATCH] ARM: OMAP3: Update clocksource timer selection
>
> When booting with device-tree for OMAP3 and AM335x devices and a gptimer
> is used as the clocksource (which is always the case for AM335x), a
> gptimer located in a power domain that is not always-on is selected.
> Ideally we should use a gptimer for clocksource that is located in a
> power domain that is always on (such as the wake-up domain) so that time
> can be maintained during a kernel suspend without keeping on additional
> power domains unnecessarily.
>
> In order to fix this so that we can select a gptimer located in a power
> domain that is always-on, the following changes were made ...
> 1. Currently, only when selecting a gptimer to use for a clockevent
>timer, do we pass a timer property that can be used to select a
>specific gptimer. Change this so that we can pass a property when
>selecting a gptimer to use for a clocksource timer too.
> 2. Currently, when selecting either a gptimer to use for a clockevent
>timer or a clocksource timer and no timer property is passed, then
>the first available timer is selected regardless of the properties
>it has. Change this so that if no properties are passed, then a timer
>that does not have additional features (such as always-on, dsp-irq,
>pwm, and secure) is selected.
>
> For OMAP3 and AM335x devices that use a gptimer for clocksource, change
> the selection of the gptimer so that by default the gptimer located in
> the always-on power domain is used for clocksource instead of
> clockevents.
>
> Please note that using a gptimer for both clocksource and clockevents
> can have a system power impact during idle. The reason being is that
> OMAP and AMxxx devices typically only have one gptimer in a power domain
> that is always-on. Therefore when the kernel is idle both the clocksource
> and clockevent timers will be active and this will keep additional power
> domains on. During kernel suspend, only the clocksource timer is active
> and therefore, it is better to use a gptimer in a power domain that is
> always-on for clocksource.
>
> Signed-off-by: Jon Hunter
> Acked-by: Santosh Shilimkar
> Acked-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/timer.c | 33 +
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 3ad9a3b..fce495e 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -160,6 +160,12 @@ static struct device_node * __init
> omap_get_timer_dt(struct of_device_id *match,
> if (property && !of_get_property(np, property, NULL))
> continue;
>
> + if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
> + of_get_property(np, "ti,timer-dsp", NULL) ||
> + of_get_property(np, "ti,timer-pwm", NULL) ||
> + of_get_property(np, "ti,timer-secure", NULL)))
> + continue;
> +
> of_add_property(np, &device_disabled);
> return np;
> }
> @@ -435,13 +441,14 @@ static int __init __maybe_unused
> omap2_sync32k_clocksource_init(void)
> }
>
> static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> - const char *fck_source)
> + const char *fck_source,
> + const char *property)
> {
> int res;
>
> clksrc.errata = omap_dm_timer_get_errata();
>
> - res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
> + res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, property,
>&clocksource_gpt.name,
>OMAP_TIMER_NONPOSTED);
> BUG_ON(res);
> @@ -538,47 +545,49 @@ static inline void __init realtime_counter_init(void)
> #endif
>
> #define OMAP_SYS
Re: [PATCH V3 5/7] ARM: OMAP3: Update clocksource timer selection
On 02/04/13 21:46, Jon Hunter wrote: > When booting with device-tree for OMAP3 and AM335x devices and a gptimer > is used as the clocksource (which is always the case for AM335x), a > gptimer located in a power domain that is not always-on is selected. > Ideally we should use a gptimer located in a power domain that is always > on (such as the wake-up domain) so that time can be maintained during a > kernel suspend without keeping on additional power domains unnecessarily. > > In order to fix this so that we can select a gptimer located in a power > domain that is always-on, the following changes were made ... > 1. Currently, only when selecting a gptimer to use for a clockevent >timer, do we pass a timer property that can be used to select a >specific gptimer. Change this so that we can pass a property when >selecting a gptimer to use for a clocksource timer too. > 2. Currently, when selecting either a gptimer to use for a clockevent >timer or a clocksource timer and no timer property is passed, then >the first available timer is selected regardless of the properties >it has. Change this so that if no properties are passed, then a timer >that does not have additional features (such as always-on, dsp-irq, >pwm, and secure) is selected. > > Please note that using a gptimer for both clocksource and clockevents > can have a system power impact during idle. The reason being is that > OMAP and AMxxx devices typically only have one gptimer in a power domain > that is always-on. Therefore when the kernel is idle both the clocksource > and clockevent timers will be active and this will keep additional power > domains on. During kernel suspend, only the clocksource timer is active > and therefore, it is better to use a gptimer in a power domain that is > always-on for clocksource. Hmmm... Do I miss something or you have forgot to update the commit message? > > Signed-off-by: Jon Hunter > --- > arch/arm/mach-omap2/timer.c | 33 + > 1 file changed, 21 insertions(+), 12 deletions(-) [...] > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", > -2, "timer_sys_ck"); > +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, > +1, "timer_sys_ck", "ti,timer-alwon"); > #endif [...] -- 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: [PATCH] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ
On 01/31/13 17:32, Santosh Shilimkar wrote: > The timekeeping doesn't depend on HZ value in presence of fine grained > clocksource and hence there should not be any time drift because of HZ > value which was chosen to be divisor of 32768. > > OMAP has been using HZ = 128 value to avoid any time drift issues > because of 32768 HZ clock. But with various measurements performed > with HZ = 100, no time drift is observed and it also proves the > point about HZ not having impact on time keeping on OMAP. Great! I had the same patch in my tree already for several months, but I was afraid to send it as I had no time to test it thoroughly. These kind of things are always scary to send without proper testing... Thank you very much for testing and sending this out! > > Very informative thread on this topic is here: > https://lkml.org/lkml/2013/1/29/435 > > Special thanks to John Stulz, Arnd Bergmann and Russell King for their > valuable suggestions. > > Cc: Arnd Bergmann > Cc: Russell King > Cc: John Stultz > Cc: Tony Lindgren If it still not too late: Acked-by: Igor Grinberg > > Signed-off-by: Santosh Shilimkar > Tested-by: Lokesh Vutla > --- > arch/arm/Kconfig|1 - > arch/arm/plat-omap/Kconfig |9 - > arch/arm/plat-omap/include/plat/timex.h |8 > 3 files changed, 18 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index b35b27f..5493164 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1648,7 +1648,6 @@ config HZ > int > default 200 if ARCH_EBSA110 || ARCH_S3C24XX || ARCH_S5P64X0 || \ > ARCH_S5PV210 || ARCH_EXYNOS4 > - default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER > default AT91_TIMER_HZ if ARCH_AT91 > default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE > default 100 > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index 67c859c..ce66eb9 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -147,15 +147,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID > help > PPA routine service ID for setting L2 auxiliary control register. > > -config OMAP_32K_TIMER_HZ > - int "Kernel internal timer frequency for 32KHz timer" > - range 32 1024 > - depends on OMAP_32K_TIMER > - default "128" > - help > - Kernel internal timer frequency should be a divisor of 32768, > - such as 64 or 128. > - > config OMAP_DM_TIMER > bool "Use dual-mode timer" > depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS > diff --git a/arch/arm/plat-omap/include/plat/timex.h > b/arch/arm/plat-omap/include/plat/timex.h > index 6d35767..e27d2da 100644 > --- a/arch/arm/plat-omap/include/plat/timex.h > +++ b/arch/arm/plat-omap/include/plat/timex.h > @@ -28,14 +28,6 @@ > #if !defined(__ASM_ARCH_OMAP_TIMEX_H) > #define __ASM_ARCH_OMAP_TIMEX_H > > -/* > - * OMAP 32KHz timer updates time one jiffie at a time from a secondary timer, > - * and that's why the CLOCK_TICK_RATE is not 32768. > - */ > -#ifdef CONFIG_OMAP_32K_TIMER > -#define CLOCK_TICK_RATE (CONFIG_OMAP_32K_TIMER_HZ) > -#else > #define CLOCK_TICK_RATE (HZ * 10UL) > -#endif > > #endif /* __ASM_ARCH_OMAP_TIMEX_H */ > -- 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: [PATCH 4/5] ARM: OMAP2+: Simplify system timers definitions
On 01/30/13 19:04, Jon Hunter wrote: > There is a lot of redundancy in the definitions for the various system > timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init() > function is the same as the omap3_gp_gptimer_timer_init() function and the > function omap2_sync32k_timer_init() can be re-used for OMAP4/5 devices. > Therefore, consolidate the definitions to simplify the code. > > Signed-off-by: Jon Hunter Acked-by: Igor Grinberg -- 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: [PATCH 5/5] ARM: OMAP3: Update clocksource timer selection
On 01/30/13 19:04, Jon Hunter wrote: > When booting with device-tree for OMAP3 and AM335x devices and a gptimer > is used as the clocksource (which is always the case for AM335x), a > gptimer located in a power domain that is not always-on is selected. > Ideally we should use a gptimer located in a power domain that is always > on (such as the wake-up domain) so that time can be maintained during a > kernel suspend without keeping on additional power domains unnecessarily. > > In order to fix this so that we can select a gptimer located in a power > domain that is always-on, the following changes were made ... > 1. Currently, only when selecting a gptimer to use for a clockevent >timer, do we pass a timer property that can be used to select a >specific gptimer. Change this so that we can pass a property when >selecting a gptimer to use for a clocksource timer too. > 2. Currently, when selecting either a gptimer to use for a clockevent >timer or a clocksource timer and no timer property is passed, then >the first available timer is selected regardless of the properties >it has. Change this so that if no properties are passed, then a timer >that does not have additional features (such as always-on, dsp-irq, >pwm, and secure) is selected. > > Please note that using a gptimer for both clocksource and clockevents > can have a system power impact during idle. The reason being is that > OMAP and AMxxx devices typically only have one gptimer in a power domain > that is always-on. Therefore when the kernel is idle both the clocksource > and clockevent timers will be active and this will keep additional power > domains on. During kernel suspend, only the clocksource timer is active > and therefore, it is better to use a gptimer in a power domain that is > always-on for clocksource. This should explain the gptimer number switch in the #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) section below, right? I would really like to see that clearly stated in the commit message. For instance: ... it is better to use a gptimer in a power domain that is always-on for clocksource. Therefore we switch to use the first gptimer for clocksource and the second for clockevents. > > Signed-off-by: Jon Hunter Apart from above, Acked-by: Igor Grinberg > --- > arch/arm/mach-omap2/timer.c | 32 +--- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c > index af20be7..acf9f82 100644 > --- a/arch/arm/mach-omap2/timer.c > +++ b/arch/arm/mach-omap2/timer.c [...] > @@ -557,19 +567,19 @@ void __init omap##name##_sync32k_timer_init(void) > \ > #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP4) || > \ > defined(CONFIG_SOC_OMAP5) > OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > #endif > > #ifdef CONFIG_ARCH_OMAP3 > OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure", > - 2, "timer_sys_ck"); > + 2, "timer_sys_ck", NULL); > #endif /* CONFIG_ARCH_OMAP3 */ > > #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) > -OMAP_SYS_GP_TIMER_INIT(3, 1, "timer_sys_ck", "ti,timer-alwon", > -2, "timer_sys_ck"); > +OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL, > +1, "timer_sys_ck", "ti,timer-alwon"); > #endif > > #ifdef CONFIG_ARCH_OMAP4 > -- 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: [PATCH v2] ARM: OMAP3: cm-t3517: add MMC support
ping!
It has been 1.5 month and we are at rc4 already...
On 01/02/13 09:16, Igor Grinberg wrote:
> ping
>
> Hi Tony,
>
> This is a really small addition to improve Paul's tests coverage.
> Can this go into 3.9?
>
> Thanks
>
> On 12/07/12 11:05, Igor Grinberg wrote:
>> cm-t3517 uses two MMC interfaces. Add support for both.
>>
>> Signed-off-by: Igor Grinberg
>> ---
>> v2: Use CONFIG_MMC_OMAP_HS instead of plain CONFIG_MMC, so it will be stubbed
>> out with the same defines as omap_hsmmc_init() function.
>> Fix the !CONFIG_MMC_OMAP_HS case.
>>
>> arch/arm/mach-omap2/board-cm-t3517.c | 27 +++
>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
>> b/arch/arm/mach-omap2/board-cm-t3517.c
>> index ebbc2ad..792d684 100644
>> --- a/arch/arm/mach-omap2/board-cm-t3517.c
>> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
>> @@ -32,6 +32,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -46,6 +47,7 @@
>>
>> #include "mux.h"
>> #include "control.h"
>> +#include "hsmmc.h"
>> #include "common-board-devices.h"
>> #include "am35xx-emac.h"
>> #include "gpmc-nand.h"
>> @@ -121,6 +123,26 @@ static void cm_t3517_init_hecc(void)
>> static inline void cm_t3517_init_hecc(void) {}
>> #endif
>>
>> +#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
>> +static struct omap2_hsmmc_info cm_t3517_mmc[] = {
>> +{
>> +.mmc= 1,
>> +.caps = MMC_CAP_4_BIT_DATA,
>> +.gpio_cd= 144,
>> +.gpio_wp= 59,
>> +},
>> +{
>> +.mmc= 2,
>> +.caps = MMC_CAP_4_BIT_DATA,
>> +.gpio_cd= -EINVAL,
>> +.gpio_wp= -EINVAL,
>> +},
>> +{} /* Terminator */
>> +};
>> +#else
>> +#define cm_t3517_mmc NULL
>> +#endif
>> +
>> #if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
>> #define RTC_IO_GPIO (153)
>> #define RTC_WR_GPIO (154)
>> @@ -271,6 +293,10 @@ static struct omap_board_mux board_mux[] __initdata = {
>> /* CM-T3517 USB HUB nRESET */
>> OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
>>
>> +/* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
>> +OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
>> +OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
>> +
>> { .reg_offset = OMAP_MUX_TERMINATOR },
>> };
>> #endif
>> @@ -286,6 +312,7 @@ static void __init cm_t3517_init(void)
>> cm_t3517_init_usbh();
>> cm_t3517_init_hecc();
>> am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
>> +omap_hsmmc_init(cm_t3517_mmc);
>> }
>>
>> MACHINE_START(CM_T3517, "Compulab CM-T3517")
>
--
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: [PATCH] usb: musb: fix context save over suspend.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like Kevin has a new address: Kevin Hilman On 01/21/13 23:38, NeilBrown wrote: > On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > >> Hi Neil, > >> On 01/21/13 11:28, NeilBrown wrote: >>> >>> >>> The standard suspend sequence involves runtime_resuming >>> devices before suspending the system. >>> So just saving context in runtime_suspend and restoring it >>> in runtime resume isn't enough. We must also save in "suspend" >>> and restore in "resume". >>> >>> Without this patch, and OMAP3 system with off_mode enabled will find >>> the musb port non-functional after suspend/resume. With the patch it >>> works perfectly. > >> Hmmm... Some time ago, this has been removed in >> 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) > >> Am I missing something? Or things changed and now this patch is correct? > > Hi Igor, > thanks for alerting me to that patch does anyone else get the feeling > that power management to too complex to be understood by a mere human? > > That commit (5d193ce8) suggests that the musb-hdrc device is an > 'omap_device', or maybe has a PM domain set to something else. > However it isn't/doesn't. dev->pm_domain is NULL. So no PM domain layer > will ever call the musb_core musb_runtime_suspend/resume. > > The parent device - musb-omap2430 - is an omap device, does have pm_domain > set, and does have its omap2430_runtime_suspend/resume called for system > suspend and so the context for that device is saved and restored. > However that doesn't help the context for musb-hdrc. > > Whether musb ever was an omap_device is beyond my archaeological skills to > determine. > > Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever > the various possible parents that had domains? > Are you able to defend your earlier patch in today's kernel? It > certainly causes my device not to work properly. > > Thanks, > NeilBrown > > > > >>> >>> Signed-off-by: NeilBrown >>> >>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c >>> index fd34867..b6ccc02 100644 >>> --- a/drivers/usb/musb/musb_core.c >>> +++ b/drivers/usb/musb/musb_core.c >>> @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) >>> } >>> >>> spin_unlock_irqrestore(&musb->lock, flags); >>> + musb_save_context(musb); >>> return 0; >>> } >>> >>> @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) >>> * unless for some reason the whole soc powered down or the USB >>> * module got reset through the PSC (vs just being disabled). >>> */ >>> + struct musb *musb = dev_to_musb(dev); >>> + musb_restore_context(musb); >>> return 0; >>> } >>> > >> - -- >> Regards, >> Igor. >> - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ/lgWAAoJEBDE8YO64EfacIAP/3nyXjs8QQpcD6RcNuRSLp3O veKU2grzsUOL/Eu/8TQMM7WDz5n8YlycQ6/THNGGYojjOlEimDC02wbsI4gc5j41 QC1/XGf62Nlxv6CzORzkGkUoKXtVWzgMYKddWKPEwsXMKPun/LH4ZGDp+7Rkfcmu U0k7LM1Pv487iG9pF3Bq5BPYeMxyxyFJC0PiQEK1ZE65RKWbCvInibc7p1bvZ+XX JQxf8Qx1p/kBhqWc6LLpcHT5Z3B/F+3rxEhvf8lSu5fdRPHFffcmuX7bIbC/GlTe e6mODA114mtn5YbaKCmnYExvJcpz4Nziy+8fGLJ56aAyeKI1wsOJzhWDpSKwQiIF CVtYulk5iIfaeUA4sAzvRqEu7dJuaVgm6mEeGHQjebPastYhK7vHjiEOJJ2+LQrs 698A9wMLckp4AQ75HiwXRgi5N0W528gD8piNoIA9Sh1LwyytIa5Wg7uYw14UjtLJ QIerm0v6Ay+8FbVfmpm9k0v3HkYfv0ZVTSdtIXVAE30+WKIBTn0yszxWYo6JZtvj p0NEFUNVuR3C9k/xyzkcqwJh8Q6DrleWJeHWL59xgWWKzfeDKjU/DMOuWmuVEkTO aRdAlW32VDtUeWlWz3Jz3IOWZRJQKCW2o97n/MDyxwMoRiMWcHxYw6jti6se9S7a IGZeEMCcf39fnH5o7i2q =nwGe -END PGP SIGNATURE- -- 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: musb: fix context save over suspend.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: > > > The standard suspend sequence involves runtime_resuming > devices before suspending the system. > So just saving context in runtime_suspend and restoring it > in runtime resume isn't enough. We must also save in "suspend" > and restore in "resume". > > Without this patch, and OMAP3 system with off_mode enabled will find > the musb port non-functional after suspend/resume. With the patch it > works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? > > Signed-off-by: NeilBrown > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index fd34867..b6ccc02 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) > } > > spin_unlock_irqrestore(&musb->lock, flags); > + musb_save_context(musb); > return 0; > } > > @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) >* unless for some reason the whole soc powered down or the USB >* module got reset through the PSC (vs just being disabled). >*/ > + struct musb *musb = dev_to_musb(dev); > + musb_restore_context(musb); > return 0; > } > - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ/SjTAAoJEBDE8YO64EfaHrsP/2bl4rP6L/tWLSZ+rNEdz6B+ Qo+HVOhnTVsOxgWbbd5VrfhE28jLoFGMslrLuI+geeCcJ1zgwNsahG9C11bygyfu 54hQgkmaxDJPDKAlalcy7VK9C6tOTgQV5iSbuRlemttK879dTrb+33zP6idn5+zK kxptY38fpmyojnl8gJiVa6Plik/apQcVr+GIx8CMwj+YQC5vkdg7cUEWyngfyk2C W0U4NceroS8NSjRbcFV3V6Q912TVjKzl+B2yxVD0OBaSK4BpHEncDBXiVx8APq87 4nDeBB5gDXi1rtN3YjcfDaFu0me5qzpYc3JFFidvdLTdXIdvxDzjHgMqsZB8ZBYC R0e5PtIw/62I90d63JkXZXVRTB7JeZsGfZFY2R7MxBab9or8zz0OyYwGWoW63vzH oFrwmAkWoD0IEKcfc8+dd99eicgZrmQL6FDWrEMsX+RS34LRtVU30SVAudRhY+CR MhNCjKyFySwx7wqkGgJl1ECl0Y6U4ua0v4bv7kdE6eyrgbQIkiGliSJ7DhWBPcP6 iMIOTwC7+LwPYP/MX2uYR3DXDfI0XwiqdtyzhD9LJe4PRol8zjozS2j0Y7FriItw jFqsgCgwDc9j8ufcpXf5ZynJYnlCG0iLuAPEUugZot83/CpxgU++A8cuHqUrOnhH 76L95rflUTkpiQ76ffP7 =jqXb -END PGP SIGNATURE- -- 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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 12:19, NeilBrown wrote: > On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 > >> On 01/16/13 09:26, NeilBrown wrote: >>> On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg >>> wrote: >>> >>>> On 01/09/13 14:08, Michael Trimarchi wrote: >>>>> Hi Neil >>>>> >>>>> I forget to answer to your questions >>>>> >>>>> On 01/09/2013 12:34 PM, NeilBrown wrote: >>>>>> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi >>>>>> wrote: >>>>>> >>>>>>> Hi Neil >>>>>>> >>>>>>> On 01/09/2013 11:19 AM, NeilBrown wrote: >>>>>>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> -BEGIN PGP SIGNED MESSAGE- >>>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>>> Hi Neil, >>>>>>>> >>>>>>>>> On 01/09/13 00:29, NeilBrown wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> I'm trying to get off_mode working reliably on my gta04 mobile >>>>>>>>>> phone. >>>>>>>>>> >>>>>>>>>> My current stumbling block is USB. The "Option" GSM module is >>>>>>>>>> attached via >>>>>>>>>> USB (there is a separate transceiver chip attached to port 1 which >>>>>>>>>> is placed >>>>>>>>>> in OMAP_EHCI_PORT_MODE_PHY). >>>>>>>> >>>>>>>>> Which PHY is this (vendor/model)? >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> it is the SMSC USB3322 >>>>>>>> >>>>>>>> http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf >>>>>>>> >>>>>>>> >>>>>>>> BTW I subsequently discovered that keeping USBHOST out off off_mode >>>>>>>> only >>>>>>>> sometimes avoid the problem, not always. So there are probably >>>>>>>> multiple >>>>>>>> issues :-( >>>> >>>> We have the same PHY and it has some issues with the OMAP USB code. >>>> First issue we experience is that if we reset the PHY more then once >>>> w/o power cycling it, the PHY dies until next power cycle. >>>> So, we stop providing the reset GPIO to the usb code and do the reset >>>> in the board code. >>> >>> I've tried various change w.r.t the resetting and I cannot fault it. >>> Resetting or not resetting neither causes a problem while the USB is >>> otherwise working, not fixed the USB while it is otherwise failing. >>> So I don't think this is my problem - thanks. >>> >>>> >>>>>>> >>>>>>> Are you sure that you don't have glitch on power, reset pin during >>>>>>> suspend? >>>>>>> >>>>>> >>>>>> No, I don't really have the equipment to measure such things. >>>>>> But is it likely? Would enabling off_mode make it more likely? >>>>> >>>>> I don't know the reason of the off_mode problem :( >>>> >>>> We have the equipment to check this and no - this is not the case. >>>> >>>>> >>>>>> Can you suggest some way I could test the hypothesis? >>>>> >>>>> I had the same problem on a rugged mobile phone, so it is just experience >>>>> Check the modem power and reset gpio too, but if you don't need to >>>>> unblock it >>>>> with the pin after resume we know that modem is not the problem >>>> >>>> I don't think modem is the problem... >>>> We have plain USB connector ports that are dead after the resume from >>>> off-mode. >>>> >>>> The good news are that we have the off-mode working on v3.6.1, >>>> including the USB, but we had to do some horrible ugly hacking for this
Re: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/13 09:26, NeilBrown wrote: > On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg > wrote: > >> On 01/09/13 14:08, Michael Trimarchi wrote: >>> Hi Neil >>> >>> I forget to answer to your questions >>> >>> On 01/09/2013 12:34 PM, NeilBrown wrote: >>>> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi >>>> wrote: >>>> >>>>> Hi Neil >>>>> >>>>> On 01/09/2013 11:19 AM, NeilBrown wrote: >>>>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg >>>>>> >>>>>> wrote: >>>>>> >>>>>>> -BEGIN PGP SIGNED MESSAGE- >>>>>>> Hash: SHA1 >>>>>> >>>>>>> Hi Neil, >>>>>> >>>>>>> On 01/09/13 00:29, NeilBrown wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I'm trying to get off_mode working reliably on my gta04 mobile phone. >>>>>>>> >>>>>>>> My current stumbling block is USB. The "Option" GSM module is >>>>>>>> attached via >>>>>>>> USB (there is a separate transceiver chip attached to port 1 which is >>>>>>>> placed >>>>>>>> in OMAP_EHCI_PORT_MODE_PHY). >>>>>> >>>>>>> Which PHY is this (vendor/model)? >>>>>> >>>>>> Hi Igor, >>>>>> it is the SMSC USB3322 >>>>>> >>>>>> http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf >>>>>> >>>>>> >>>>>> BTW I subsequently discovered that keeping USBHOST out off off_mode only >>>>>> sometimes avoid the problem, not always. So there are probably multiple >>>>>> issues :-( >> >> We have the same PHY and it has some issues with the OMAP USB code. >> First issue we experience is that if we reset the PHY more then once >> w/o power cycling it, the PHY dies until next power cycle. >> So, we stop providing the reset GPIO to the usb code and do the reset >> in the board code. > > I've tried various change w.r.t the resetting and I cannot fault it. > Resetting or not resetting neither causes a problem while the USB is > otherwise working, not fixed the USB while it is otherwise failing. > So I don't think this is my problem - thanks. > >> >>>>> >>>>> Are you sure that you don't have glitch on power, reset pin during >>>>> suspend? >>>>> >>>> >>>> No, I don't really have the equipment to measure such things. >>>> But is it likely? Would enabling off_mode make it more likely? >>> >>> I don't know the reason of the off_mode problem :( >> >> We have the equipment to check this and no - this is not the case. >> >>> >>>> Can you suggest some way I could test the hypothesis? >>> >>> I had the same problem on a rugged mobile phone, so it is just experience >>> Check the modem power and reset gpio too, but if you don't need to unblock >>> it >>> with the pin after resume we know that modem is not the problem >> >> I don't think modem is the problem... >> We have plain USB connector ports that are dead after the resume from >> off-mode. >> >> The good news are that we have the off-mode working on v3.6.1, >> including the USB, but we had to do some horrible ugly hacking for this. >> > > I assume this means "some patches on top of 3.6.1" ?? > Care to share your code? Even horribly ugly hacks can be educational. We are not ready to share these patches (this will happen eventually after some work is finished), but I can explain what they do... We split the ehci_run function to separate the debugfs and sysfs stuff from other initializations, so we can run the new version without the debugfs and sysfs stuff multiple times. Then we implement the suspend/resume ehci callbacks: on suspend, assert phy reset, on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to EHCI_INSNREG04, and call the new ehci_run() function. That does the job for USB host to resume from off mode. - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ9nKiAAoJEBDE8YO64Efa7U4QAKFXRyyNR5Q7jjwVG6UwITWq 6kJyNXJKQTqn6GLEV7xJmT4SZAtxq+dRDl/XE9dcXFK3RTebttXxyVz1X0vXZQud h6QLenH8jHczNubfn6CTLI38PKprl1F2zpZtjKpHfNmD5cLWzJ1EIoTH19ENsJ4v zV3KI3RgiFuq02vxOULtp9gP/x0WZSHwBEGm/ToqqsEaX7wAJc2BDFOSS8NpSGbb VLPFA1doMrFOYkL+oMS2IVudM0wEYCBGhGxMi/Y++RY1omlonhEGCoVxaxzGoHrk H/ZpxFheIGBKwo+VX1eSgW9oQZyzbPZttyEWXXNCRh/6oejXCBSS3zkKrWrctmVD ONu1gzoaC9p/c1n2GDioIfxC41dPKdjCETMbTi9rR5shc12ZmwtrgUOU80mpzWj3 6fY+TRW4x8qYbsFL89T6TWGpDz7JrBdtdJiBD/TPtJW05ikn9DTL5/GNVjeeoRk0 5DJ06pHh+rQFKThEvoDdLAH3PZdtDVSdXnAg+gF4D7/BMZ14TLHmW2l471I95S2I eKxZxIwFa2IscTbGKhTlrdPF4UShEvLuFgO6NCb1ea1FT7m3ih8rwA5ObI4676DG Y5kokqi9dpzMB/6T/SDk/gySTg9WUDXFlhS6x/b89f1xC71GzGTJkkqqH4u6KfX8 GcqI3wEFlqpG4FM39XAw =nynZ -END PGP SIGNATURE- -- 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: Help wanted with USB and OMAP3 off_mode
On 01/09/13 14:08, Michael Trimarchi wrote: > Hi Neil > > I forget to answer to your questions > > On 01/09/2013 12:34 PM, NeilBrown wrote: >> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi >> wrote: >> >>> Hi Neil >>> >>> On 01/09/2013 11:19 AM, NeilBrown wrote: >>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg >>>> wrote: >>>> >>>>> -BEGIN PGP SIGNED MESSAGE- >>>>> Hash: SHA1 >>>> >>>>> Hi Neil, >>>> >>>>> On 01/09/13 00:29, NeilBrown wrote: >>>>>> >>>>>> Hi, >>>>>> I'm trying to get off_mode working reliably on my gta04 mobile phone. >>>>>> >>>>>> My current stumbling block is USB. The "Option" GSM module is attached >>>>>> via >>>>>> USB (there is a separate transceiver chip attached to port 1 which is >>>>>> placed >>>>>> in OMAP_EHCI_PORT_MODE_PHY). >>>> >>>>> Which PHY is this (vendor/model)? >>>> >>>> Hi Igor, >>>> it is the SMSC USB3322 >>>> >>>> http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf >>>> >>>> >>>> BTW I subsequently discovered that keeping USBHOST out off off_mode only >>>> sometimes avoid the problem, not always. So there are probably multiple >>>> issues :-( We have the same PHY and it has some issues with the OMAP USB code. First issue we experience is that if we reset the PHY more then once w/o power cycling it, the PHY dies until next power cycle. So, we stop providing the reset GPIO to the usb code and do the reset in the board code. >>> >>> Are you sure that you don't have glitch on power, reset pin during suspend? >>> >> >> No, I don't really have the equipment to measure such things. >> But is it likely? Would enabling off_mode make it more likely? > > I don't know the reason of the off_mode problem :( We have the equipment to check this and no - this is not the case. > >> Can you suggest some way I could test the hypothesis? > > I had the same problem on a rugged mobile phone, so it is just experience > Check the modem power and reset gpio too, but if you don't need to unblock it > with the pin after resume we know that modem is not the problem I don't think modem is the problem... We have plain USB connector ports that are dead after the resume from off-mode. The good news are that we have the off-mode working on v3.6.1, including the USB, but we had to do some horrible ugly hacking for 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: Help wanted with USB and OMAP3 off_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/09/13 00:29, NeilBrown wrote:
>
> Hi,
> I'm trying to get off_mode working reliably on my gta04 mobile phone.
>
> My current stumbling block is USB. The "Option" GSM module is attached via
> USB (there is a separate transceiver chip attached to port 1 which is placed
> in OMAP_EHCI_PORT_MODE_PHY).
Which PHY is this (vendor/model)?
>
> After a suspend/resume cycle with off_mode enabled the GSM module disappears.
> i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
> exist.
> Without off mode, the modem always appears after resume.
>
> I discovered that the registers set by:
>
>drivers/mfd/omap-usb-host.c
>
> are not maintained across as suspend/resume so I added the following patch
> (which I can make a formal submission of if it looks right to others), but
> that didn't help (or didn't help enough).
>
> If I
>
> echo 1 > /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
>
> thus keeping just the USBHOST power domain out of off_mode, the GSM module
> doesn't disappear. So it seems that some context in the usbhost domain is
> not being save and restored.
>
> This is as far as I can get. Can someone suggest where I should look to find
> out what is not being saved/restored properly, and how to go about saving and
> restoring?
>
> Thanks in advance,
> NeilBrown
>
>
>
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 23cec57..522405e 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
>
> void __iomem*uhh_base;
>
> + struct {
> + unsignedhostconfig;
> + } context;
> +
> struct usbhs_omap_platform_data platdata;
>
> u32 usbhs_rev;
> @@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
> clk_enable(omap->utmi_p1_fck);
> clk_enable(omap->utmi_p2_fck);
>
> + usbhs_write(omap->uhh_base,
> + OMAP_UHH_HOSTCONFIG,
> + omap->context.hostconfig);
> +
> spin_unlock_irqrestore(&omap->lock, flags);
>
> return 0;
> @@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
> }
>
> spin_lock_irqsave(&omap->lock, flags);
> + omap->context.hostconfig = usbhs_read(omap->uhh_base,
> + OMAP_UHH_HOSTCONFIG);
>
> if (is_ehci_tll_mode(pdata->port_mode[0]))
> clk_disable(omap->usbhost_p1_fck);
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQ7T+kAAoJEBDE8YO64Efaj8YQAI5nOE9vvf8wxbu5IXTxaMxn
6B+g2m/zkMlyVNL5hTrwkPkP4CTBwvsGCZYkZT5JS3KM+R+TuyIX07+eM59Ie0Po
u1CCn2XKZY2CP53b3nAtgk9Phxwruf5fDjEu9QiQapdUpbiTWmIn8W3CVye241O2
wXBKAXszX1bD81NFNY+Jm5Us5uGHNTtNtqe78Rng7BTvmaaNgE61PurFclgn0xQb
IO5E7eyq7TG1u/IBhge2jlZGx2BbLcVsrQI3WyuE2L6F+MRgAKBDD7K8uHTfxPyM
eXAk/u5tbA21t1mTIXk19N4c0YVgeFW2kKQOPShKywy9J6k3tE5LE4yUjooo4ZeS
TlIf7HFcp15N3FfX90FOYsQOXILnoNL6a8SOK3gU+iVxZU/4VohKOXBlMjuZ7o10
5FnglPaHjsEaa1DgB/FcnYh3OO33mODJsckUhi5GiIlrbm70JspfWShZfln1k8FS
SwClmyb6FCiqBOcRJ2uS1KTwObzYV9WeuPGCTXC5d4UBB57eRcGcX/NvSftV57mX
jcSEle93kgZx1EiG53Vwd29oV9nU6SJECF7Q8CqulDEQVr76E7Xh8Z1CrsD+BhKe
XuFa3zdtMg1SZO/ctcTIPPpElCVPF1FChX2lY9fCIdK2luHNrOs4GyrozCGXQcXO
ZMFiiStsjr021CGqQUFw
=yIA2
-END PGP SIGNATURE-
--
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 1/1] arm :omap :DMA: fix a bug on reserving the omap SDMA channels
On 01/03/13 10:38, Santosh Shilimkar wrote: > On Thursday 03 January 2013 12:58 PM, R Sricharan wrote: >> Hi, >> >> On Sunday 30 December 2012 02:13 AM, ahema...@gmail.com wrote: >>> From: ahemaily >>> >>> The variable dma_lch_count used for comparison >>> (omap_dma_reserve_channels <= dma_lch_count) >>> before it initialized to the value from omap_dma_dev_attr : d->lch_count. >>> >>> I change the place of dma_lch_count initialization to be before the >>> comparison. >>> >>> Signed-off-by: Abdelrahman Hemaily >>> --- >>> arch/arm/plat-omap/dma.c |4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c >>> index c76ed8b..cb3e321 100644 >>> --- a/arch/arm/plat-omap/dma.c >>> +++ b/arch/arm/plat-omap/dma.c >>> @@ -2014,12 +2014,12 @@ static int __devinit >>> omap_system_dma_probe(struct platform_device *pdev) >>> >>> d= p->dma_attr; >>> errata= p->errata; >>> - >>> +dma_lch_count = d->lch_count; >>> + >>> if ((d->dev_caps & RESERVE_CHANNEL) && omap_dma_reserve_channels >>> && (omap_dma_reserve_channels <= dma_lch_count)) >>> d->lch_count= omap_dma_reserve_channels; >>> >>> -dma_lch_count= d->lch_count; >> By removing this line, you are effectively not assigning >> d->lch_count after reserving. So the patch should only change >> dma_lch_count in the above "if statement" to d->lch_count >> > You are right. I missed it in last review. Below should be enough. > > diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c > index 37a488a..555ff7b 100644 > --- a/arch/arm/plat-omap/dma.c > +++ b/arch/arm/plat-omap/dma.c > @@ -2019,7 +2019,7 @@ static int __devinit omap_system_dma_probe(struct > platform_device *pdev) > errata= p->errata; > > if ((d->dev_caps & RESERVE_CHANNEL) && omap_dma_reserve_channels > -&& (omap_dma_reserve_channels <= dma_lch_count)) > +&& (omap_dma_reserve_channels <= d->lch_coun)) It looks like the 't' is missing... ^ > d->lch_count= omap_dma_reserve_channels; > > dma_lch_count= d->lch_count; > -- > 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 > -- 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: [PATCH v2] ARM: OMAP3: cm-t3517: add MMC support
ping
Hi Tony,
This is a really small addition to improve Paul's tests coverage.
Can this go into 3.9?
Thanks
On 12/07/12 11:05, Igor Grinberg wrote:
> cm-t3517 uses two MMC interfaces. Add support for both.
>
> Signed-off-by: Igor Grinberg
> ---
> v2: Use CONFIG_MMC_OMAP_HS instead of plain CONFIG_MMC, so it will be stubbed
> out with the same defines as omap_hsmmc_init() function.
> Fix the !CONFIG_MMC_OMAP_HS case.
>
> arch/arm/mach-omap2/board-cm-t3517.c | 27 +++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
> b/arch/arm/mach-omap2/board-cm-t3517.c
> index ebbc2ad..792d684 100644
> --- a/arch/arm/mach-omap2/board-cm-t3517.c
> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -46,6 +47,7 @@
>
> #include "mux.h"
> #include "control.h"
> +#include "hsmmc.h"
> #include "common-board-devices.h"
> #include "am35xx-emac.h"
> #include "gpmc-nand.h"
> @@ -121,6 +123,26 @@ static void cm_t3517_init_hecc(void)
> static inline void cm_t3517_init_hecc(void) {}
> #endif
>
> +#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
> +static struct omap2_hsmmc_info cm_t3517_mmc[] = {
> + {
> + .mmc= 1,
> + .caps = MMC_CAP_4_BIT_DATA,
> + .gpio_cd= 144,
> + .gpio_wp= 59,
> + },
> + {
> + .mmc= 2,
> + .caps = MMC_CAP_4_BIT_DATA,
> + .gpio_cd= -EINVAL,
> + .gpio_wp= -EINVAL,
> + },
> + {} /* Terminator */
> +};
> +#else
> +#define cm_t3517_mmc NULL
> +#endif
> +
> #if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
> #define RTC_IO_GPIO (153)
> #define RTC_WR_GPIO (154)
> @@ -271,6 +293,10 @@ static struct omap_board_mux board_mux[] __initdata = {
> /* CM-T3517 USB HUB nRESET */
> OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
>
> + /* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
> + OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
> + OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
> +
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #endif
> @@ -286,6 +312,7 @@ static void __init cm_t3517_init(void)
> cm_t3517_init_usbh();
> cm_t3517_init_hecc();
> am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
> + omap_hsmmc_init(cm_t3517_mmc);
> }
>
> MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
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: [PATCH V3 11/11] ARM: delete struct sys_timer
Hi Stephen, I've only now bumped into the patchset (working the back log on linux-arm). Sorry for late reply, but I guess you should have Cc'd the relevant mailing lists with such changes. Cc'd now. On 11/19/12 20:31, Stephen Warren wrote: > From: Stephen Warren > > Now that the only field in struct sys_timer is .init, delete the struct, > and replace the machine descriptor .timer field with the initialization > function itself. > > This will enable moving timer drivers into drivers/clocksource without > having to place a public prototype of each struct sys_timer object into > include/linux; the intent is to create a single of_clocksource_init() > function that determines which timer driver to initialize by scanning > the device dtree, much like the proposed irqchip_init() at: > http://www.spinics.net/lists/arm-kernel/msg203686.html > > Signed-off-by: Stephen Warren > Tested-by: Robert Jarzmik > --- > v3: Minor merge conflicts due to rebasing onto next-20121115. > v2: Converted all platforms, not just Tegra. > > The patch is very large, so I've trimmed it for the mailing list, leaving > only the core ARM changes, changes outside arch/arm, and a single machine > example. The full series can be found at: > > git://nv-tegra.nvidia.com/user/swarren/linux-2.6 arm_timer_rework > --- [...] > arch/arm/mach-omap1/board-ams-delta.c |2 +- > arch/arm/mach-omap1/board-fsample.c|2 +- > arch/arm/mach-omap1/board-generic.c|2 +- > arch/arm/mach-omap1/board-h2.c |2 +- > arch/arm/mach-omap1/board-h3.c |2 +- > arch/arm/mach-omap1/board-htcherald.c |2 +- > arch/arm/mach-omap1/board-innovator.c |2 +- > arch/arm/mach-omap1/board-nokia770.c |2 +- > arch/arm/mach-omap1/board-osk.c|2 +- > arch/arm/mach-omap1/board-palmte.c |2 +- > arch/arm/mach-omap1/board-palmtt.c |2 +- > arch/arm/mach-omap1/board-palmz71.c|2 +- > arch/arm/mach-omap1/board-perseus2.c |2 +- > arch/arm/mach-omap1/board-sx1.c|2 +- > arch/arm/mach-omap1/board-voiceblue.c |2 +- > arch/arm/mach-omap1/common.h |2 +- > arch/arm/mach-omap1/time.c |6 +- > arch/arm/mach-omap2/board-2430sdp.c|2 +- > arch/arm/mach-omap2/board-3430sdp.c|2 +- > arch/arm/mach-omap2/board-3630sdp.c|2 +- > arch/arm/mach-omap2/board-4430sdp.c|2 +- > arch/arm/mach-omap2/board-am3517crane.c|2 +- > arch/arm/mach-omap2/board-am3517evm.c |2 +- > arch/arm/mach-omap2/board-apollon.c|2 +- > arch/arm/mach-omap2/board-cm-t35.c |4 ++-- > arch/arm/mach-omap2/board-cm-t3517.c |2 +- > arch/arm/mach-omap2/board-devkit8000.c |2 +- > arch/arm/mach-omap2/board-generic.c| 12 ++-- > arch/arm/mach-omap2/board-h4.c |2 +- > arch/arm/mach-omap2/board-igep0020.c |4 ++-- > arch/arm/mach-omap2/board-ldp.c|2 +- > arch/arm/mach-omap2/board-n8x0.c |6 +++--- > arch/arm/mach-omap2/board-omap3beagle.c|2 +- > arch/arm/mach-omap2/board-omap3evm.c |2 +- > arch/arm/mach-omap2/board-omap3logic.c |4 ++-- > arch/arm/mach-omap2/board-omap3pandora.c |2 +- > arch/arm/mach-omap2/board-omap3stalker.c |2 +- > arch/arm/mach-omap2/board-omap3touchbook.c |2 +- > arch/arm/mach-omap2/board-omap4panda.c |2 +- > arch/arm/mach-omap2/board-overo.c |2 +- > arch/arm/mach-omap2/board-rm680.c |4 ++-- > arch/arm/mach-omap2/board-rx51.c |2 +- > arch/arm/mach-omap2/board-ti8168evm.c |4 ++-- > arch/arm/mach-omap2/board-zoom.c |4 ++-- > arch/arm/mach-omap2/common.h | 12 ++-- > arch/arm/mach-omap2/timer.c| 17 +++-- [...] > 492 files changed, 622 insertions(+), 1199 deletions(-) I've looked at the omap2+ changes and I think OMAP4 and 5 got messed up a bit... the below (compile tested on omap2plus only) should be applied: diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 2e0c446..f5d5f59 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -725,6 +725,6 @@ MACHINE_START(OMAP_4430SDP, "OMAP4430 4430SDP board") .handle_irq = gic_handle_irq, .init_machine = omap_4430sdp_init, .init_late = omap4430_init_late, - .init_time = omap4_sync32k_timer_init, + .init_time = omap4_local_timer_init, .restart= omap44xx_restart, MACHINE_END diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.
[PATCH v2] ARM: OMAP3: cm-t3517: add MMC support
cm-t3517 uses two MMC interfaces. Add support for both.
Signed-off-by: Igor Grinberg
---
v2: Use CONFIG_MMC_OMAP_HS instead of plain CONFIG_MMC, so it will be stubbed
out with the same defines as omap_hsmmc_init() function.
Fix the !CONFIG_MMC_OMAP_HS case.
arch/arm/mach-omap2/board-cm-t3517.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index ebbc2ad..792d684 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -46,6 +47,7 @@
#include "mux.h"
#include "control.h"
+#include "hsmmc.h"
#include "common-board-devices.h"
#include "am35xx-emac.h"
#include "gpmc-nand.h"
@@ -121,6 +123,26 @@ static void cm_t3517_init_hecc(void)
static inline void cm_t3517_init_hecc(void) {}
#endif
+#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
+static struct omap2_hsmmc_info cm_t3517_mmc[] = {
+ {
+ .mmc= 1,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= 144,
+ .gpio_wp= 59,
+ },
+ {
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+#else
+#define cm_t3517_mmc NULL
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -271,6 +293,10 @@ static struct omap_board_mux board_mux[] __initdata = {
/* CM-T3517 USB HUB nRESET */
OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
+ OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -286,6 +312,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_usbh();
cm_t3517_init_hecc();
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
+ omap_hsmmc_init(cm_t3517_mmc);
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.3.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
[PATCH] ARM: OMAP3: cm-t3517: add MMC support
cm-t3517 uses two MMC interfaces. Add support for both.
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t3517.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index ebbc2ad..fb1f993 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -46,6 +47,7 @@
#include "mux.h"
#include "control.h"
+#include "hsmmc.h"
#include "common-board-devices.h"
#include "am35xx-emac.h"
#include "gpmc-nand.h"
@@ -121,6 +123,24 @@ static void cm_t3517_init_hecc(void)
static inline void cm_t3517_init_hecc(void) {}
#endif
+#if defined(CONFIG_MMC) || defined(CONFIG_MMC_MODULE)
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= 144,
+ .gpio_wp= 59,
+ },
+ {
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -271,6 +291,10 @@ static struct omap_board_mux board_mux[] __initdata = {
/* CM-T3517 USB HUB nRESET */
OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
+ OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -286,6 +310,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_usbh();
cm_t3517_init_hecc();
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
+ omap_hsmmc_init(mmc);
}
MACHINE_START(CM_T3517, "Compulab CM-T3517")
--
1.7.3.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 V2 3/4] ARM: AM335x: Fix warning in timer.c
On 11/29/12 00:04, Jon Hunter wrote: > When compiling the kernel with configuration options ... > > # CONFIG_ARCH_OMAP2 is not set > # CONFIG_ARCH_OMAP3 is not set > # CONFIG_ARCH_OMAP4 is not set > # CONFIG_SOC_OMAP5 is not set > CONFIG_SOC_AM33XX=y > > ... the following build warning is seen. > > CC arch/arm/mach-omap2/timer.o > arch/arm/mach-omap2/timer.c:395:19: warning: > ‘omap2_sync32k_clocksource_init’ > defined but not used [-Wunused-function] > > This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove > CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no > longer referenced by the timer initialisation function for the AM335x > device as it has no 32k-sync timer. > > Fix this by adding the "__maybe_unused" compiler directive to the > omap2_sync32k_clocksource_init() function to indicate that this function > may be used for certain configurations. > > Cc: Igor Grinberg > > Signed-off-by: Jon Hunter Acked-by: Igor Grinberg -- 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: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c
On 11/28/12 08:28, Santosh Shilimkar wrote: > On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote: >> When compiling the kernel with configuration options ... >> >> # CONFIG_ARCH_OMAP2 is not set >> # CONFIG_ARCH_OMAP3 is not set >> # CONFIG_ARCH_OMAP4 is not set >> # CONFIG_SOC_OMAP5 is not set >> CONFIG_SOC_AM33XX=y >> >> ... the following build warning is seen. >> >>CC arch/arm/mach-omap2/timer.o >>arch/arm/mach-omap2/timer.c:395:19: warning: >> ‘omap2_sync32k_clocksource_init’ >>defined but not used [-Wunused-function] >> >> This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove >> CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no >> longer referenced by the timer initialisation function for the AM335x >> device as it has no 32k-sync timer. >> >> Fix this by only including the omap2_sync32k_clocksource_init() function >> if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled. >> >> Cc: Igor Grinberg >> >> Signed-off-by: Jon Hunter >> --- >> arch/arm/mach-omap2/timer.c |3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c >> index eb96712..085c7e7 100644 >> --- a/arch/arm/mach-omap2/timer.c >> +++ b/arch/arm/mach-omap2/timer.c >> @@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void) >> return 0; >> } >> >> +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \ >> +defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) > #ifndef CONFIG_SOC_AM33XX ? > > #ifdef things are really ugly and needs constant patching and > hence something like CONFIG_HAS_32K kind of feature flags are > better. But that will undo certain part of f80b3b > (ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER). Agreed on ugliness of ifdefs. What about adding __maybe_unused to the function signature? That will cover any future SoC also w/o the need to extend the ifdefs. -- 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: [PATCH 2/3] ARM: OMAP4: Fix build error and warning in timer.c
On 11/28/12 04:15, Jon Hunter wrote:
> When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
> enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
> warning is seen.
>
> CC arch/arm/mach-omap2/timer.o
> arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
> arch/arm/mach-omap2/timer.c:630:2: error: implicit declaration of
> function ‘omap4_sync32_timer_init’
> [-Werror=implicit-function-declaration]
> arch/arm/mach-omap2/timer.c: At top level:
> arch/arm/mach-omap2/timer.c:607:1: warning: ‘omap4_sync32k_timer_init’
> defined but not used [-Wunused-function]
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
>
> This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
> CONFIG_OMAP_32K_TIMER) where the "k" is missing from the "sync32k" in
> the function name "omap4_sync32_timer_init". Therefore, correct this
> typo to resolve the above error and warning.
Yeah ;-( sorry for this...
>
> Cc: Igor Grinberg
>
> Reported-by: Tony Lindgren
> Signed-off-by: Jon Hunter
Acked-by: Igor Grinberg
> ---
> arch/arm/mach-omap2/timer.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index a9f99e3..eb96712 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -627,7 +627,7 @@ static void __init omap4_local_timer_init(void)
> #else /* CONFIG_LOCAL_TIMERS */
> static inline void omap4_local_timer_init(void)
> {
> - omap4_sync32_timer_init();
> + omap4_sync32k_timer_init();
> }
> #endif /* CONFIG_LOCAL_TIMERS */
> OMAP_SYS_TIMER(4, local);
--
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: [PATCH] ARM: OMAP: Conditionally compile counter_32k
On 11/26/12 15:15, Alessio Igor Bogani wrote: > Hi Igor, > > On 26/11/2012 13:02, Igor Grinberg wrote: >> On 11/26/12 11:28, Alessio Igor Bogani wrote: > [...] >>> # Common support >>> -obj-y := sram.o dma.o fb.o counter_32k.o >>> +obj-y := sram.o dma.o fb.o >>> obj-m := >>> obj-n := >>> obj- := >>> >>> +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o >> >> We are moving away from this config option in favor of runtime detection, > > Well, I'll be happy when it'll happen. > >> Why do you need this? > > Because until now the build system doesn't honour the config file. Indeed it > builds that source code file also when I set CONFIG_OMAP_32K_TIMER to n. > > The runtime detection isn't a good excuse for doesn't make the build system > working like users expect. So, the problem is the users expectations... If you look, at Tony's omap-for-v3.8/timer branch, patch: ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER it should change the expectations (at least I tried to do this in Kconfig file). So, to the question of honoring the config option - yes, but it is a work in progress on removing that one. If you have a real issue that you are trying to fix - it is totally different thing, but if it is just config option honoring... then I don't think we should merge this patch. -- 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: [PATCH] ARM: OMAP: Conditionally compile counter_32k
On 11/26/12 11:28, Alessio Igor Bogani wrote: > The 32K timer isn't available on all OMAP devices. > > Signed-off-by: Alessio Igor Bogani > --- > arch/arm/plat-omap/Makefile |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile > index 8d88584..b1b321c 100644 > --- a/arch/arm/plat-omap/Makefile > +++ b/arch/arm/plat-omap/Makefile > @@ -3,11 +3,13 @@ > # > > # Common support > -obj-y := sram.o dma.o fb.o counter_32k.o > +obj-y := sram.o dma.o fb.o > obj-m := > obj-n := > obj- := > > +obj-$(CONFIG_OMAP_32K_TIMER) += counter_32k.o We are moving away from this config option in favor of runtime detection, so I don't think this patch is appropriate. Why do you need this? > + > # omap_device support (OMAP2+ only at the moment) > > obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o -- 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 v3 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer initialization functions are named by the platform
name and the clock source in use.
This also makes it possible to define and use the GPTIMER as the
clock source instead of the 32K timer on platforms that do not have
the 32K timer ip block or the 32K timer is not wired on the board.
Currently, the the timer is chosen in the machine_desc structure on
per board basis. Later, DT should be used to choose the timer.
2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults
and those under !CONFIG_OMAP_32K_TIMER are removed.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg
Cc: Jon Hunter
Cc: Santosh Shilimkar
Cc: Vaibhav Hiremath
Acked-by: Santosh Shilimkar
Reviewed-by: Jon Hunter
---
Compile tested on omap2plus_defconfig + crane board enabled.
This patch conflicts slightly with the:
ARM: OMAP2+: Fix compiler warning for 32k timer (From Jon)
(or its future versions) available at:
http://www.spinics.net/lists/linux-omap/msg82465.html
With this patch applied, there will be no need for the above patch.
v2: 1) Do not change the default timer name to avoid multiple
renaming in the board files (Tony).
2) Inline the DT timer property (Jon).
3) Do not rename actual timer initialization functions and get rid of the
wrapper function for omap2_sync32k_clocksource_init() function.
4) Remove the oddness around omap2_##clksrc_name##_clocksource_init()
function by introducing a separate macro for gptimer case.
5) Avoid having two timer_init functions for each OMAP generation and
add only those necessary (Jon).
v3: Fix commit message typos (10x Jon).
arch/arm/mach-omap2/timer.c | 128 +-
arch/arm/plat-omap/Kconfig |6 ++
2 files changed, 58 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 099e406..418753f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -64,20 +64,6 @@
#define OMAP3_32K_SOURCE "omap_32k_fck"
#define OMAP4_32K_SOURCE "sys_32k_ck"
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
-#define TIMER_PROP_SECURE "ti,timer-secure"
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE "ti,timer-alwon"
-#endif
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -407,7 +393,6 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
static int __init omap2_sync32k_clocksource_init(void)
{
@@ -468,12 +453,6 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
@@ -499,25 +478,6 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
gptimer_id, clksrc.rate);
}
-static void __init omap2_clocksource_init(int gptimer_id,
- const char *fck_source)
-{
- /*
-* First give preference to kernel parameter configuration
-* by user (clocksource="gp_timer").
-*
-* In case of missing kernel parameter for clocksource,
-* first check for availability for 32k-sync timer, in case
-* of failure in finding 32k_counter module or registering
-* it as clocksource, execution will fallback to gp-timer.
-*/
- if (use_gptimer_clksrc == true)
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
- else if (omap2_sync32k_clocksource_init())
- /* Fall back to gp-timer code */
-
[PATCH v2 1/2] ads7846: enable pendown GPIO debounce time setting
Some platforms need the pendown GPIO debounce time setting programmed.
Since the pendown GPIO is handled by the driver, the debounce time
should also be handled along with the pendown GPIO request.
Signed-off-by: Igor Grinberg
---
v2: fix the comment style
drivers/input/touchscreen/ads7846.c |6 +-
include/linux/spi/ads7846.h |5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..78e5d9a 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -955,7 +955,8 @@ static int ads7846_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ads7846_pm, ads7846_suspend, ads7846_resume);
-static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct
ads7846 *ts)
+static int __devinit ads7846_setup_pendown(struct spi_device *spi,
+ struct ads7846 *ts)
{
struct ads7846_platform_data *pdata = spi->dev.platform_data;
int err;
@@ -981,6 +982,9 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
ts->gpio_pendown = pdata->gpio_pendown;
+ if (pdata->gpio_pendown_debounce)
+ gpio_set_debounce(pdata->gpio_pendown,
+ pdata->gpio_pendown_debounce);
} else {
dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
return -EINVAL;
diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h
index c64de9d..2f694f3 100644
--- a/include/linux/spi/ads7846.h
+++ b/include/linux/spi/ads7846.h
@@ -46,8 +46,9 @@ struct ads7846_platform_data {
u16 debounce_rep; /* additional consecutive good readings
* required after the first two */
int gpio_pendown; /* the GPIO used to decide the pendown
-* state if get_pendown_state == NULL
-*/
+* state if get_pendown_state == NULL */
+ int gpio_pendown_debounce; /* platform specific debounce time for
+* the gpio_pendown */
int (*get_pendown_state)(void);
int (*filter_init) (const struct ads7846_platform_data *pdata,
void **filter_data);
--
1.7.3.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
[PATCH 2/2] ARM: OMAP: ads7846: fix pendown debounce setting
Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the
pendown GPIO debounce time setting by the below sequence:
gpio_request_one()
gpio_set_debounce()
gpio_free()
It also revealed a bug in the OMAP GPIO handling code which prevented
the GPIO debounce clock to be disabled and CORE transition to low power
states.
Commit c9c55d9 (gpio/omap: fix off-mode bug: clear debounce settings on
free/reset) fixes the OMAP GPIO handling code by making sure that the
GPIO debounce clock gets disabled if no GPIO is requested from current
bank.
While fixing the OMAP GPIO handling code (in the right way), the above
commit makes the gpio_request->set_debounce->free sequence invalid as
after freeing the GPIO, the debounce settings are lost.
Fix the debounce settings by moving the debounce initialization to the
actual GPIO requesting code - the ads7846 driver.
Signed-off-by: Igor Grinberg
Cc: Kevin Hilman
Cc: Zumeng Chen
---
arch/arm/mach-omap2/common-board-devices.c | 34 ---
1 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/common-board-devices.c
b/arch/arm/mach-omap2/common-board-devices.c
index ad85609..d246efd 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -63,30 +63,36 @@ void __init omap_ads7846_init(int bus_num, int
gpio_pendown, int gpio_debounce,
struct spi_board_info *spi_bi = &ads7846_spi_board_info;
int err;
- err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
- if (err) {
- pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
- return;
- }
+ /*
+* If a board defines get_pendown_state() function, request the pendown
+* GPIO and set the GPIO debounce time.
+* If a board does not define the get_pendown_state() function, then
+* the ads7846 driver will setup the pendown GPIO itself.
+*/
+ if (board_pdata && board_pdata->get_pendown_state) {
+ err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
+ if (err) {
+ pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
+ return;
+ }
+
+ if (gpio_debounce)
+ gpio_set_debounce(gpio_pendown, gpio_debounce);
- if (gpio_debounce)
- gpio_set_debounce(gpio_pendown, gpio_debounce);
+ gpio_export(gpio_pendown, 0);
+ }
spi_bi->bus_num = bus_num;
spi_bi->irq = gpio_to_irq(gpio_pendown);
+ ads7846_config.gpio_pendown = gpio_pendown;
+
if (board_pdata) {
board_pdata->gpio_pendown = gpio_pendown;
+ board_pdata->gpio_pendown_debounce = gpio_debounce;
spi_bi->platform_data = board_pdata;
- if (board_pdata->get_pendown_state)
- gpio_export(gpio_pendown, 0);
- } else {
- ads7846_config.gpio_pendown = gpio_pendown;
}
- if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state))
- gpio_free(gpio_pendown);
-
spi_register_board_info(&ads7846_spi_board_info, 1);
}
#else
--
1.7.3.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
[PATCH 1/2] ads7846: enable pendown GPIO debounce time setting
Some platforms need the pendown GPIO debounce time setting programmed.
Since the pendown GPIO is handled by the driver, the debounce time
should also be handled along with the pendown GPIO request.
Signed-off-by: Igor Grinberg
---
drivers/input/touchscreen/ads7846.c |6 +-
include/linux/spi/ads7846.h |5 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..78e5d9a 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -955,7 +955,8 @@ static int ads7846_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ads7846_pm, ads7846_suspend, ads7846_resume);
-static int __devinit ads7846_setup_pendown(struct spi_device *spi, struct
ads7846 *ts)
+static int __devinit ads7846_setup_pendown(struct spi_device *spi,
+ struct ads7846 *ts)
{
struct ads7846_platform_data *pdata = spi->dev.platform_data;
int err;
@@ -981,6 +982,9 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
ts->gpio_pendown = pdata->gpio_pendown;
+ if (pdata->gpio_pendown_debounce)
+ gpio_set_debounce(pdata->gpio_pendown,
+ pdata->gpio_pendown_debounce);
} else {
dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
return -EINVAL;
diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h
index c64de9d..2e94187 100644
--- a/include/linux/spi/ads7846.h
+++ b/include/linux/spi/ads7846.h
@@ -46,8 +46,9 @@ struct ads7846_platform_data {
u16 debounce_rep; /* additional consecutive good readings
* required after the first two */
int gpio_pendown; /* the GPIO used to decide the pendown
-* state if get_pendown_state == NULL
-*/
+* state if get_pendown_state == NULL */
+ int gpio_pendown_debounce; /* platform specific debounce time for
+ the gpio_pendown */
int (*get_pendown_state)(void);
int (*filter_init) (const struct ads7846_platform_data *pdata,
void **filter_data);
--
1.7.3.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
[PATCH 0/2] ARM: OMAP: ads7846: fix pendown debounce setting
Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the pendown GPIO debounce time setting by the below sequence: gpio_request_one() gpio_set_debounce() gpio_free() It also revealed a bug in the OMAP GPIO handling code which prevented the GPIO debounce clock to be disabled and CORE transition to low power states. Commit c9c55d9 (gpio/omap: fix off-mode bug: clear debounce settings on free/reset) fixes the OMAP GPIO handling code by making sure that the GPIO debounce clock gets disabled if no GPIO is requested from current bank. While fixing the OMAP GPIO handling code (in the right way), the above commit makes the gpio_request->set_debounce->free sequence invalid as after freeing the GPIO, the debounce settings are lost. This patch set: 1) Adds the pendown GPIO debounce time setting to the platform data structure of the ads7846 driver. 2) Fixes the OMAP platform code to pass the debounce time value to the driver instead of handling it by itself. Igor Grinberg (2): ads7846: enable pendown GPIO debounce time setting ARM: OMAP: ads7846: fix pendown debounce setting arch/arm/mach-omap2/common-board-devices.c | 34 --- drivers/input/touchscreen/ads7846.c|6 - include/linux/spi/ads7846.h|5 ++- 3 files changed, 28 insertions(+), 17 deletions(-) -- 1.7.3.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
[PATCH v2 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
setting.
To remove the dependancy, several conversions/additions had to be done:
1) Timer initialization functions are named by the platform
name and the clock source in use.
This also makes it possible to define and use the GPTIMER as the
clock source instead of the 32K timer on platforms that do not have
the 32K timer ip block or the 32K timer is not wired on the board.
Cirrently, the the timer is chosen in the machine_desc structure on
per board basis. Later, DT should be used to choose the timer.
2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults
and those under !CONFIG_OMAP_32K_TIMER are removed.
This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
3) Since we have all the timers defined inside machine_desc structure
and we no longer need the fallback to gp_timer clock source in case
32k_timer clock source is unavailable (namely on AM33xx), we no
longer need the #ifdef around __omap2_sync32k_clocksource_init()
function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
__omap2_sync32k_clocksource_init() function.
Signed-off-by: Igor Grinberg
Cc: Jon Hunter
Cc: Santosh Shilimkar
Cc: Vaibhav Hiremath
---
Compile tested on omap2plus_defconfig + crane board enabled.
This patch conflicts slightly with the:
ARM: OMAP2+: Fix compiler warning for 32k timer (From Jon)
(or its future versions) available at:
http://www.spinics.net/lists/linux-omap/msg82465.html
With this patch applied, there will be no need for the above patch.
v2: 1) Do not change the default timer name to avoid multiple
renaming in the board files (Tony).
2) Inline the DT timer property (Jon).
3) Do not rename actual timer initialization functions and get rid of the
wrapper function for omap2_sync32k_clocksource_init() function.
4) Remove the oddness around omap2_##clksrc_name##_clocksource_init()
function by introducing a separate macro for gptimer case.
5) Avoid having two timer_init functions for each OMAP generation and
add only those necessary (Jon).
arch/arm/mach-omap2/timer.c | 128 +-
arch/arm/plat-omap/Kconfig |6 ++
2 files changed, 58 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 099e406..418753f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -64,20 +64,6 @@
#define OMAP3_32K_SOURCE "omap_32k_fck"
#define OMAP4_32K_SOURCE "sys_32k_ck"
-#ifdef CONFIG_OMAP_32K_TIMER
-#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
-#define OMAP3_SECURE_TIMER 12
-#define TIMER_PROP_SECURE "ti,timer-secure"
-#else
-#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
-#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
-#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
-#define OMAP3_SECURE_TIMER 1
-#define TIMER_PROP_SECURE "ti,timer-alwon"
-#endif
-
#define REALTIME_COUNTER_BASE 0x48243200
#define INCREMENTER_NUMERATOR_OFFSET 0x10
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
@@ -407,7 +393,6 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}
-#ifdef CONFIG_OMAP_32K_TIMER
/* Setup free-running counter for clocksource */
static int __init omap2_sync32k_clocksource_init(void)
{
@@ -468,12 +453,6 @@ static int __init omap2_sync32k_clocksource_init(void)
return ret;
}
-#else
-static inline int omap2_sync32k_clocksource_init(void)
-{
- return -ENODEV;
-}
-#endif
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
@@ -499,25 +478,6 @@ static void __init omap2_gptimer_clocksource_init(int
gptimer_id,
gptimer_id, clksrc.rate);
}
-static void __init omap2_clocksource_init(int gptimer_id,
- const char *fck_source)
-{
- /*
-* First give preference to kernel parameter configuration
-* by user (clocksource="gp_timer").
-*
-* In case of missing kernel parameter for clocksource,
-* first check for availability for 32k-sync timer, in case
-* of failure in finding 32k_counter module or registering
-* it as clocksource, execution will fallback to gp-timer.
-*/
- if (use_gptimer_clksrc == true)
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
- else if (omap2_sync32k_clocksource_init())
- /* Fall back to gp-timer code */
- omap2_gptimer_clocksource_init(gptimer_id, fck_source);
-}
-
#ifdef CONFIG_SOC_HAS_
[PATCH 2/2] ARM: OMAP3: cm-t3517: use GPTIMER for system clock
cm-t3517 starting from revision 1.2 does not have the 32K oscilator wired to the AM3517 SoC. Therefore switch to use the GPTIMER for system clock. Signed-off-by: Igor Grinberg --- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c |3 +++ 3 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t3517.c b/arch/arm/mach-omap2/board-cm-t3517.c index 699caec..ebbc2ad 100644 --- a/arch/arm/mach-omap2/board-cm-t3517.c +++ b/arch/arm/mach-omap2/board-cm-t3517.c @@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, "Compulab CM-T3517") .handle_irq = omap3_intc_handle_irq, .init_machine = cm_t3517_init, .init_late = am35xx_init_late, - .timer = &omap3_timer, + .timer = &omap3_gp_timer, .restart= omap3xxx_restart, MACHINE_END diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index dae55d8..948bcaa 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -82,6 +82,7 @@ extern void omap2_init_common_infrastructure(void); extern struct sys_timer omap2_timer; extern struct sys_timer omap3_timer; extern struct sys_timer omap3_secure_timer; +extern struct sys_timer omap3_gp_timer; extern struct sys_timer omap3_am33xx_timer; extern struct sys_timer omap4_timer; extern struct sys_timer omap5_timer; diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 418753f..4bcf080 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -596,6 +596,9 @@ OMAP_SYS_TIMER(3, sync32k); OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, "ti,timer-secure", 2, OMAP3_MPU_SOURCE); OMAP_SYS_TIMER(3_secure, sync32k); +OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, "ti,timer-alwon", + 2, OMAP3_MPU_SOURCE); +OMAP_SYS_TIMER(3_gp, gptimer); #endif /* CONFIG_ARCH_OMAP3 */ #ifdef CONFIG_SOC_AM33XX -- 1.7.3.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] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/13/12 18:13, Jon Hunter wrote: > > On 11/13/2012 03:14 AM, Igor Grinberg wrote: >> On 11/12/12 21:15, Jon Hunter wrote: >>> >>> On 11/11/2012 05:28 AM, Igor Grinberg wrote: >>>> >>>> >>>> On 11/08/12 21:16, Jon Hunter wrote: >>>>> >>>>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: >>>>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: >>>>>>> >>>>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote: >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>>> There is no reliable way to determine which source should be used in >>>>>>>> runtime >>>>>>>> for boards that do not have the 32k oscillator wired. >>>>>>> >>>>>>> So thinking about this some more and given that we are moving away from >>>>>>> board files, if a board does not provide a 32kHz clock source, then this >>>>>>> should be reflected in the device-tree source file for that board. >>>>>>> Hence, at boot time we should be able to determine if a 32kHz clock >>>>>>> source can be used. >>>>>>> >>>>>> >>>>>> Let me feed some more thoughts here :) >>>>>> >>>>>> The way it is being detected currently is based on timer idle status bit. >>>>>> I am worried that, this is the only option we have. >>>>> >>>>> Why not use device-tree to indicate the presence of a 32k clock source? >>>>> This seems like a board level configuration and so device-tree seems to >>>>> be the perfect place for this IMO. >>>> >>>> Well, that is what my commit message says... >>> >>> Sorry, but that was not clear to me from whats in the commit message. >> >> From the commit message: >> "1) Timer structures and initialization functions are named by the platform >>name and the clock source in use. The decision which timer is >>used is done statically from the machine_desc structure. In the >>future it should come from DT." >> >> The last sentence has it. > > Right, but it does not go into the details. It would be good to have > added a comment to the effect of "some boards do not have a 32k clock > source and in the future this should be handled by device-tree". Ok. > >> The transition to DT is not immediate and we can't (still) neglect >> the non-DT setups. > > Absolutely, but I am trying to understand if there are boards being > "neglected". I see now that your CM-T3517 would be. This was not clear > from your patch as even the CM-T3517 board was being configured to the > use the sync32k timer. So from looking at your patch I did not see any > neglected boards, however, I understand your motivation to add all these > init functions so that boards could be customised easily. I did not changed the CM-T3517, because I believe it should be done in a separate patch. > >>> Should we be doing this now instead of adding all these static timer >>> init functions? >> >> I don't see this as "adding ...", I see this as expanding the setup >> which was previously hidden by the CONFIG_OMAP_32K_TIMER option. >> >>> >>> Are there any boards today (supported in the kernel that is), that don't >>> support a 32k? >> >> Yes, starting from revision 1.2, CM-T3517 does not have the 32k. > > Thanks, this is the exact information I was looking for. You should put > this in your commit message to highlight the fact that there are boards > that don't have a 32k clock source. > > I am familiar with the OMAP devices, but less familiar with these AM > derivatives (as I don't work with these) and so it is good to put these > specifics in the commit message. Ok. -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/12/12 21:15, Jon Hunter wrote: > > On 11/11/2012 05:28 AM, Igor Grinberg wrote: >> >> >> On 11/08/12 21:16, Jon Hunter wrote: >>> >>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: >>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: >>>>> >>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote: >>>>> >>>>> [snip] >>>>> >>>>>> There is no reliable way to determine which source should be used in >>>>>> runtime >>>>>> for boards that do not have the 32k oscillator wired. >>>>> >>>>> So thinking about this some more and given that we are moving away from >>>>> board files, if a board does not provide a 32kHz clock source, then this >>>>> should be reflected in the device-tree source file for that board. >>>>> Hence, at boot time we should be able to determine if a 32kHz clock >>>>> source can be used. >>>>> >>>> >>>> Let me feed some more thoughts here :) >>>> >>>> The way it is being detected currently is based on timer idle status bit. >>>> I am worried that, this is the only option we have. >>> >>> Why not use device-tree to indicate the presence of a 32k clock source? >>> This seems like a board level configuration and so device-tree seems to >>> be the perfect place for this IMO. >> >> Well, that is what my commit message says... > > Sorry, but that was not clear to me from whats in the commit message. >From the commit message: "1) Timer structures and initialization functions are named by the platform name and the clock source in use. The decision which timer is used is done statically from the machine_desc structure. In the future it should come from DT." The last sentence has it. The transition to DT is not immediate and we can't (still) neglect the non-DT setups. > > Should we be doing this now instead of adding all these static timer > init functions? I don't see this as "adding ...", I see this as expanding the setup which was previously hidden by the CONFIG_OMAP_32K_TIMER option. > > Are there any boards today (supported in the kernel that is), that don't > support a 32k? Yes, starting from revision 1.2, CM-T3517 does not have the 32k. [...] -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/12/12 21:05, Jon Hunter wrote: > > On 11/11/2012 03:16 AM, Igor Grinberg wrote: >> On 11/08/12 18:20, Tony Lindgren wrote: >>> * Igor Grinberg [121107 23:15]: >>>> On 11/07/12 19:33, Tony Lindgren wrote: >>>>> >>>>> I think this should be the default for the timers as that counter >>>>> does not stop during deeper idle states. >>>> >>>> Well, it is the default as you can see from the patch. >>>> The problem is that for boards that for some reason do not have >>>> the 32k wired and rely on MPU/GP timer source, the default will not work >>>> and currently there is no way for board to specify which timer source >>>> it can use. >>> >>> Yes. I was just wondering if we can avoid patching all the board >>> files by doing it the other way around by introducing a new >>> omap_gp_timer rather than renaming all the existing ones? >> >> Is the renaming that bad? One line per machine_desc structure? >> Of course we can skip the renaming, but then it will be less consistent >> and will not reflect the actual timer source used. >> I tried to make it flexible as much as possible and self explanatory. >> So above are my considerations, but at this point in time I don't really >> care if we rename them or just add a new one, but we have to get rid of >> the ugly fall back. > > I am not sure if you guys disagree, but does it make sense to start > thinking about this with regard to device-tree? With device-tree all the > boards files will become obsolete and so we need to be able to handle > this during boot time and not compile time. This is understood completely, but I personally think that we should not neglect the "still not converted to DT boards", because the conversion takes time and involves much more effort. Also taking into account that there are subsystems that are still not converted to DT. Also, removing the CONFIG_OMAP_32K_TIMER _does_ get us closer to handle the timers init during boot time. > >>> >>>> We have discussed this in San Diego (remember?) and you actually proposed >>>> this way as a solution. Well, may be I took it a bit further than you >>>> thought, but this is because the board code cannot know which timer source >>>> should be used at runtime and the fall back described below, does not work. >>> >>> Yes thanks I agree we should get rid of that Kconfig option for sure. >>> >>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c >>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c >>>>>> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board") >>>>>> .handle_irq = omap2_intc_handle_irq, >>>>>> .init_machine = omap_2430sdp_init, >>>>>> .init_late = omap2430_init_late, >>>>>> -.timer = &omap2_timer, >>>>>> +.timer = &omap2_sync32k_timer, >>>>>> .restart= omap_prcm_restart, >>>>>> MACHINE_END >>>>>> --- a/arch/arm/mach-omap2/board-3430sdp.c >>>>>> +++ b/arch/arm/mach-omap2/board-3430sdp.c >>>>>> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board") >>>>>> .handle_irq = omap3_intc_handle_irq, >>>>>> .init_machine = omap_3430sdp_init, >>>>>> .init_late = omap3430_init_late, >>>>>> -.timer = &omap3_timer, >>>>>> +.timer = &omap3_sync32k_timer, >>>>>> .restart= omap_prcm_restart, >>>>>> MACHINE_END >>>>> ... >>>>> >>>>> Can't we assume that the default timer is omap[234]_sync32k_timer to >>>>> avoid renaming the timer entries in all the board files? >>>> >>>> Hmmm... >>>> How will this work with the macros defining the sys_timer structure? >>>> I would also not want to hide the exact timer used under the default name. >>> >>> Can't you just add a new sys_timer (or a new macro) for GP only setups? >> >> Of course I can... but I tried to create a flexible generic code, so >> no meter how a board will be wired, you just need to specify which timer >> source >> it uses and be done with it. > > If you are concerned about how a board is wired up (if the 32k is > present), then I think that that is best handled via device-tree and we > should query device-tree on boot to see what our options are. > > What do you guys think? Yes, but again, you can't neglect the non-DT case... at least until you have everything converted to DT. -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/12/12 08:38, Hiremath, Vaibhav wrote: > On Sun, Nov 11, 2012 at 17:05:07, Igor Grinberg wrote: >> >> >> On 11/08/12 20:34, Jon Hunter wrote: >>> >>> On 11/08/2012 12:17 PM, Paul Walmsley wrote: >>>> On Thu, 8 Nov 2012, Jon Hunter wrote: >>>> >>>>> On 11/08/2012 11:58 AM, Paul Walmsley wrote: >>>>>> On Thu, 8 Nov 2012, Jon Hunter wrote: >>>>>> >>>>>>> Igor was mentioning a h/w scenario where the 32kHz source is not >>>>>>> present. However, I am not sure which devices support this and is >>>>>>> applicable too. >>>>>> >>>>>> Pretty sure Igor is referring to the AM3517/3505. This is very poorly >>>>>> documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) >>>>>> Figure >>>>>> 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4 >>>>>> "Clock Specifications". >>>>> >>>>> But AFAICT, even in that h/w configuration the internal 32k >>>>> oscillator will be used >>>> >>>> Just to clarify, there's no internal 32k oscillator used on the 3517/3505; >>>> just a divider from the HF clock. >>> >>> Ah yes I see that now! >>> >>>>> and so the gptimer will still have a 32k clock source. >>>> >>>> That's a good question and you might want to check with Igor on that one, >>>> the AM3517 TRM conflicts with the DM as to whether it's available to the >>>> GPTIMER or not :-( >>> >>> Well the external 32k and internal divided down version go through the >>> same mux and so that seems to imply either they are both available to >>> the gptimer or neither is. >> >> Yep, but the /800 do not get you the 32768... >> and that makes the timer suck. >> Of course this can be dealt with in the clock subsystem >> (I remember Paul said that he will look into that), but it will take time. >> >> Also, what about having the sys_clk instead of 32k for higher precision? >> Is that possible already (without my patch)? >> > > Yes, it is possible. You can choose it through bootargs. Is the kernel command line the only way for doing this? I personally dislike it, because it brings multiple maintenance problems. This must be possible at least through DT. -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/12 20:34, Jon Hunter wrote: > > On 11/08/2012 12:17 PM, Paul Walmsley wrote: >> On Thu, 8 Nov 2012, Jon Hunter wrote: >> >>> On 11/08/2012 11:58 AM, Paul Walmsley wrote: On Thu, 8 Nov 2012, Jon Hunter wrote: > Igor was mentioning a h/w scenario where the 32kHz source is not > present. However, I am not sure which devices support this and is > applicable too. Pretty sure Igor is referring to the AM3517/3505. This is very poorly documented, but can be observed in the AM3517 TRM Rev B (SPRUGR0B) Figure 4-23 "PRM Clock Generator" and the AM3517 DM Rev C (SPRS550C) Section 4 "Clock Specifications". >>> >>> But AFAICT, even in that h/w configuration the internal 32k >>> oscillator will be used >> >> Just to clarify, there's no internal 32k oscillator used on the 3517/3505; >> just a divider from the HF clock. > > Ah yes I see that now! > >>> and so the gptimer will still have a 32k clock source. >> >> That's a good question and you might want to check with Igor on that one, >> the AM3517 TRM conflicts with the DM as to whether it's available to the >> GPTIMER or not :-( > > Well the external 32k and internal divided down version go through the > same mux and so that seems to imply either they are both available to > the gptimer or neither is. Yep, but the /800 do not get you the 32768... and that makes the timer suck. Of course this can be dealt with in the clock subsystem (I remember Paul said that he will look into that), but it will take time. Also, what about having the sys_clk instead of 32k for higher precision? Is that possible already (without my patch)? -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/12 21:16, Jon Hunter wrote: > > On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: >> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: >>> >>> On 11/08/2012 01:59 AM, Igor Grinberg wrote: >>> >>> [snip] >>> >>>> There is no reliable way to determine which source should be used in >>>> runtime >>>> for boards that do not have the 32k oscillator wired. >>> >>> So thinking about this some more and given that we are moving away from >>> board files, if a board does not provide a 32kHz clock source, then this >>> should be reflected in the device-tree source file for that board. >>> Hence, at boot time we should be able to determine if a 32kHz clock >>> source can be used. >>> >> >> Let me feed some more thoughts here :) >> >> The way it is being detected currently is based on timer idle status bit. >> I am worried that, this is the only option we have. > > Why not use device-tree to indicate the presence of a 32k clock source? > This seems like a board level configuration and so device-tree seems to > be the perfect place for this IMO. Well, that is what my commit message says... -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/12 18:16, Jon Hunter wrote:
>
> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>> On 11/07/12 23:36, Jon Hunter wrote:
>>> Hi Igor,
>>>
>>> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
>>>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
>>>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
>>>> setting.
>>>> To remove the dependancy, several conversions/additions had to be done:
>>>> 1) Timer structures and initialization functions are named by the platform
>>>>name and the clock source in use. The decision which timer is
>>>>used is done statically from the machine_desc structure. In the
>>>>future it should come from DT.
>>>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
>>>>separate timer structures along with the timer init functions.
>>>>This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
>>>> 3) Since we have all the timers defined inside machine_desc structure
>>>>and we no longer need the fallback to gp_timer clock source in case
>>>>32k_timer clock source is unavailable (namely on AM33xx), we no
>>>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
>>>>function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
>>>>__omap2_sync32k_clocksource_init() function.
>>>>
>>>> Signed-off-by: Igor Grinberg
>>>> Cc: Jon Hunter
>>>> Cc: Santosh Shilimkar
>>>> Cc: Vaibhav Hiremath
>>>
>>> [snip]
>>>
>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>>> index 684d2fc..a4ad7a0 100644
>>>> --- a/arch/arm/mach-omap2/timer.c
>>>> +++ b/arch/arm/mach-omap2/timer.c
>>>> @@ -63,20 +63,8 @@
>>>> #define OMAP2_32K_SOURCE "func_32k_ck"
>>>> #define OMAP3_32K_SOURCE "omap_32k_fck"
>>>> #define OMAP4_32K_SOURCE "sys_32k_ck"
>>>> -
>>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>>> -#define OMAP2_CLKEV_SOURCEOMAP2_32K_SOURCE
>>>> -#define OMAP3_CLKEV_SOURCEOMAP3_32K_SOURCE
>>>> -#define OMAP4_CLKEV_SOURCEOMAP4_32K_SOURCE
>>>> -#define OMAP3_SECURE_TIMER12
>>>> #define TIMER_PROP_SECURE "ti,timer-secure"
>>>> -#else
>>>> -#define OMAP2_CLKEV_SOURCEOMAP2_MPU_SOURCE
>>>> -#define OMAP3_CLKEV_SOURCEOMAP3_MPU_SOURCE
>>>> -#define OMAP4_CLKEV_SOURCEOMAP4_MPU_SOURCE
>>>> -#define OMAP3_SECURE_TIMER1
>>>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
>>>> -#endif
>>>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
>>>
>>> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
>>> "ti,timer-secure" and "ti,timer-alwon" directly?
>>>
>>> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
>>> was to drop this and use the property string directly to remove any
>>> abstraction.
>>
>> Well, I don't understand what do you mean by "any abstraction".
>> The purpose of defining those two was to eliminate multiple occurrences
>> of the string in the code, so for example if someone decides to change the
>> property string for some currently unknown reason - it will be easy and
>> small.
>> Defines are a common practice for that, no?
>> If you still think it should be inlined, I will do.
>
> I understand your point, but right now I don't anticipate that we will
> have many options here and so I think that we should drop these.
>
>>>> #define REALTIME_COUNTER_BASE 0x48243200
>>>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
>>>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
>>>>
>>>>/* If we are a secure device, remove any secure timer nodes */
>>>>if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
>>>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
>>>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
>>>>if (np)
>>>>of_node_put(np);
>>>>}
>>>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>>>return 0;
>>>> }
>>>
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/08/12 18:20, Tony Lindgren wrote: > * Igor Grinberg [121107 23:15]: >> On 11/07/12 19:33, Tony Lindgren wrote: >>> >>> I think this should be the default for the timers as that counter >>> does not stop during deeper idle states. >> >> Well, it is the default as you can see from the patch. >> The problem is that for boards that for some reason do not have >> the 32k wired and rely on MPU/GP timer source, the default will not work >> and currently there is no way for board to specify which timer source >> it can use. > > Yes. I was just wondering if we can avoid patching all the board > files by doing it the other way around by introducing a new > omap_gp_timer rather than renaming all the existing ones? Is the renaming that bad? One line per machine_desc structure? Of course we can skip the renaming, but then it will be less consistent and will not reflect the actual timer source used. I tried to make it flexible as much as possible and self explanatory. So above are my considerations, but at this point in time I don't really care if we rename them or just add a new one, but we have to get rid of the ugly fall back. > >> We have discussed this in San Diego (remember?) and you actually proposed >> this way as a solution. Well, may be I took it a bit further than you >> thought, but this is because the board code cannot know which timer source >> should be used at runtime and the fall back described below, does not work. > > Yes thanks I agree we should get rid of that Kconfig option for sure. > >>>> --- a/arch/arm/mach-omap2/board-2430sdp.c >>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c >>>> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board") >>>>.handle_irq = omap2_intc_handle_irq, >>>>.init_machine = omap_2430sdp_init, >>>>.init_late = omap2430_init_late, >>>> - .timer = &omap2_timer, >>>> + .timer = &omap2_sync32k_timer, >>>>.restart= omap_prcm_restart, >>>> MACHINE_END >>>> --- a/arch/arm/mach-omap2/board-3430sdp.c >>>> +++ b/arch/arm/mach-omap2/board-3430sdp.c >>>> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board") >>>>.handle_irq = omap3_intc_handle_irq, >>>>.init_machine = omap_3430sdp_init, >>>>.init_late = omap3430_init_late, >>>> - .timer = &omap3_timer, >>>> + .timer = &omap3_sync32k_timer, >>>>.restart= omap_prcm_restart, >>>> MACHINE_END >>> ... >>> >>> Can't we assume that the default timer is omap[234]_sync32k_timer to >>> avoid renaming the timer entries in all the board files? >> >> Hmmm... >> How will this work with the macros defining the sys_timer structure? >> I would also not want to hide the exact timer used under the default name. > > Can't you just add a new sys_timer (or a new macro) for GP only setups? Of course I can... but I tried to create a flexible generic code, so no meter how a board will be wired, you just need to specify which timer source it uses and be done with it. > >>> Then we just need a new timer entries for the hardware that does >>> not have the sycn32k_timer available? >> >> Well, I tried to make it small patch just for the hardware that needs it, >> but I always found some corner case where, IMHO, this does not work/look >> good. > > Can you explain a bit further? Yes, OMAP4 has its own "local" timer function, OMAP5 - the real time timer function, we have that fall back from 32k to gptimer for AM33xx and we also have the use_gptimer_clksrc parameter. All the above call the same timer source init functions at the end. > > I guess what I'm after is just to avoid renaming the existing > timers in the board-*.c files and only rename the ones that > need gp timer only. This means: get rid of the 32k to gptimer fall back. I've got your point, will cook something shortly. -- 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: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/07/12 23:36, Jon Hunter wrote:
> Hi Igor,
>
> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
>> setting.
>> To remove the dependancy, several conversions/additions had to be done:
>> 1) Timer structures and initialization functions are named by the platform
>>name and the clock source in use. The decision which timer is
>>used is done statically from the machine_desc structure. In the
>>future it should come from DT.
>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
>>separate timer structures along with the timer init functions.
>>This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
>> 3) Since we have all the timers defined inside machine_desc structure
>>and we no longer need the fallback to gp_timer clock source in case
>>32k_timer clock source is unavailable (namely on AM33xx), we no
>>longer need the #ifdef around __omap2_sync32k_clocksource_init()
>>function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
>>__omap2_sync32k_clocksource_init() function.
>>
>> Signed-off-by: Igor Grinberg
>> Cc: Jon Hunter
>> Cc: Santosh Shilimkar
>> Cc: Vaibhav Hiremath
>
> [snip]
>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index 684d2fc..a4ad7a0 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -63,20 +63,8 @@
>> #define OMAP2_32K_SOURCE"func_32k_ck"
>> #define OMAP3_32K_SOURCE"omap_32k_fck"
>> #define OMAP4_32K_SOURCE"sys_32k_ck"
>> -
>> -#ifdef CONFIG_OMAP_32K_TIMER
>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
>> -#define OMAP3_SECURE_TIMER 12
>> #define TIMER_PROP_SECURE "ti,timer-secure"
>> -#else
>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
>> -#define OMAP3_SECURE_TIMER 1
>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
>> -#endif
>> +#define TIMER_PROP_ALWON"ti,timer-alwon"
>
> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
> "ti,timer-secure" and "ti,timer-alwon" directly?
>
> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
> was to drop this and use the property string directly to remove any
> abstraction.
Well, I don't understand what do you mean by "any abstraction".
The purpose of defining those two was to eliminate multiple occurrences
of the string in the code, so for example if someone decides to change the
property string for some currently unknown reason - it will be easy and small.
Defines are a common practice for that, no?
If you still think it should be inlined, I will do.
>
>> #define REALTIME_COUNTER_BASE 0x48243200
>> #define INCREMENTER_NUMERATOR_OFFSET0x10
>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
>>
>> /* If we are a secure device, remove any secure timer nodes */
>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
>> -np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
>> +np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
>> if (np)
>> of_node_put(np);
>> }
>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_OMAP_32K_TIMER
>> /* Setup free-running counter for clocksource */
>> -static int __init omap2_sync32k_clocksource_init(void)
>> +static int __init __omap2_sync32k_clocksource_init(void)
>
> Not sure I follow why you renamed this function here ...
I didn't want to add unused arguments to this function, so I've made a
wrapper below to have both the sync32k and the gp functions have the same
signature (argument list) and be called from a single macro.
Anyway, see below.
>
>> {
>> int ret;
>> struct device_node *np = NULL;
>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
>>
>> return ret;
>> }
>> -#else
>> -static inline int omap2_sync32k_clocksource_init(void)
>> -{
>> -return -ENODEV;
>> -}
>> -#endif
&g
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On 11/07/12 19:33, Tony Lindgren wrote: > * Igor Grinberg [121107 06:44]: >> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. >> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER >> setting. >> To remove the dependancy, several conversions/additions had to be done: >> 1) Timer structures and initialization functions are named by the platform >>name and the clock source in use. The decision which timer is >>used is done statically from the machine_desc structure. In the >>future it should come from DT. >> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into >>separate timer structures along with the timer init functions. >>This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. > > I think this should be the default for the timers as that counter > does not stop during deeper idle states. Well, it is the default as you can see from the patch. The problem is that for boards that for some reason do not have the 32k wired and rely on MPU/GP timer source, the default will not work and currently there is no way for board to specify which timer source it can use. We have discussed this in San Diego (remember?) and you actually proposed this way as a solution. Well, may be I took it a bit further than you thought, but this is because the board code cannot know which timer source should be used at runtime and the fall back described below, does not work. > >> 3) Since we have all the timers defined inside machine_desc structure >>and we no longer need the fallback to gp_timer clock source in case >>32k_timer clock source is unavailable (namely on AM33xx), we no >>longer need the #ifdef around __omap2_sync32k_clocksource_init() >>function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the >>__omap2_sync32k_clocksource_init() function. >> >> Signed-off-by: Igor Grinberg >> Cc: Jon Hunter >> Cc: Santosh Shilimkar >> Cc: Vaibhav Hiremath >> --- >> Finally I'm sending this out... >> I've lost following Tony's branches and deciding which one to base on, >> so I used linux-omap/master as a base for the patch. >> Tony, tell me if you want it based on some other branch. >> This has been compile tested on omap1|2plus_defconfig only. > > Yes sorry it's been a bit crazy with branches to get this > header clean up done.. If it applies to master it should > be easy to apply on others. No problem ;-) > >> --- a/arch/arm/mach-omap2/board-2430sdp.c >> +++ b/arch/arm/mach-omap2/board-2430sdp.c >> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board") >> .handle_irq = omap2_intc_handle_irq, >> .init_machine = omap_2430sdp_init, >> .init_late = omap2430_init_late, >> -.timer = &omap2_timer, >> +.timer = &omap2_sync32k_timer, >> .restart= omap_prcm_restart, >> MACHINE_END >> --- a/arch/arm/mach-omap2/board-3430sdp.c >> +++ b/arch/arm/mach-omap2/board-3430sdp.c >> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board") >> .handle_irq = omap3_intc_handle_irq, >> .init_machine = omap_3430sdp_init, >> .init_late = omap3430_init_late, >> -.timer = &omap3_timer, >> +.timer = &omap3_sync32k_timer, >> .restart= omap_prcm_restart, >> MACHINE_END > ... > > Can't we assume that the default timer is omap[234]_sync32k_timer to > avoid renaming the timer entries in all the board files? Hmmm... How will this work with the macros defining the sys_timer structure? I would also not want to hide the exact timer used under the default name. > > Then we just need a new timer entries for the hardware that does > not have the sycn32k_timer available? Well, I tried to make it small patch just for the hardware that needs it, but I always found some corner case where, IMHO, this does not work/look good. -- 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+: timer: remove CONFIG_OMAP_32K_TIMER
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer structures and initialization functions are named by the platform name and the clock source in use. The decision which timer is used is done statically from the machine_desc structure. In the future it should come from DT. 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into separate timer structures along with the timer init functions. This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. 3) Since we have all the timers defined inside machine_desc structure and we no longer need the fallback to gp_timer clock source in case 32k_timer clock source is unavailable (namely on AM33xx), we no longer need the #ifdef around __omap2_sync32k_clocksource_init() function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the __omap2_sync32k_clocksource_init() function. Signed-off-by: Igor Grinberg Cc: Jon Hunter Cc: Santosh Shilimkar Cc: Vaibhav Hiremath --- Finally I'm sending this out... I've lost following Tony's branches and deciding which one to base on, so I used linux-omap/master as a base for the patch. Tony, tell me if you want it based on some other branch. This has been compile tested on omap1|2plus_defconfig only. arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-3630sdp.c|2 +- arch/arm/mach-omap2/board-4430sdp.c|2 +- arch/arm/mach-omap2/board-am3517crane.c|2 +- arch/arm/mach-omap2/board-am3517evm.c |2 +- arch/arm/mach-omap2/board-apollon.c|2 +- arch/arm/mach-omap2/board-cm-t35.c | 18 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-generic.c| 14 ++-- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |4 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3encore.c|2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3logic.c |4 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-omap4pcm049.c|2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rm680.c |4 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/board-ti8168evm.c |4 +- arch/arm/mach-omap2/board-zoom.c |4 +- arch/arm/mach-omap2/common.h | 17 ++- arch/arm/mach-omap2/timer.c| 162 ++-- arch/arm/plat-omap/Kconfig |5 + 32 files changed, 147 insertions(+), 137 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index d1c0162..90c1584 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board") .handle_irq = omap2_intc_handle_irq, .init_machine = omap_2430sdp_init, .init_late = omap2430_init_late, - .timer = &omap2_timer, + .timer = &omap2_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 79fd904..e14b355 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board") .handle_irq = omap3_intc_handle_irq, .init_machine = omap_3430sdp_init, .init_late = omap3430_init_late, - .timer = &omap3_timer, + .timer = &omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index 81871b1..030d292 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -211,6 +211,6 @@ MACHINE_START(OMAP_3630SDP, "OMAP 3630SDP board") .handle_irq = omap3_intc_handle_irq, .init_machine = omap_sdp_init, .init_late = omap3630_init_late, - .timer = &omap3_timer, + .timer = &omap3_sync32k_timer, .restart= omap_prcm_restart, MACHINE_END diff --git a/arch/arm/ma
Re: [PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
Cc: Tony Lindgren, Afzal Mohammed,
On 11/06/12 12:51, Matthieu CASTET wrote:
> This allow to clean the omap nand driver that were trying in x8 and x16 bits
> mode.
>
> This also make work onfi detection on beagleboard :
>
> Before :
> [1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND
> 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64
>
> After :
> [1.914825] ONFI param page 0 valid
> [1.919158] ONFI flash detected
> [1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
> MT29F2G16ABD), page size: 2048, OOB size: 64
>
> platform data devsize is renamed bussize. It now indicate the maximun size of
> the nand bus.
>
> Signed-off-by: Matthieu CASTET
I think, you should base on one of Tony's branches with that kind of patches.
Because, for example the omap_nand_flash_init() function does not exist anymore
in Tony's master and may be several more things will need to have adjustments.
Also, the GPMC related stuff inside the NAND driver
should probably be coordinated with Afzal, as he is reworking the whole
GPMC related code.
> ---
> arch/arm/mach-omap2/board-3630sdp.c |2 +-
> arch/arm/mach-omap2/board-devkit8000.c |2 +-
> arch/arm/mach-omap2/board-flash.c|8 ++---
> arch/arm/mach-omap2/board-igep0020.c |2 +-
> arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> arch/arm/mach-omap2/board-omap3evm.c |2 +-
> arch/arm/mach-omap2/board-omap3pandora.c |2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
> arch/arm/mach-omap2/board-zoom.c |2 +-
> arch/arm/mach-omap2/common-board-devices.c |2 +-
> arch/arm/mach-omap2/gpmc-nand.c |5 ---
> drivers/mtd/nand/omap2.c | 42
> ++
> include/linux/platform_data/mtd-nand-omap2.h |7 -
> 13 files changed, 42 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c
> b/arch/arm/mach-omap2/board-3630sdp.c
> index fc224ad..d7b981b 100644
> --- a/arch/arm/mach-omap2/board-3630sdp.c
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -198,7 +198,7 @@ static void __init omap_sdp_init(void)
> h8mbx00u0mer0em_sdrc_params);
> zoom_display_init();
> board_smc91x_init();
> - board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
> + board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_OMAP_BUS_16);
> enable_board_wakeup_source();
> usbhs_init(&usbhs_bdata);
> }
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c
> b/arch/arm/mach-omap2/board-devkit8000.c
> index 1fd161e..b3487e1 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -621,7 +621,7 @@ static void __init devkit8000_init(void)
>
> usb_musb_init(NULL);
> usbhs_init(&usbhs_bdata);
> - omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
> + omap_nand_flash_init(NAND_OMAP_BUS_16, devkit8000_nand_partitions,
>ARRAY_SIZE(devkit8000_nand_partitions));
> omap_twl4030_audio_init("omap3beagle");
>
> diff --git a/arch/arm/mach-omap2/board-flash.c
> b/arch/arm/mach-omap2/board-flash.c
> index 0cabe61..488a1fa 100644
> --- a/arch/arm/mach-omap2/board-flash.c
> +++ b/arch/arm/mach-omap2/board-flash.c
> @@ -133,12 +133,12 @@ static struct omap_nand_platform_data board_nand_data =
> {
>
> void
> __init board_nand_init(struct mtd_partition *nand_parts,
> - u8 nr_parts, u8 cs, int nand_type)
> + u8 nr_parts, u8 cs, int bus_type)
> {
> board_nand_data.cs = cs;
> board_nand_data.parts = nand_parts;
> board_nand_data.nr_parts= nr_parts;
> - board_nand_data.devsize = nand_type;
> + board_nand_data.bussize = bus_type;
>
> board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
> gpmc_nand_init(&board_nand_data);
> @@ -185,7 +185,7 @@ unmap:
> * @return - void.
> */
> void __init board_flash_init(struct flash_partitions partition_info[],
> - char chip_sel_board[][GPMC_CS_NUM], int nand_type)
> + char chip_sel_board[][GPMC_CS_NUM], int bus_type)
> {
> u8 cs = 0;
> u8 norcs = GPMC_CS_NUM + 1;
> @@ -238,5 +238,5 @@ void __init board_flash_init(struct flash_partitions
> partition_info[],
> pr_err("NAND: Unable to find configuration in GPMC\n");
> else
> board_nand_init(partition_info[2].parts,
> - partition_info[2].nr_parts, nandcs, nand_type);
> + partition_info[2].nr_parts, nandcs, bus_type);
> }
> diff --git a/arch/arm/mach-omap2/board-igep0020.c
> b/arch/arm/mach-omap2/board-igep0020.c
> index 48d5e41..732f183 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/ar
Re: OMAP baseline test results for v3.7-rc2
On 10/23/12 20:19, Kevin Hilman wrote: > Kevin Hilman writes: > >> +Igor >> >> Paul Walmsley writes: >> >>> Here are some basic OMAP test results for Linux v3.7-rc2. >>> Logs and other details at: >>> >>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/ >> >> [...] >> >>> * 37xx EVM: CORE not entering dynamic off-idle >>> - Cause unknown; dynamic retention-idle seems to work; system suspend to >>> off works >> >> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that >> SPI1 was not idle when going off. A quick hack disabling the >> touchscreen showed that after that, core was hitting idle just fine. >> >> I ran out of time today debugging this, but it's definitely realted to >> the GPIO debounce setting for the touchscreen. Changing it to zero[1] >> makes CORE hit retention again in idle. > > OK, found the root cause of this in the GPIO driver. Patch submitted: > > http://marc.info/?l=linux-omap&m=135101577925972&w=2 Ok that one looks good. > > however... > >> Igor, I'm hoping you might know what's going on here since we already >> had some problems with this ads7846 init stuff and you're more familiar >> with this debounce init. > > ... board files that are setting debounce values for ads7846 will no > longer work. > > Currently, omap_ads7846_init() in common-board-devices.c does this: > >gpio_request_one() >gpio_set_debounce() >gpio_free() > > because of a bug in the GPIO driver, the debounce settings were sticky > and lingered even after the gpio_free(). That bug has been fixed by the > above patch, which means the above gpio_set_debounce() is completely > pointless because it's followed immediately by a gpio_free(). > > IMO, the whole GPIO init for the ads7846 needs a rethink as it's > currently partially done by common-board-devices.c and done (again) in > the ads7846 driver. If the gpio_free() isn't done in > common-board-devices, then the ads7846 driver will currently fail to > probe/load becasue it can't request a GPIO line. > > Having found and fixed the PM regression, I'll leave the ads7846 cleanup to > somone else. Ok, understood, I'll look into this one soon. -- 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
