Re: [PATCH 04/18] ARM: am57xx: cl-som-am57x: dts: add EEPROM support

[Igor Grinberg]

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 v2 04/18] ARM: am57xx: cl-som-am57x: dts: add EEPROM support

[Igor Grinberg]

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 <lifsh...@compulab.co.il>

Acked-by: Igor Grinberg <grinb...@compulab.co.il>

> ---
> 
>   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 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Igor Grinberg]

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 @@

[...]

> +_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

[Igor Grinberg]

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 t.rem...@phytec.de
 ---
  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

[Igor Grinberg]

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 j-keer...@ti.com 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

[Igor Grinberg]

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 sakari.ai...@iki.fi
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Igor Grinberg grinb...@compulab.co.il

For cm-t35 stuff:

Acked-by: Igor Grinberg grinb...@compulab.co.il

-- 
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

[Igor Grinberg]

Hi Dima,

On 12/28/14 15:15, Dmitry Lifshitz wrote:
 Add NAND support
 
 Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
 ---
  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 v2] ARM: dts: cm-t3x: add NAND support

[Igor Grinberg]

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 lifsh...@compulab.co.il

Acked-by: Igor Grinberg grinb...@compulab.co.il


-- 
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

[Igor Grinberg]

-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 ba...@ti.com [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 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?

 
 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?

 
 (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?

 
 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 thing you can do.

Hmmm... Interesting, so people should not use mainline.

 You should at a minimum provide your
 customers with a more minimal rootfs. Why would you have

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Igor Grinberg]

-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 ba...@ti.com [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

[Igor Grinberg]

-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 thing you can do.

 Hmmm... Interesting, so people should not use mainline.
 
 now you're reading what you want to read ;-) Using my statements out of
 context.

I'm sorry, but you seemed to not care about the context, but just call
stuff a BS or worst thing to do... and that is w/o even understanding
the case.

 
 It's clear (actually s/rootfs/defconfig below) that I meant defconfig.
 

Well, no, I'm sorry it is not clear, but I accept the amendment.

 You should at a minimum provide your
 customers with a more minimal rootfs. Why would you have your customers
 
 oh wait, not rootfs, defconfig.
 
 build MUSB on an OMAP5 board ? Why would they build 5 different
 network device drivers ? Why would they build almost every single PMIC
 we ever used ? The list goes on and on.

 That is their decision to make. I'm just saying that they can use it.
 
 right, and they can switch SATA to built-in if they want to ship an
 initramfs-less product, don't you think ?

no. It *very* depends on who your customer is and sometimes compiling
kernel with provided defaults is fine, but changing those is not.
You can say, come on... if they build the kernel, they can also change

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Igor Grinberg]

Hi Tony,

On 12/24/14 21:04, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [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

[Igor Grinberg]

-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

[Igor Grinberg]

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

[Igor Grinberg]

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

[Igor Grinberg]

Hi Tony,

On 11/10/14 19:48, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 lifsh...@compulab.co.il

 Acked-by: Igor Grinberg grinb...@compulab.co.il
 
 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 v2] ARM: dts: sbc-t3x: add DVI display data

[Igor Grinberg]

On 11/11/14 16:49, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [14 04:04]:
 Hi Tony,

 On 11/10/14 19:48, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 lifsh...@compulab.co.il

 Acked-by: Igor Grinberg grinb...@compulab.co.il

 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] mfd: twl4030-power: Fix poweroff with PM configuration enabled

[Igor Grinberg]

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 rmk+ker...@arm.linux.org.uk
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 --- 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] mfd: twl4030-power: Fix poweroff with PM configuration enabled

[Igor Grinberg]

On 11/04/14 17:42, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 v2] ARM: dts: sbc-t3x: add DVI display data

[Igor Grinberg]

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 lifsh...@compulab.co.il

Acked-by: Igor Grinberg grinb...@compulab.co.il


-- 
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

[Igor Grinberg]

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 lifsh...@compulab.co.il
 ---
  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
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.17-rc3

[Igor Grinberg]

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

[Igor Grinberg]

On 03/12/14 19:44, Tony Lindgren wrote:
 * Stefan Roese s...@denx.de [140312 03:52]:
 Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
 on the CM-T3530 SOM.

 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Dmitry Lifshitz lifsh...@compulab.co.il
 Cc: Igor Grinberg grinb...@compulab.co.il
 Cc: Tony Lindgren t...@atomide.com

Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
 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

[Igor Grinberg]

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] 6Waiting 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: Help needed USB hub disconnected at resume

[Igor Grinberg]

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] 6Waiting 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

Re: [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards

[Igor Grinberg]

On 03/01/14 00:12, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 00/11] ARM: dts: sbc-t3x: add support for more boards

[Igor Grinberg]

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] arm: dts: Add support for Compulab sbc-t3530 with cm-t35

[Igor Grinberg]

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 s...@denx.de
 Cc: Igor Grinberg grinb...@compulab.co.il
 Cc: Dmitry Lifshitz lifsh...@compulab.co.il
 Cc: Tony Lindgren t...@atomide.com
 ---
  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_163 */
 - ;
 - };
 -
 - uart3_pins: pinmux_uart3_pins {
 - pinctrl-single,pins = 
 - 0x16e (PIN_INPUT | MUX_MODE0)   /* 
 uart3_rx_irrx.uart3_rx_irrx */
 - 0x170 (PIN_OUTPUT | MUX_MODE0)  /* 
 uart3_tx_irtx.uart3_tx_irtx */
 + 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

Re: [PATCH 1/5] ARM: omap2: cm-t35: Add regulators and clock for camera sensor

[Igor Grinberg]

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 laurent.pinch...@ideasonboard.com

Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
  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 linux/clk-provider.h
 +#include linux/clkdev.h
  #include linux/kernel.h
  #include linux/init.h
  #include linux/platform_device.h
 @@ -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

[Igor Grinberg]

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 pebo...@tiscali.nl
 ---
 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

[Igor Grinberg]

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

[Igor Grinberg]

On 12/17/13 21:31, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [131216 23:16]:
 On 12/16/13 21:17, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 t...@atomide.com
 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
 instead of the smsc911x.
 
 Cc: devicet...@vger.kernel.org
 Cc: Igor Grinberg grinb...@compulab.co.il
 Cc: Mike Rapoport m...@compulab.co.il
 Signed-off-by: Tony Lindgren t...@atomide.com

Acked-by: Igor Grinberg grinb...@compulab.co.il

This one looks great!
Really minor comments below (we can fix those later)

[...]

 diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts 
 b/arch/arm/boot/dts/omap3-cm-t3730.dts
 new file mode 100644
 index 000..80cf668
 --- /dev/null
 +++ b/arch/arm/boot/dts/omap3-cm-t3730.dts

[...]

 +mmc1 {
 + vmmc-supply = vmmc1;
 + vmmc_aux-supply = vsim;

vsim is not present in TPS65930...
can be just left empty or set to a fixed voltage regulator.

 + bus-width = 4;
 + pinctrl-names = default;
 + pinctrl-0 = mmc1_pins;
 +};

[...]

 diff

Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730

[Igor Grinberg]

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

[Igor Grinberg]

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 grinb...@compulab.co.il
 Cc: Mike Rapoport m...@compulab.co.il
 Signed-off-by: Tony Lindgren t...@atomide.com

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: regulator-vddvario {
 + compatible = regulator-fixed;
 + regulator-name = vddvario;
 + regulator-always-on;
 + };
 +
 + vdd33a: regulator-vdd33a {
 + compatible = regulator-fixed;
 + regulator-name = vdd33a;
 + regulator-always-on;
 + };
 +};
 +
 +gpmc {
 + ranges = 5 0 0x2c00 0x0100,
 +  4 0

Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730

[Igor Grinberg]

On 12/16/13 21:17, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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
 +
 +
 +/ {
 +   model = CompuLab SBC-T3517 with CM-T3517;
 +   compatible = compulab,omap3-sbc-t3517, ti,am3517, ti,omap3;
 +
 +   memory {
 +   device_type = memory;
 +   reg = 0x8000 0x1000; /* 256 MB */

 Can we support multiple memory sizes through static DT, or
 the only way is to update this property in the bootloader?
 
 Well we should probably have a minimal .dts file for the variants
 too that can include omap3-cm-t37.dts and so on. I guess some
 bootloaders are capable of rewriting the .dtb too.

Ok. So what do you think, is it fine to have something like:
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-256mb.dts   - sb-t35 with cm-t3730 and 256MB memory size
omap3-sbc-t3730-128mb.dts   - sb-t35 with cm-t3730 and 128MB memory size
omap3-sbc-t3730-64mb.dts- sb-t35 with cm-t3730 and 64MB memory size
omap3-sbc-t3530-256mb.dts

Re: [PATCH] ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init()

[Igor Grinberg]

On 10/25/13 11:31, Wei Yongjun wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 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 yongjun_...@trendmicro.com.cn

Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
  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

[Igor Grinberg]

-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 lifsh...@compulab.co.il
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 lifsh...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
 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: invert PD pin logic level (0 - is a power on state)
+ * @latch_on_rising_edge : select the edge (0 - falling, 1 - rising) of the input clock

Re: Request for OMAPDSS testing

[Igor Grinberg]

-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

[Igor Grinberg]

-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

[Igor Grinberg]

-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

[Igor Grinberg]

On 04/17/13 04:30, Robert Nelson wrote:
 On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren t...@atomide.com wrote:
 * Roger Quadros rog...@ti.com [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 b-cous...@ti.com
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  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] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx

[Igor Grinberg]

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 t...@atomide.com wrote:
 * Roger Quadros rog...@ti.com [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 b-cous...@ti.com
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling

[Igor Grinberg]

-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 tomi.valkei...@ti.com
 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 t...@atomide.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com

Looks good, thanks!

Acked-by: Igor Grinberg grinb...@compulab.co.il

 
 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);
   if (err) {
   pr_err(CM-T35: failed to register DSS device\n);
 - gpio_free_array(cm_t35_dss_gpios, ARRAY_SIZE(cm_t35_dss_gpios));
 + gpio_free(CM_T35_LCD_EN_GPIO);
   }
  }
  
 
 

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRXSjtAAoJEBDE8YO64EfakqEP/RxTWET2KP1KRIs5VW6o6JXG
w4Mil7k62AmpClojEWMJTF6UfOc08Zmg4m5ZPly1mT2NAgwtwStP1hkTRuPuL34w
NMfbwro5uUf4Wp49ZxZyuLLEnlzVh8VPWPmHKc+pRl9XQOqS9fau+EBxmIXKSAgC

Re: [PATCH 00/28] OMAP: DSS related board file changes

[Igor Grinberg]

-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 drivers
 to handle the hotplug/unplug.

Yep, I don't see any problem with having board specific drivers.
Multiple subsystems have them, so we also can have them in CDF.

 
 And we probably need some way to show the information about possible
 displays to the userspace. I mean, with a case like DVI/Panel on the
 board, it would make sense to show the userspace that there are those
 two options, even if the other device is not even present.

Indeed this is needed for the runtime switch.


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWplwAAoJEBDE8YO64EfaKH4P/jaMuXrGyvCmfYgD5OLFU0fV
BvsLyy0/DVqoDjB2N8YH8PnuixKrP17L8nEDckq725byXf/ZQEIaYTeyBZ/COYDD
NGAkVn8sFe2w7FLsg+dVa2+GSgYL2Pprvvf4DrJy1JMepBsDlaSkZL7V5LOq7m7J
7PIMizeZIngeDy4OHu4BNAksylPUj/3iqPDGJ9BZpgzoj1TwbPDG/ECyKADD9J8+
JHrK+aSnJFI/5qE+J1j+6ghYhDnIz5OQqtjA

Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Igor Grinberg]

-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

[Igor Grinberg]

-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 display manager
(may be a part of CDF) that will deal with the device registration/removal
and board specific drivers should implement some kind of API of the
generic display manger.

 
 Well, actually, if there was a way to add a device while somehow marking
 it so that no driver will be bound to it... Then the user could use the
 standard sysfs interface to bind a driver to the device. I wonder if
 that could be done...

I don't think this can fit current platform device framework.
But may

Re: [PATCH 00/28] OMAP: DSS related board file changes

[Igor Grinberg]

On 03/28/13 18:57, Tony Lindgren wrote:
 * Tomi Valkeinen tomi.valkei...@ti.com [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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Igor Grinberg]

-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: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRV/8gAAoJEBDE8YO64EfaGOQQAIEnXwrHiZFlsMkCo5n8uUok
qBBvEoFh5s1h2aaDNna3Q7tvKF42UlaGtZPqwl5bDUHimcEaLnNPy14MQJ/w/dHN
AvDaI2ZoqGCYDVjVa0KUCWqL6Chm7ZpAoU9NeY3T3+U8S7kIeizz0oBJKoZ4bfpk
g6Kq5vnbi36pCWFMqQe+7fEn5CHJNHTp+miPpq3Dsed2zkVgIg9re0nTxpQjlDHO
+kLwJjrHbCqZoBMzE0MacaibROiHhccQ9Xtf25iVemyHQ6CP6g+ibJduFF7S4pOk
kOwH1NY2QiFGDyA0Tj+kuYsbUYe3E1ds7FCu0/9g2KpiGRqSAqrFDghJzj1PojL

Re: [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices

[Igor Grinberg]

On 03/28/13 14:48, Tomi Valkeinen wrote:
 From: Archit Taneja arc...@ti.com
 
 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 arc...@ti.com
 Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com

This should have been done long long time ago...
Thanks!

Acked-by: Igor Grinberg grinb...@compulab.co.il


-- 
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

[Igor Grinberg]

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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Igor Grinberg]

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: OMAP baseline test results for v3.9-rc1

[Igor Grinberg]

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

[Igor Grinberg]

-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

[Igor Grinberg]

-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 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.
 
 As I said, reliable vs unreliable. That's not insane.
 
 But again, if you can handle this particular panel reliably with the
 two-driver approach, I'm fine with it.

Again, it works reliably on other platforms,
why would OMAP be an exception?

 
 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.
 
 Yes, that sounds ok

Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling

[Igor Grinberg]

-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 proper support...


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRHNqRAAoJEBDE8YO64Efac08QAKBgU7xFkdBHU0ekAgRIafhO
kd0EgPXwPZDvuAaoj5pzdMI65alRSuoQxp5ohHyz0aFfGRk0Q66f6/zXzTsGXPLP
pRTkqGGTHD5Qtv2IvhHPvLMRGW+87QiuK0NU0BJqV/1JRPz1UyKMJrwc5U3Acf4J
B7bQnWLlIcPftIt2zHwuvZZMYZUL8f5/dXGWMhxmTF7rse7YcTjCwQO4eabTIX5r
/GUanF+qlwKJzk7nxQR1DFQdN+7Vv8vdumJi38sq9fouLgXlhmzOgXvxMgT7lq8T
l+7Bg7l+E9yrHaXmWf3zjZBAk6/wBnzzrmmK5V6Gjg2PiEh6Rs5ARWPrdc/FQCpt
4bXTKEktLonHj2rya8intrPLw7lP4AQN81QsQOLeRIPGoSCcDsi4RGAFrWdXR0Xt
Du9ea/liAD3

Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling

[Igor Grinberg]

-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

[Igor Grinberg]

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 t...@atomide.com
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  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 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling

[Igor Grinberg]

-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 V3 5/7] ARM: OMAP3: Update clocksource timer selection

[Igor Grinberg]

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 jon-hun...@ti.com
 ---
  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 V3 5/7] ARM: OMAP3: Update clocksource timer selection

[Igor Grinberg]

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 jon-hun...@ti.com
 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 jon-hun...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Acked-by: Igor Grinberg grinb...@compulab.co.il
 ---
  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_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,
 \
 -clksrc_nr, clksrc_src)   \
 +clksrc_nr, clksrc_src, clksrc_prop)  \
  void __init omap##name##_gptimer_timer_init(void)\
  {\
   omap_dmtimer_init

Re: [PATCH] ARM: OMAP2+: Get rid of custom OMAP_32K_TIMER_HZ

[Igor Grinberg]

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 a...@arndb.de
 Cc: Russell King li...@arm.linux.org.uk
 Cc: John Stultz john.stu...@linaro.org
 Cc: Tony Lindgren t...@atomide.com

If it still not too late:
Acked-by: Igor Grinberg grinb...@compulab.co.il

 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 Tested-by: Lokesh Vutla lokeshvu...@ti.com
 ---
  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 5/5] ARM: OMAP3: Update clocksource timer selection

[Igor Grinberg]

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 jon-hun...@ti.com

Apart from above,
Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
  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 4/5] ARM: OMAP2+: Simplify system timers definitions

[Igor Grinberg]

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 jon-hun...@ti.com

Acked-by: Igor Grinberg grinb...@compulab.co.il


-- 
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.

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It looks like Kevin has a new address:
Kevin Hilman khil...@deeprootsystems.com

On 01/21/13 23:38, NeilBrown wrote:
 On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il
 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 ne...@suse.de

 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 v2] ARM: OMAP3: cm-t3517: add MMC support

[Igor Grinberg]

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 grinb...@compulab.co.il
 ---
 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 linux/mtd/mtd.h
  #include linux/mtd/nand.h
  #include linux/mtd/partitions.h
 +#include linux/mmc/host.h
  #include linux/can/platform/ti_hecc.h
  
  #include asm/mach-types.h
 @@ -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.

[Igor Grinberg]

-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 ne...@suse.de
 
 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

[Igor Grinberg]

-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 grinb...@compulab.co.il
 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
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
 grinb...@compulab.co.il
 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

[Igor Grinberg]

-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 grinb...@compulab.co.il
 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 grinb...@compulab.co.il
 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
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg 
 grinb...@compulab.co.il
 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.
 
 Interesting thanks.  That makes a certain amount of sense.
 
 However I tried compiling ehci-hcd as a module and  unload/reloading it which
 should have a similar net effect to what you did, but it didn't make any
 difference - device disappears on resume.

Yes it does for cm-t3730, in fact, that is what we have started from...

 
 I also tried restoring the correct value to EHCI_INSNREG04 and
 EHCI_INSNREG05_ULPI which are the only registers written by 
 ehci-omap.c, and that didn't help either.
 
 The only thing I've found that works is keeping 'core' out of off-mode.

Ah, one more thing, we ensure that phy is completely powered off through
the TPS power scripts, otherwise, it does not work...

 
 BTW I discovered that arch/arm/mach-omap2/powerdomains3xxx_data.c
 comments out the setting of 
   .flags= PWRDM_HAS_HDWR_SAR,
 for the usbhost powerdomain - that is why I had to leave it in retention.
 If I uncomment that setting, the it is safe for USBHOST to go to off-mode,
 just not for CORE.
 
 I'll keep exploring.
 
 NeilBrown
 N?§²æìr¸?yúè?Øb²X¬¶Ç§vØ^?)Þº{.nÇ+?·¥?{±¢f©?{ayºÊ?Ú?ë,j­¢f£¢·h??àz¹®w¥¢¸
 ¢·¦j:+v?¨?wèjØm¶?ÿ¾«?êçzZ+?ù???Ý¢j?ú!tml=

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ9oreAAoJEBDE8YO64EfaRasP/iUDBXhmPQtVm7ESB1DPopMc
b5dUWY1mwQGfNhdcPqApyPk5MPzHTAFfNiLTxJURUqN562gMl1+SR4Mr9cOX6ju4

Re: Help wanted with USB and OMAP3 off_mode

[Igor Grinberg]

-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: Help wanted with USB and OMAP3 off_mode

[Igor Grinberg]

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
 mich...@amarulasolutions.com wrote:

 Hi Neil

 On 01/09/2013 11:19 AM, NeilBrown wrote:
 On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg grinb...@compulab.co.il
 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: [PATCH 1/1] arm :omap :DMA: fix a bug on reserving the omap SDMA channels

[Igor Grinberg]

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 ahema...@gmail.com

 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 ahema...@gmail.com
 ---
   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

[Igor Grinberg]

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 grinb...@compulab.co.il
 ---
 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 linux/mtd/mtd.h
  #include linux/mtd/nand.h
  #include linux/mtd/partitions.h
 +#include linux/mmc/host.h
  #include linux/can/platform/ti_hecc.h
  
  #include asm/mach-types.h
 @@ -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

[PATCH v2] ARM: OMAP3: cm-t3517: add MMC support

[Igor Grinberg]

cm-t3517 uses two MMC interfaces. Add support for both.

Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
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 linux/mtd/mtd.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
+#include linux/mmc/host.h
 #include linux/can/platform/ti_hecc.h
 
 #include asm/mach-types.h
@@ -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

Re: [PATCH V3 11/11] ARM: delete struct sys_timer

[Igor Grinberg]

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 swar...@nvidia.com
 
 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 swar...@nvidia.com
 Tested-by: Robert Jarzmik robert.jarz...@free.fr
 ---
 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.c
index 

[PATCH] ARM: OMAP3: cm-t3517: add MMC support

[Igor Grinberg]

cm-t3517 uses two MMC interfaces. Add support for both.

Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
 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 linux/mtd/mtd.h
 #include linux/mtd/nand.h
 #include linux/mtd/partitions.h
+#include linux/mmc/host.h
 #include linux/can/platform/ti_hecc.h
 
 #include asm/mach-types.h
@@ -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

[Igor Grinberg]

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 grinb...@compulab.co.il
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com

Acked-by: Igor Grinberg grinb...@compulab.co.il


-- 
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

[Igor Grinberg]

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 grinb...@compulab.co.il
 
 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com

Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
  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 3/3] ARM: AM335x: Fix warning in timer.c

[Igor Grinberg]

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 grinb...@compulab.co.il

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
   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] ARM: OMAP: Conditionally compile counter_32k

[Igor Grinberg]

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 alessio.bog...@elettra.trieste.it
 ---
  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

Re: [PATCH] ARM: OMAP: Conditionally compile counter_32k

[Igor Grinberg]

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

[PATCH 0/2] ARM: OMAP: ads7846: fix pendown debounce setting

[Igor Grinberg]

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 1/2] ads7846: enable pendown GPIO debounce time setting

[Igor Grinberg]

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 grinb...@compulab.co.il
---
 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 v2 1/2] ads7846: enable pendown GPIO debounce time setting

[Igor Grinberg]

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 grinb...@compulab.co.il
---
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 v3 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

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 grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
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

[PATCH 2/2] ARM: OMAP3: cm-t3517: use GPTIMER for system clock

[Igor Grinberg]

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 grinb...@compulab.co.il
---
 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

[PATCH v2 1/2] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

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 grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
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

Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

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 grinb...@compulab.co.il [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

[Igor Grinberg]

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

[Igor Grinberg]

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

[Igor Grinberg]

On 11/08/12 18:20, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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

[Igor Grinberg]

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 grinb...@compulab.co.il
 Cc: Jon Hunter jon-hun...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Vaibhav Hiremath hvaib...@ti.com

 [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;
  }
  
 -#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.
 
 Ok.
 

  {
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
  
 -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
 -  const char *fck_source)
 +static void __init omap2_gp_clocksource_init(int gptimer_id,
 +   const char *fck_source)

 Nit, I personally prefer keeping gptimer, because gp just means
 general-purpose and does not imply a timer per-se.

 I've made this change, so we will not get something like:
 omapx_gptimer_timer_init(), but this really does not meter to me,
 so

Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

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

[Igor Grinberg]

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

[Igor Grinberg]

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

[Igor Grinberg]

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 grinb...@compulab.co.il
 Cc: Jon Hunter jon-hun...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Vaibhav Hiremath hvaib...@ti.com
 
 [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_SOURCEfunc_32k_ck
  #define OMAP3_32K_SOURCEomap_32k_fck
  #define OMAP4_32K_SOURCEsys_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_ALWONti,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
  
 -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
 -const char *fck_source)
 +static void __init omap2_gp_clocksource_init(int gptimer_id,
 + const char *fck_source)
 
 Nit, I personally prefer keeping gptimer, because gp just means
 general-purpose and does not imply a timer per-se.

I've made this change, so we will not get something like:
omapx_gptimer_timer_init(), but this really does not meter to me,
so no problem will do for v2.

 
  {
  int res;
  
 @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int 
 gptimer_id,
  gptimer_id, clksrc.rate);
  }
  
 -static void __init omap2_clocksource_init(int

[PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

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 grinb...@compulab.co.il
Cc: Jon Hunter jon-hun...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
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/mach

Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER

[Igor Grinberg]

On 11/07/12 19:33, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [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 grinb...@compulab.co.il
 Cc: Jon Hunter jon-hun...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Cc: Vaibhav Hiremath hvaib...@ti.com
 ---
 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

Re: [PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO

[Igor Grinberg]

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 matthieu.cas...@parrot.com

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/arch/arm/mach-omap2/board-igep0020.c
 @@ -175,7 +175,7 @@ static void __init 

Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable

[Igor Grinberg]

On 10/24/12 10:16, Linus Walleij wrote:
 On Tue, Oct 23, 2012 at 8:09 PM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 
 From: Kevin Hilman khil...@ti.com

 When debounce clocks are disabled, ensure that the banks
 dbck_enable_mask is cleared also.  Otherwise, context restore on
 subsequent off-mode transition will restore previous value from the
 shadow copies (bank-context.debounce*) leading to mismatch state
 between driver state and hardware state.

 This was discovered when board code was doing

   gpio_request_one()
   gpio_set_debounce()
   gpio_free()

 which was leaving the GPIO debounce settings in a confused state.
 Then, enabling off mode causing bogus state to be restored, leaving
 GPIO debounce enabled which then prevented the CORE powerdomain from
 transitioning.

 Reported-by: Paul Walmsley p...@pwsan.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com
 
 Thanks! Applied with Felipe's and Santosh's ACKs.

If not too late:
Acked-by: Igor Grinberg grinb...@compulab.co.il

Kevin, thanks for the patch and sorry I could not respond on time.

-- 
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.7-rc2

[Igor Grinberg]

On 10/23/12 20:19, Kevin Hilman wrote:
 Kevin Hilman khil...@deeprootsystems.com writes:
 
 +Igor

 Paul Walmsley p...@pwsan.com 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-omapm=135101577925972w=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