Re: [PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node

[Chanwoo Choi]

Hi,

On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
 Hi,
 
 On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
 Hi,

 On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
 Hi,

 On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
 This patch remove unnecessary function call in of_extcon_get_extcon_dev()
 by using the name of device_node structure.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/extcon/of_extcon.c | 12 ++--
  1 file changed, 2 insertions(+), 10 deletions(-)

 diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
 index 72173ec..0a29f82 100644
 --- a/drivers/extcon/of_extcon.c
 +++ b/drivers/extcon/of_extcon.c
 @@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct 
 device *dev, int index)
  {
struct device_node *node;
struct extcon_dev *edev;
 -  struct platform_device *extcon_parent_dev;
  
if (!dev-of_node) {
dev_dbg(dev, device does not have a device node entry\n);
 @@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct 
 device *dev, int index)
return ERR_PTR(-ENODEV);
}
  
 -  extcon_parent_dev = of_find_device_by_node(node);
 -  if (!extcon_parent_dev) {
 -  dev_dbg(dev, unable to find device by node\n);
 -  return ERR_PTR(-EPROBE_DEFER);
 -  }
 -
 -  edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
 +  edev = extcon_get_extcon_dev(node-name);

 Since you no longer want to use device names I think you should add this 
 too to
 warn users if they rely on using the device name.

 Previous of_extcon_get_extcon_dev() support only platform device using 
 of_find_device_by_node.

 If extcon device is based on i2c/spi/pci and so on, 
 of_extcon_get_extcon_dev() can't
 find device instance for device name. So, I change device name from the name 
 of platform device
 to the name of dt node.
 
 That's fine. But we have to fix extcon_dev_register() too, to not use device
 names right? We have to warn extcon users not to use device names right?

I don't think so. extcon_get_edev_by_phandle() shows wrong node-name as 
following:
The consumer could detect the cause of problem which can't get extcon device 
after
checking error log message.

edev = extcon_get_extcon_dev(node-name);
if (!edev) {
dev_err(dev, unable to get extcon device : %s\n, node-name);
return ERR_PTR(-ENODEV);
}

I don't want to add more log message.



 diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
 index bc4c789..025eb39 100644
 --- a/drivers/extcon/extcon-class.c
 +++ b/drivers/extcon/extcon-class.c
 @@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
 edev-dev.class = extcon_class;
 edev-dev.release = extcon_dev_release;

 -   edev-name = edev-name ? edev-name : dev_name(edev-dev.parent);
 //The user should always pass the 'name' as we no longer use device name 
 while
 getting extcon device. And this name should also be the 'node' name?
 if (IS_ERR_OR_NULL(edev-name)) {
 dev_err(edev-dev,
 extcon device name is null\n);

 Btw changing to node name from device name breaks dwc3 in OMAP5 and you 
 would
 need this too..

 diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
 index 2aea4bc..cea8cd3 100644
 --- a/drivers/extcon/extcon-palmas.c
 +++ b/drivers/extcon/extcon-palmas.c
 @@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device 
 *pdev)

 palmas_usb-edev.supported_cable = palmas_extcon_cable;
 palmas_usb-edev.dev.parent = palmas_usb-dev;
 +   palmas_usb-edev.name = palmas_usb;
 palmas_usb-edev.mutually_exclusive = mutually_exclusive;

 status = extcon_dev_register(palmas_usb-edev);

 Cheers
 Kishon


 If node name is same as extcon device name, don't need some modification.
 Also, you can modify node name in some OMAP dts file insead of modification 
 of extcon-palmas.c
 
 node name in OMAP dts is already 'palmas_usb'. But since we were not setting
 'edev.name' in extcon-palmas.c, extcon_dev_register used device name of palmas
 (palmas_usb.7 in my case). So extcon-palmas.c needs the fix.

For example,
I used extcon provider/consumer driver in dts as following:
extcon-max14577.c set device name as edev-name and then dt node name of 
max14577
set max14577-muic which is same as device name(dev_name(pdev-dev)).

I don't need to modify extcon-max14577.c

In drivers/extcon/extcon-max14577.c
...
info-edev-name = dev_name(pdev-dev);
...
In dts.
i2c@1388 {
.
max14577@25 {
.
muic: max14577-muic {
compatible = maxim,max14577-muic;
};

};
};

hsotg@1248 {
.

[PATCH v2 1/2] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Pekon Gupta]

Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]

* How to boot from NAND using Memory Expander + NAND Cape ? *
 - Important: As BOOTSEL values are sampled only at POR, so after changing any
   setting on SW2 (DIP switch), disconnect and reconnect all board power supply
   (including mini-USB console port) to POR the beaglebone.

 - Selection of ECC scheme
  for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
  for NAND cape(b), ROM code expects BCH16_HW ecc-scheme

 - Selection of boot modes can be controlled via  DIP switch(SW2) present on
   Memory Expander cape, so first boot via MMC or other sources to flash NAND
   device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
   SW2[SWITCH_BOOT] == OFF  follow default boot order  MMC- SPI - UART - USB
   SW2[SWITCH_BOOT] == ON   boot mode selected via DIP switch(SW2)

 - For NAND boot following switch settings need to be followed
   SW2[ 0] = ON   (SYSBOOT[ 0]==0: NAND boot mode selected )
   SW2[ 1] = ON   (SYSBOOT[ 1]==0:   -- do --  )
   SW2[ 2] = OFF  (SYSBOOT[ 2]==1:   -- do --  )
   SW2[ 3] = OFF  (SYSBOOT[ 3]==1:   -- do --  )
   SW2[ 4] = ON   (SYSBOOT[ 4]==0:   -- do --  )
   SW2[ 8] = OFF  (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
   SW2[ 9] = ON   (SYSBOOT[ 9]==0: ECC done by ROM  )
   SW2[10] = ON   (SYSBOOT[10]==0: Non Muxed device )
   SW2[11] = ON   (SYSBOOT[11]==0:-- do --  )

[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2] 
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module

Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++
 arch/arm/boot/dts/am335x-bone.dts |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts|   1 +
 3 files changed, 132 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts 
b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 000..9c9f6a6
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+am33xx_pinmux {
+   nand_flash_x16: nand_flash_x16 {
+   pinctrl-single,pins = 
+   0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+   0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+   0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+   0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+   0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+   0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+   0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+   0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+   0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+   0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+   0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10 
*/
+   0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11 
*/
+   0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12 
*/
+   0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13 
*/
+   0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14 
*/
+   0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15 
*/
+   0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* 
gpmc_wait0.gpmc_wait0 */
+   0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/* 
gpmc_wpn.gpio0_30 */
+   0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* 
gpmc_csn0.gpmc_csn0  */
+   0x90 (MUX_MODE0 | PIN_OUTPUT)   /* 
gpmc_advn_ale.gpmc_advn_ale */
+   0x94 (MUX_MODE0 | PIN_OUTPUT)   /* 
gpmc_oen_ren.gpmc_oen_ren */
+   0x98 (MUX_MODE0 | PIN_OUTPUT)   /* 
gpmc_wen.gpmc_wen */
+   0x9c (MUX_MODE0 | PIN_OUTPUT)

[PATCH v2 0/2] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)

[Pekon Gupta]

Series is rebased on following tree for OMAP DT
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
:omap-for-v3.15/dt

*changes v1 - v2*
[PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks
  http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon 
n...@ti.com'
  http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren 
t...@atomide.com'
[PATCH v2 2/2] same as [PATCH v1 1/3]


*original v1*
This patch-set adds parallel NAND support on following TI platforms
 - AM335x (am335x-bone LT, am335x-boneblack): disabled by default
 - AM43xx (am437x-gp-evm)

Pekon Gupta (2):
  ARM: dts: am335x-bone: add support for beaglebone NAND cape
  ARM: dts: am437x-gp-evm: add support for parallel NAND flash

 arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++
 arch/arm/boot/dts/am335x-bone.dts |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts|   1 +
 arch/arm/boot/dts/am437x-gp-evm.dts   | 107 +
 4 files changed, 239 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts

-- 
1.8.5.1.163.gd7aced9

--
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 2/2] ARM: dts: am437x-gp-evm: add support for parallel NAND flash

[Pekon Gupta]

Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board

(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 107 
 1 file changed, 107 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0   /* 
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+   nand_flash_x8: nand_flash_x8 {
+   pinctrl-single,pins = 
+   0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7)  /* 
spi2_cs0.gpio/eMMCorNANDsel */
+   0x0  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad0.gpmc_ad0 */
+   0x4  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad1.gpmc_ad1 */
+   0x8  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad2.gpmc_ad2 */
+   0xc  (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad5.gpmc_ad5 */
+   0x18 (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad6.gpmc_ad6 */
+   0x1c (PIN_INPUT  | MUX_MODE0)   /* gpmc_ad7.gpmc_ad7 */
+   0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_wait0.gpmc_wait0 */
+   0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/* 
gpmc_wpn.gpmc_wpn */
+   0x7c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_csn0.gpmc_csn0  */
+   0x90 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_advn_ale.gpmc_advn_ale */
+   0x94 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_oen_ren.gpmc_oen_ren */
+   0x98 (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_wen.gpmc_wen */
+   0x9c (PIN_OUTPUT | MUX_MODE0)   /* 
gpmc_be0n_cle.gpmc_be0n_cle */
+   ;
+   };
 };
 
 i2c0 {
@@ -125,3 +146,89 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
 };
+
+elm {
+   status = okay;
+};
+
+gpmc {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = nand_flash_x8;
+   ranges = 0 0 0x0800 0x1000;   /* CS0: NAND */
+   nand@0,0 {
+   reg = 0 0 0; /* CS0, offset 0 */
+   ti,nand-ecc-opt = bch8;
+   ti,elm-id = elm;
+   nand-bus-width = 8;
+   gpmc,device-width = 1;
+   gpmc,sync-clk-ps = 0;
+   gpmc,cs-on-ns = 0;
+   gpmc,cs-rd-off-ns = 40;
+   gpmc,cs-wr-off-ns = 40;
+   gpmc,adv-on-ns = 0;
+   gpmc,adv-rd-off-ns = 25;
+   gpmc,adv-wr-off-ns = 25;
+   gpmc,we-on-ns = 0;
+   gpmc,we-off-ns = 20;
+   gpmc,oe-on-ns = 3;
+   gpmc,oe-off-ns = 30;
+   gpmc,access-ns = 30;
+   gpmc,rd-cycle-ns = 40;
+   gpmc,wr-cycle-ns = 40;
+   gpmc,wait-on-read = true;
+   gpmc,wait-on-write = true;
+   gpmc,bus-turnaround-ns = 0;
+   gpmc,cycle2cycle-delay-ns = 0;
+   gpmc,clk-activation-ns = 0;
+   gpmc,wait-monitoring-ns = 0;
+   gpmc,wr-access-ns = 40;
+   gpmc,wr-data-mux-bus-ns = 0;
+   /* MTD partition table */
+   /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+   #address-cells = 1;
+   #size-cells = 1;
+   partition@0 {
+   label = NAND.SPL;
+   reg = 0x 0x0004;
+   };
+   partition@1 {
+   label = NAND.SPL.backup1;
+   reg = 0x0004 0x0004;
+   };
+   partition@2 {
+   label = NAND.SPL.backup2;
+   reg = 0x0008 0x0004;
+   };
+   partition@3 {
+   label = NAND.SPL.backup3;
+   reg = 0x000C 0x0004;
+   };
+   

Re: [PATCH 1/2] extcon: of: Remove unnecessary function call by using the name of device_node

[Kishon Vijay Abraham I]

Hi,

On Thursday 20 March 2014 12:26 PM, Chanwoo Choi wrote:
 Hi,
 
 On 03/20/2014 02:20 PM, Kishon Vijay Abraham I wrote:
 Hi,

 On Thursday 20 March 2014 07:52 AM, Chanwoo Choi wrote:
 Hi,

 On 03/19/2014 09:08 PM, Kishon Vijay Abraham I wrote:
 Hi,

 On Tuesday 18 March 2014 05:34 PM, Chanwoo Choi wrote:
 This patch remove unnecessary function call in of_extcon_get_extcon_dev()
 by using the name of device_node structure.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/extcon/of_extcon.c | 12 ++--
  1 file changed, 2 insertions(+), 10 deletions(-)

 diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
 index 72173ec..0a29f82 100644
 --- a/drivers/extcon/of_extcon.c
 +++ b/drivers/extcon/of_extcon.c
 @@ -32,7 +32,6 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct 
 device *dev, int index)
  {
   struct device_node *node;
   struct extcon_dev *edev;
 - struct platform_device *extcon_parent_dev;
  
   if (!dev-of_node) {
   dev_dbg(dev, device does not have a device node entry\n);
 @@ -46,16 +45,9 @@ struct extcon_dev *of_extcon_get_extcon_dev(struct 
 device *dev, int index)
   return ERR_PTR(-ENODEV);
   }
  
 - extcon_parent_dev = of_find_device_by_node(node);
 - if (!extcon_parent_dev) {
 - dev_dbg(dev, unable to find device by node\n);
 - return ERR_PTR(-EPROBE_DEFER);
 - }
 -
 - edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
 + edev = extcon_get_extcon_dev(node-name);

 Since you no longer want to use device names I think you should add this 
 too to
 warn users if they rely on using the device name.

 Previous of_extcon_get_extcon_dev() support only platform device using 
 of_find_device_by_node.

 If extcon device is based on i2c/spi/pci and so on, 
 of_extcon_get_extcon_dev() can't
 find device instance for device name. So, I change device name from the 
 name of platform device
 to the name of dt node.

 That's fine. But we have to fix extcon_dev_register() too, to not use device
 names right? We have to warn extcon users not to use device names right?
 
 I don't think so. extcon_get_edev_by_phandle() shows wrong node-name as 
 following:

The wrong node-name was given by the extcon provider but the error is being
reported in the consumer.
 The consumer could detect the cause of problem which can't get extcon device 
 after
 checking error log message.
 
   edev = extcon_get_extcon_dev(node-name);
   if (!edev) {
   dev_err(dev, unable to get extcon device : %s\n, node-name);
   return ERR_PTR(-ENODEV);
   }
 
 I don't want to add more log message.

I'm not sure if that log message is helpful in anyway to identify the problem
was because of the wrong node-name.
 


 diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
 index bc4c789..025eb39 100644
 --- a/drivers/extcon/extcon-class.c
 +++ b/drivers/extcon/extcon-class.c
 @@ -601,7 +601,6 @@ int extcon_dev_register(struct extcon_dev *edev)
 edev-dev.class = extcon_class;
 edev-dev.release = extcon_dev_release;

 -   edev-name = edev-name ? edev-name : dev_name(edev-dev.parent);
 //The user should always pass the 'name' as we no longer use device name 
 while
 getting extcon device. And this name should also be the 'node' name?
 if (IS_ERR_OR_NULL(edev-name)) {
 dev_err(edev-dev,
 extcon device name is null\n);

 Btw changing to node name from device name breaks dwc3 in OMAP5 and you 
 would
 need this too..

 diff --git a/drivers/extcon/extcon-palmas.c 
 b/drivers/extcon/extcon-palmas.c
 index 2aea4bc..cea8cd3 100644
 --- a/drivers/extcon/extcon-palmas.c
 +++ b/drivers/extcon/extcon-palmas.c
 @@ -188,6 +188,7 @@ static int palmas_usb_probe(struct platform_device 
 *pdev)

 palmas_usb-edev.supported_cable = palmas_extcon_cable;
 palmas_usb-edev.dev.parent = palmas_usb-dev;
 +   palmas_usb-edev.name = palmas_usb;
 palmas_usb-edev.mutually_exclusive = mutually_exclusive;

 status = extcon_dev_register(palmas_usb-edev);

 Cheers
 Kishon


 If node name is same as extcon device name, don't need some modification.
 Also, you can modify node name in some OMAP dts file insead of modification 
 of extcon-palmas.c

 node name in OMAP dts is already 'palmas_usb'. But since we were not setting
 'edev.name' in extcon-palmas.c, extcon_dev_register used device name of 
 palmas
 (palmas_usb.7 in my case). So extcon-palmas.c needs the fix.
 
 For example,
 I used extcon provider/consumer driver in dts as following:
 extcon-max14577.c set device name as edev-name and then dt node name of 
 max14577
 set max14577-muic which is same as device name(dev_name(pdev-dev)).
 
 I don't need to modify extcon-max14577.c
 
 In drivers/extcon/extcon-max14577.c
   ...
   info-edev-name = dev_name(pdev-dev);

dev_name need not be same as node name in all cases.

-Kishon
--
To unsubscribe from this list: send the line 

[PATCH v8 2/4] mtd: devices: elm: clean elm_load_syndrome

[Pekon Gupta]

This patch refactors elm_load_syndrome() to make it scalable for newer
ECC schemes by removing scheme specific macros (like ECC_BYTES*xx),
and instead using ECC control information passed during elm_config.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 18 +++---
 include/linux/platform_data/elm.h |  7 ---
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index c51752a..4fbfaf6 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -84,6 +84,7 @@ struct elm_info {
struct list_head list;
enum bch_ecc bch_type;
struct elm_registers elm_regs;
+   int ecc_syndrome_size;
 };
 
 static LIST_HEAD(elm_devices);
@@ -126,7 +127,8 @@ int elm_config(struct device *dev, enum bch_ecc bch_type,
 
reg_val = (bch_type  ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE  16);
elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
-   info-bch_type = bch_type;
+   info-bch_type  = bch_type;
+   info-ecc_syndrome_size = ecc_syndrome_size;
 
return 0;
 }
@@ -175,10 +177,8 @@ static void elm_load_syndrome(struct elm_info *info,
elm_configure_page_mode(info, i, true);
offset = ELM_SYNDROME_FRAGMENT_0 +
SYNDROME_FRAGMENT_REG_SIZE * i;
-
-   /* BCH8 */
-   if (info-bch_type) {
-
+   switch (info-bch_type) {
+   case BCH8_ECC:
/* syndrome fragment 0 = ecc[9-12B] */
val = cpu_to_be32(*(u32 *) ecc[9]);
elm_write_reg(info, offset, val);
@@ -197,7 +197,8 @@ static void elm_load_syndrome(struct elm_info *info,
offset += 4;
val = ecc[0];
elm_write_reg(info, offset, val);
-   } else {
+   break;
+   case BCH4_ECC:
/* syndrome fragment 0 = ecc[20-52b] bits */
val = (cpu_to_be32(*(u32 *) ecc[3])  4) |
((ecc[2]  0xf)  28);
@@ -207,11 +208,14 @@ static void elm_load_syndrome(struct elm_info *info,
offset += 4;
val = cpu_to_be32(*(u32 *) ecc[0])  12;
elm_write_reg(info, offset, val);
+   break;
+   default:
+   pr_err(invalid config bch_type\n);
}
}
 
/* Update ecc pointer with ecc byte size */
-   ecc += info-bch_type ? BCH8_SIZE : BCH4_SIZE;
+   ecc += info-ecc_syndrome_size;
}
 }
 
diff --git a/include/linux/platform_data/elm.h 
b/include/linux/platform_data/elm.h
index 6e37156..4edb406 100644
--- a/include/linux/platform_data/elm.h
+++ b/include/linux/platform_data/elm.h
@@ -26,13 +26,6 @@ enum bch_ecc {
 /* ELM support 8 error syndrome process */
 #define ERROR_VECTOR_MAX   8
 
-#define BCH8_ECC_OOB_BYTES 13
-#define BCH4_ECC_OOB_BYTES 7
-/* RBL requires 14 byte even though BCH8 uses only 13 byte */
-#define BCH8_SIZE  (BCH8_ECC_OOB_BYTES + 1)
-/* Uses 1 extra byte to handle erased pages */
-#define BCH4_SIZE  (BCH4_ECC_OOB_BYTES + 1)
-
 /**
  * struct elm_errorvec - error vector for elm
  * @error_reported:set true for vectors error is reported
-- 
1.8.5.1.163.gd7aced9

--
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 v8 1/4] mtd: devices: elm: check for hardware engine's design constraints

[Pekon Gupta]

ELM hardware engine is used by BCH ecc-schemes for detecting and locating ECC
errors. This patch adds the following checks for ELM hardware engine:

 - ELM internal buffers are of 1K,
   so it cannot process data with ecc-step-size  1K.

 - ELM engine can execute upto maximum of 8 threads in parallel,
   so in *page-mode* (when complete page is processed in single iteration),
   ELM cannot support ecc-steps  8.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 13 -
 drivers/mtd/nand/omap2.c  |  9 ++---
 include/linux/platform_data/elm.h |  3 ++-
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index f160d2c..c51752a 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -103,7 +103,8 @@ static u32 elm_read_reg(struct elm_info *info, int offset)
  * @dev:   ELM device
  * @bch_type:  Type of BCH ecc
  */
-int elm_config(struct device *dev, enum bch_ecc bch_type)
+int elm_config(struct device *dev, enum bch_ecc bch_type,
+   int ecc_steps, int ecc_step_size, int ecc_syndrome_size)
 {
u32 reg_val;
struct elm_info *info = dev_get_drvdata(dev);
@@ -112,6 +113,16 @@ int elm_config(struct device *dev, enum bch_ecc bch_type)
dev_err(dev, Unable to configure elm - device not probed?\n);
return -ENODEV;
}
+   /* ELM cannot detect ECC errors for chunks  1KB */
+   if (ecc_step_size  ((ELM_ECC_SIZE + 1) / 2)) {
+   dev_err(dev, unsupported config ecc-size=%d\n, ecc_step_size);
+   return -EINVAL;
+   }
+   /* ELM support 8 error syndrome process */
+   if (ecc_steps  ERROR_VECTOR_MAX) {
+   dev_err(dev, unsupported config ecc-step=%d\n, ecc_steps);
+   return -EINVAL;
+   }
 
reg_val = (bch_type  ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE  16);
elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index ab9c472..6f9b339 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1540,6 +1540,8 @@ static int is_elm_present(struct omap_nand_info *info,
struct device_node *elm_node, enum bch_ecc bch_type)
 {
struct platform_device *pdev;
+   struct nand_ecc_ctrl *ecc = info-nand.ecc;
+   int err;
/* check whether elm-id is passed via DT */
if (!elm_node) {
pr_err(nand: error: ELM DT node not found\n);
@@ -1553,9 +1555,10 @@ static int is_elm_present(struct omap_nand_info *info,
}
/* ELM module available, now configure it */
info-elm_dev = pdev-dev;
-   if (elm_config(info-elm_dev, bch_type))
-   return -ENODEV;
-   return 0;
+   err = elm_config(info-elm_dev, bch_type,
+   (info-mtd.writesize / ecc-size), ecc-size, ecc-bytes);
+
+   return err;
 }
 #endif /* CONFIG_MTD_NAND_ECC_BCH */
 
diff --git a/include/linux/platform_data/elm.h 
b/include/linux/platform_data/elm.h
index bf0a83b..6e37156 100644
--- a/include/linux/platform_data/elm.h
+++ b/include/linux/platform_data/elm.h
@@ -50,5 +50,6 @@ struct elm_errorvec {
 
 void elm_decode_bch_error_page(struct device *dev, u8 *ecc_calc,
struct elm_errorvec *err_vec);
-int elm_config(struct device *dev, enum bch_ecc bch_type);
+int elm_config(struct device *dev, enum bch_ecc bch_type,
+   int ecc_steps, int ecc_step_size, int ecc_syndrome_size);
 #endif /* __ELM_H */
-- 
1.8.5.1.163.gd7aced9

--
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 v8 3/4] mtd: devices: elm: configure parallel channels based on ecc_steps

[Pekon Gupta]

ELM hardware can process up to maximum of 8 hannels in parallel for
ECC error detection. Currently the number of channels getting configured for
processing is static determined by macro ERROR_VECTOR_MAX. However, the actual
number of channels that need to be processed is the ECC step number.
This patch just avoids configuring extra unused channels.

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index 4fbfaf6..26df41f 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -84,6 +84,7 @@ struct elm_info {
struct list_head list;
enum bch_ecc bch_type;
struct elm_registers elm_regs;
+   int ecc_steps;
int ecc_syndrome_size;
 };
 
@@ -128,6 +129,7 @@ int elm_config(struct device *dev, enum bch_ecc bch_type,
reg_val = (bch_type  ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE  16);
elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
info-bch_type  = bch_type;
+   info-ecc_steps = ecc_steps;
info-ecc_syndrome_size = ecc_syndrome_size;
 
return 0;
@@ -170,7 +172,7 @@ static void elm_load_syndrome(struct elm_info *info,
int i, offset;
u32 val;
 
-   for (i = 0; i  ERROR_VECTOR_MAX; i++) {
+   for (i = 0; i  info-ecc_steps; i++) {
 
/* Check error reported */
if (err_vec[i].error_reported) {
@@ -238,7 +240,7 @@ static void elm_start_processing(struct elm_info *info,
 * Set syndrome vector valid, so that ELM module
 * will process it for vectors error is reported
 */
-   for (i = 0; i  ERROR_VECTOR_MAX; i++) {
+   for (i = 0; i  info-ecc_steps; i++) {
if (err_vec[i].error_reported) {
offset = ELM_SYNDROME_FRAGMENT_6 +
SYNDROME_FRAGMENT_REG_SIZE * i;
@@ -267,7 +269,7 @@ static void elm_error_correction(struct elm_info *info,
int offset;
u32 reg_val;
 
-   for (i = 0; i  ERROR_VECTOR_MAX; i++) {
+   for (i = 0; i  info-ecc_steps; i++) {
 
/* Check error reported */
if (err_vec[i].error_reported) {
-- 
1.8.5.1.163.gd7aced9

--
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 v8 0/4] mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup

[Pekon Gupta]

*changes v7 - v8*
Incorporated feedbacks from Brian Norris computersforpe...@gmail.com
 - renamed ecc_step_bytes - ecc_syndrome_size


*changes v6 - v7*
Incorporated feedbacks from Ezequiel Garcia ezequiel.gar...@free-electrons.com
 - using dev_err() instead of pr_err()
 - moved un-related addition of info-ecc_steps, info-ecc_step_bytes,
   info-ecc_step_size from [PATCH v6 1/4] into subsequent patches
 - dropped pr_fmt() change


*changes v5 - v6*
[PATCH 02/04] minor cleanup

*changes v4 - v5*
This patch series is split version from earlier series [1].
This series refactors and cleans ELM driver which is used by Hardware
based BCHx ecc-schemes.
 - Undo: introduction of 'struct mtd_info' and 'struct nand_chip'. Instead
 keep ELM driver independent of mtd_info and nand_chip structs and
 pass only required ECC configurations as elm_config() arguments
 elm_config(..., int ecc_steps, int ecc_step_size, int ecc_step_bytes)
 - Undo: re-writing of elm_load_syndrome() ECC register configurations.

*changes v3 - v4 [1]*
 - in-corporated feedbacks from Brian Norris computersforpe...@gmail.com
 - updated: use 'pr_fmt(fmt)' to suffix DRIVER_NAME
 - removed: local 'eccsteps' in ELM driver, instead using nand_chip-ecc.steps
 - undo: irrelavant white-space changes

[1] http://lists.infradead.org/pipermail/linux-mtd/2013-November/050242.html

Pekon Gupta (4):
  mtd: devices: elm: check for hardware engine's design constraints
  mtd: devices: elm: clean elm_load_syndrome
  mtd: devices: elm: configure parallel channels based on ecc_steps
  mtd: devices: elm: update DRIVER_NAME as omap-elm

 drivers/mtd/devices/elm.c | 43 ---
 drivers/mtd/nand/omap2.c  |  9 +---
 include/linux/platform_data/elm.h | 10 ++---
 3 files changed, 39 insertions(+), 23 deletions(-)

-- 
1.8.5.1.163.gd7aced9

--
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 v8 4/4] mtd: devices: elm: update DRIVER_NAME as omap-elm

[Pekon Gupta]

use omap-elm as DRIVER_NAME

Signed-off-by: Pekon Gupta pe...@ti.com
---
 drivers/mtd/devices/elm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index 26df41f..1fd4a0f 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -15,6 +15,8 @@
  *
  */
 
+#define DRIVER_NAMEomap-elm
+
 #include linux/platform_device.h
 #include linux/module.h
 #include linux/interrupt.h
@@ -520,7 +522,7 @@ MODULE_DEVICE_TABLE(of, elm_of_match);
 
 static struct platform_driver elm_driver = {
.driver = {
-   .name   = elm,
+   .name   = DRIVER_NAME,
.owner  = THIS_MODULE,
.of_match_table = of_match_ptr(elm_of_match),
.pm = elm_pm_ops,
-- 
1.8.5.1.163.gd7aced9

--
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 v8 0/4] mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup

[Gupta, Pekon]

From: Gupta, Pekon
Subject: [PATCH v8 0/4] mtd: devices: elm: add checks ELM H/W constrains, 
driver code cleanup


Sorry, sent to the wrong list.. was intended for linux-mtd list
Please ignore the whole series.


with regards, pekon
--
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/26] arm: Replace various irq_desc accesses

[Arnd Bergmann]

On Sunday 23 February 2014, Thomas Gleixner wrote:
 --- tip.orig/arch/arm/mach-omap1/ams-delta-fiq.c
 +++ tip/arch/arm/mach-omap1/ams-delta-fiq.c
 @@ -44,13 +44,10 @@ static unsigned int irq_counter[16];
  
  static irqreturn_t deferred_fiq(int irq, void *dev_id)
  {
 -   struct irq_desc *irq_desc;
 -   struct irq_chip *irq_chip = NULL;
 int gpio, irq_num, fiq_count;
 +   struct irq_chip *irq_chip;
  
 -   irq_desc = irq_to_desc(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK));
 -   if (irq_desc)
 -   irq_chip = irq_desc-irq_data.chip;
 +   irq_chip = 
 irq_get_irq_chip(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK));

I got a compile error because irq_get_irq_chip() doesn't exist. I suppose
you meant irq_get_chip.

Arnd
--
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 07/11] tty: serial: omap: remove unneeded singlethread workqueue

[Felipe Balbi]

it wasn't used by anything, just remove it.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c79d3e6..b092d3d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -180,8 +180,6 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 /* Forward declaration of functions */
 static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
 
-static struct workqueue_struct *serial_omap_uart_wq;
-
 static inline unsigned int serial_in(struct uart_omap_port *up, int offset)
 {
offset = up-port.regshift;
@@ -1684,7 +1682,6 @@ static int serial_omap_probe(struct platform_device *pdev)
up-calc_latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
pm_qos_add_request(up-pm_qos_request,
PM_QOS_CPU_DMA_LATENCY, up-latency);
-   serial_omap_uart_wq = create_singlethread_workqueue(up-name);
INIT_WORK(up-qos_work, serial_omap_uart_qos_work);
 
platform_set_drvdata(pdev, up);
-- 
1.9.1.286.g5172cb3

--
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 11/11] serial: fix UART_IIR_ID

[Felipe Balbi]

UART IRQ Identification bitfield is 3
bits long (bits 3:1) but current mask only
masks 2 bits. Fix it.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 include/uapi/linux/serial_reg.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index e632260..99b4705 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -32,7 +32,7 @@
 
 #define UART_IIR   2   /* In:  Interrupt ID Register */
 #define UART_IIR_NO_INT0x01 /* No interrupts pending */
-#define UART_IIR_ID0x06 /* Mask for the interrupt ID */
+#define UART_IIR_ID0x0e /* Mask for the interrupt ID */
 #define UART_IIR_MSI   0x00 /* Modem status interrupt */
 #define UART_IIR_THRI  0x02 /* Transmitter holding register empty */
 #define UART_IIR_RDI   0x04 /* Receiver data interrupt */
-- 
1.9.1.286.g5172cb3

--
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 09/11] bluetooth: hci_ldisc: fix deadlock condition

[Felipe Balbi]

LDISCs shouldn't call tty-ops-write() from within
-write_wakeup().

-write_wakeup() is called with port lock taken and
IRQs disabled, tty-ops-write() will try to acquire
the same port lock and we will deadlock.

Reviewed-by: Peter Hurley pe...@hurleysoftware.com
Reported-by: Huang Shijie b32...@freescale.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/bluetooth/hci_ldisc.c | 24 +++-
 drivers/bluetooth/hci_uart.h  |  1 +
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 6e06f6f..77af52f 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -118,10 +118,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct 
hci_uart *hu)
 
 int hci_uart_tx_wakeup(struct hci_uart *hu)
 {
-   struct tty_struct *tty = hu-tty;
-   struct hci_dev *hdev = hu-hdev;
-   struct sk_buff *skb;
-
if (test_and_set_bit(HCI_UART_SENDING, hu-tx_state)) {
set_bit(HCI_UART_TX_WAKEUP, hu-tx_state);
return 0;
@@ -129,6 +125,22 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
 
BT_DBG();
 
+   schedule_work(hu-write_work);
+
+   return 0;
+}
+
+static void hci_uart_write_work(struct work_struct *work)
+{
+   struct hci_uart *hu = container_of(work, struct hci_uart, write_work);
+   struct tty_struct *tty = hu-tty;
+   struct hci_dev *hdev = hu-hdev;
+   struct sk_buff *skb;
+
+   /* REVISIT: should we cope with bad skbs or -write() returning
+* and error value ?
+*/
+
 restart:
clear_bit(HCI_UART_TX_WAKEUP, hu-tx_state);
 
@@ -153,7 +165,6 @@ restart:
goto restart;
 
clear_bit(HCI_UART_SENDING, hu-tx_state);
-   return 0;
 }
 
 static void hci_uart_init_work(struct work_struct *work)
@@ -281,6 +292,7 @@ static int hci_uart_tty_open(struct tty_struct *tty)
tty-receive_room = 65536;
 
INIT_WORK(hu-init_ready, hci_uart_init_work);
+   INIT_WORK(hu-write_work, hci_uart_write_work);
 
spin_lock_init(hu-rx_lock);
 
@@ -318,6 +330,8 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
 
+   cancel_work_sync(hu-write_work);
+
if (test_and_clear_bit(HCI_UART_PROTO_SET, hu-flags)) {
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, hu-flags))
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index fffa61f..12df101 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -68,6 +68,7 @@ struct hci_uart {
unsigned long   hdev_flags;
 
struct work_struct  init_ready;
+   struct work_struct  write_work;
 
struct hci_uart_proto   *proto;
void*priv;
-- 
1.9.1.286.g5172cb3

--
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 10/11] Revert serial: omap: unlock the port lock

[Felipe Balbi]

This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e.

That commit tried to fix a deadlock problem when using
hci_ldisc, but it turns out the bug was in hci_ldsic
all along where it was calling -write() from within
-write_wakeup() callback.

The problem is that -write_wakeup() was called with
port lock held and -write() tried to grab the same
port lock.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b092d3d..be10e7e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -380,11 +380,8 @@ static void transmit_chars(struct uart_omap_port *up, 
unsigned int lsr)
break;
} while (--count  0);
 
-   if (uart_circ_chars_pending(xmit)  WAKEUP_CHARS) {
-   spin_unlock(up-port.lock);
+   if (uart_circ_chars_pending(xmit)  WAKEUP_CHARS)
uart_write_wakeup(up-port);
-   spin_lock(up-port.lock);
-   }
 
if (uart_circ_empty(xmit))
serial_omap_stop_tx(up-port);
-- 
1.9.1.286.g5172cb3

--
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 08/11] In the uart_handle_cts_change(), uart_write_wakeup() is called after we call @uart_port-ops-start_tx().

[Felipe Balbi]

From: Huang Shijie b32...@freescale.com

The Documentation/serial/driver tells us:
---
  start_tx(port)
Start transmitting characters.

Locking: port-lock taken.
Interrupts: locally disabled.
---

So when the uart_write_wakeup() is called, the port-lock is taken by
the upper. See the following callstack:

|_ uart_write_wakeup
   |_ tty_wakeup
  |_ ld-ops-write_wakeup

With the port-lock held, we call the @write_wakeup. Some implemetation of
the @write_wakeup does not notice that the port-lock is held, and it still
tries to send data with uart_write() which will try to grab the prot-lock.
A dead lock occurs, see the following log caught in the Bluetooth by uart:


BUG: spinlock lockup suspected on CPU#0, swapper/0/0
 lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW3.10.17-16839-ge4a1bef 
#1320
[80014cbc] (unwind_backtrace+0x0/0x138) from [8001251c] 
(show_stack+0x10/0x14)
[8001251c] (show_stack+0x10/0x14) from [802816ac] 
(do_raw_spin_lock+0x108/0x184)
[802816ac] (do_raw_spin_lock+0x108/0x184) from [806a22b0] 
(_raw_spin_lock_irqsave+0x54/0x60)
[806a22b0] (_raw_spin_lock_irqsave+0x54/0x60) from [802f5754] 
(uart_write+0x38/0xe0)
[802f5754] (uart_write+0x38/0xe0) from [80455270] 
(hci_uart_tx_wakeup+0xa4/0x168)
[80455270] (hci_uart_tx_wakeup+0xa4/0x168) from [802dab18] 
(tty_wakeup+0x50/0x5c)
[802dab18] (tty_wakeup+0x50/0x5c) from [802f81a4] (imx_rtsint+0x50/0x80)
[802f81a4] (imx_rtsint+0x50/0x80) from [802f88f4] (imx_int+0x158/0x17c)
[802f88f4] (imx_int+0x158/0x17c) from [8007abe0] 
(handle_irq_event_percpu+0x50/0x194)
[8007abe0] (handle_irq_event_percpu+0x50/0x194) from [8007ad60] 
(handle_irq_event+0x3c/0x5c)


This patch adds more limits to the @write_wakeup, the one who wants to
implemet the @write_wakeup should follow the limits which avoid the deadlock.

Signed-off-by: Huang Shijie b32...@freescale.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
 include/linux/tty_ldisc.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/tty_ldisc.h b/include/linux/tty_ldisc.h
index b8347c2..8946e31 100644
--- a/include/linux/tty_ldisc.h
+++ b/include/linux/tty_ldisc.h
@@ -92,7 +92,10 @@
  * This function is called by the low-level tty driver to signal
  * that line discpline should try to send more characters to the
  * low-level driver for transmission.  If the line discpline does
- * not have any more data to send, it can just return.
+ * not have any more data to send, it can just return. If the line
+ * discipline does have some data to send, please arise a tasklet
+ * or workqueue to do the real data transfer. Do not send data in
+ * this hook, it may leads to a deadlock.
  *
  * int (*hangup)(struct tty_struct *)
  *
-- 
1.9.1.286.g5172cb3

--
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 06/11] tty: serial: omap: remove some dead code

[Felipe Balbi]

nobody passes a DTR_gpio to this driver, so
this code is not necessary.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 39 ---
 1 file changed, 39 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d785327..c79d3e6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -163,10 +163,6 @@ struct uart_omap_port {
u8  wakeups_enabled;
u32 features;
 
-   int DTR_gpio;
-   int DTR_inverted;
-   int DTR_active;
-
struct serial_rs485 rs485;
int rts_gpio;
 
@@ -685,16 +681,6 @@ static void serial_omap_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
serial_out(up, UART_MCR, up-mcr);
pm_runtime_mark_last_busy(up-dev);
pm_runtime_put_autosuspend(up-dev);
-
-   if (gpio_is_valid(up-DTR_gpio) 
-   !!(mctrl  TIOCM_DTR) != up-DTR_active) {
-   up-DTR_active = !up-DTR_active;
-   if (gpio_cansleep(up-DTR_gpio))
-   schedule_work(up-qos_work);
-   else
-   gpio_set_value(up-DTR_gpio,
-  up-DTR_active != up-DTR_inverted);
-   }
 }
 
 static void serial_omap_break_ctl(struct uart_port *port, int break_state)
@@ -838,9 +824,6 @@ static void serial_omap_uart_qos_work(struct work_struct 
*work)
qos_work);
 
pm_qos_update_request(up-pm_qos_request, up-latency);
-   if (gpio_is_valid(up-DTR_gpio))
-   gpio_set_value_cansleep(up-DTR_gpio,
-   up-DTR_active != up-DTR_inverted);
 }
 
 static void
@@ -1655,28 +1638,6 @@ static int serial_omap_probe(struct platform_device 
*pdev)
if (IS_ERR(base))
return PTR_ERR(base);
 
-   if (gpio_is_valid(omap_up_info-DTR_gpio) 
-   omap_up_info-DTR_present) {
-   ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
-   omap-serial);
-   if (ret  0)
-   return ret;
-   ret = gpio_direction_output(omap_up_info-DTR_gpio,
-   omap_up_info-DTR_inverted);
-   if (ret  0)
-   return ret;
-   }
-
-   if (gpio_is_valid(omap_up_info-DTR_gpio) 
-   omap_up_info-DTR_present) {
-   up-DTR_gpio = omap_up_info-DTR_gpio;
-   up-DTR_inverted = omap_up_info-DTR_inverted;
-   } else {
-   up-DTR_gpio = -EINVAL;
-   }
-
-   up-DTR_active = 0;
-
up-dev = pdev-dev;
up-port.dev = pdev-dev;
up-port.type = PORT_OMAP;
-- 
1.9.1.286.g5172cb3

--
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 05/11] tty: serial: omap: switch over to devm_ioremap_resource

[Felipe Balbi]

just using helper function to remove some duplicated
code a bit. While at that, also move allocation of
struct uart_omap_port higher in the code so that
we return much earlier in case of no memory.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 32 +---
 1 file changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d041060..d785327 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1627,6 +1627,7 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
struct uart_omap_port *up;
struct resource *mem;
+   void __iomem *base;
int uartirq = 0;
int wakeirq = 0;
int ret;
@@ -1645,17 +1646,14 @@ static int serial_omap_probe(struct platform_device 
*pdev)
return -EPROBE_DEFER;
}
 
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!mem) {
-   dev_err(pdev-dev, no mem resource?\n);
-   return -ENODEV;
-   }
+   up = devm_kzalloc(pdev-dev, sizeof(*up), GFP_KERNEL);
+   if (!up)
+   return -ENOMEM;
 
-   if (!devm_request_mem_region(pdev-dev, mem-start, resource_size(mem),
-   pdev-dev.driver-name)) {
-   dev_err(pdev-dev, memory region already claimed\n);
-   return -EBUSY;
-   }
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(pdev-dev, mem);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
 
if (gpio_is_valid(omap_up_info-DTR_gpio) 
omap_up_info-DTR_present) {
@@ -1669,10 +1667,6 @@ static int serial_omap_probe(struct platform_device 
*pdev)
return ret;
}
 
-   up = devm_kzalloc(pdev-dev, sizeof(*up), GFP_KERNEL);
-   if (!up)
-   return -ENOMEM;
-
if (gpio_is_valid(omap_up_info-DTR_gpio) 
omap_up_info-DTR_present) {
up-DTR_gpio = omap_up_info-DTR_gpio;
@@ -1715,14 +1709,7 @@ static int serial_omap_probe(struct platform_device 
*pdev)
 
sprintf(up-name, OMAP UART%d, up-port.line);
up-port.mapbase = mem-start;
-   up-port.membase = devm_ioremap(pdev-dev, mem-start,
-   resource_size(mem));
-   if (!up-port.membase) {
-   dev_err(pdev-dev, can't ioremap UART\n);
-   ret = -ENOMEM;
-   goto err_ioremap;
-   }
-
+   up-port.membase = base;
up-port.flags = omap_up_info-flags;
up-port.uartclk = omap_up_info-uartclk;
if (!up-port.uartclk) {
@@ -1769,7 +1756,6 @@ static int serial_omap_probe(struct platform_device *pdev)
 err_add_port:
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
-err_ioremap:
 err_rs485:
 err_port_line:
dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
-- 
1.9.1.286.g5172cb3

--
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 02/11] tty: serial: omap: switch over to devm_request_gpio

[Felipe Balbi]

this will make sure gpio gets freed automatically
when this device is destroyed.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 73abba8..db5d90b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1594,7 +1594,7 @@ static int serial_omap_probe_rs485(struct uart_omap_port 
*up,
/* check for tx enable gpio */
up-rts_gpio = of_get_named_gpio_flags(np, rts-gpio, 0, flags);
if (gpio_is_valid(up-rts_gpio)) {
-   ret = gpio_request(up-rts_gpio, omap-serial);
+   ret = devm_gpio_request(up-dev, up-rts_gpio, omap-serial);
if (ret  0)
return ret;
ret = gpio_direction_output(up-rts_gpio,
@@ -1660,7 +1660,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 
if (gpio_is_valid(omap_up_info-DTR_gpio) 
omap_up_info-DTR_present) {
-   ret = gpio_request(omap_up_info-DTR_gpio, omap-serial);
+   ret = devm_gpio_request(pdev-dev, omap_up_info-DTR_gpio,
+   omap-serial);
if (ret  0)
return ret;
ret = gpio_direction_output(omap_up_info-DTR_gpio,
-- 
1.9.1.286.g5172cb3

--
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 04/11] tty: serial: omap: switch over to platform_get_resource

[Felipe Balbi]

this way we can remove one pointer declaration.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6831425..d041060 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1627,7 +1627,6 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
struct uart_omap_port *up;
struct resource *mem;
-   struct resource *irq;
int uartirq = 0;
int wakeirq = 0;
int ret;
@@ -1641,12 +1640,9 @@ static int serial_omap_probe(struct platform_device 
*pdev)
omap_up_info = of_get_uart_port_info(pdev-dev);
pdev-dev.platform_data = omap_up_info;
} else {
-   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!irq) {
-   dev_err(pdev-dev, no irq resource?\n);
-   return -ENODEV;
-   }
-   uartirq = irq-start;
+   uartirq = platform_get_irq(pdev, 0);
+   if (uartirq  0)
+   return -EPROBE_DEFER;
}
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
1.9.1.286.g5172cb3

--
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 03/11] tty: serial: omap: cleanup variable declarations

[Felipe Balbi]

cleanup only, no functional changes.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index db5d90b..6831425 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1624,10 +1624,13 @@ static int serial_omap_probe_rs485(struct 
uart_omap_port *up,
 
 static int serial_omap_probe(struct platform_device *pdev)
 {
-   struct uart_omap_port   *up;
-   struct resource *mem, *irq;
struct omap_uart_port_info *omap_up_info = dev_get_platdata(pdev-dev);
-   int ret, uartirq = 0, wakeirq = 0;
+   struct uart_omap_port *up;
+   struct resource *mem;
+   struct resource *irq;
+   int uartirq = 0;
+   int wakeirq = 0;
+   int ret;
 
/* The optional wakeirq may be specified in the board dts file */
if (pdev-dev.of_node) {
-- 
1.9.1.286.g5172cb3

--
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 01/11] tty: serial: add missing braces

[Felipe Balbi]

per CodingStyle we should have those braces, no
functional changes.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/tty/serial/omap-serial.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 77f0351..73abba8 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1677,8 +1677,10 @@ static int serial_omap_probe(struct platform_device 
*pdev)
omap_up_info-DTR_present) {
up-DTR_gpio = omap_up_info-DTR_gpio;
up-DTR_inverted = omap_up_info-DTR_inverted;
-   } else
+   } else {
up-DTR_gpio = -EINVAL;
+   }
+
up-DTR_active = 0;
 
up-dev = pdev-dev;
@@ -1740,6 +1742,7 @@ static int serial_omap_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, up);
if (omap_up_info-autosuspend_timeout == 0)
omap_up_info-autosuspend_timeout = -1;
+
device_init_wakeup(up-dev, true);
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev,
-- 
1.9.1.286.g5172cb3

--
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/11] In the uart_handle_cts_change(), uart_write_wakeup() is called after we call @uart_port-ops-start_tx().

[Felipe Balbi]

Hi,


On Thu, Mar 20, 2014 at 02:30:04PM -0500, Felipe Balbi wrote:
 From: Huang Shijie b32...@freescale.com
 
 The Documentation/serial/driver tells us:
 ---
   start_tx(port)
   Start transmitting characters.
 
   Locking: port-lock taken.
   Interrupts: locally disabled.
 ---
 
 So when the uart_write_wakeup() is called, the port-lock is taken by
 the upper. See the following callstack:
 
   |_ uart_write_wakeup
  |_ tty_wakeup
 |_ ld-ops-write_wakeup
 
 With the port-lock held, we call the @write_wakeup. Some implemetation of
 the @write_wakeup does not notice that the port-lock is held, and it still
 tries to send data with uart_write() which will try to grab the prot-lock.
 A dead lock occurs, see the following log caught in the Bluetooth by uart:
 
 
 BUG: spinlock lockup suspected on CPU#0, swapper/0/0
  lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
 CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW3.10.17-16839-ge4a1bef 
 #1320
 [80014cbc] (unwind_backtrace+0x0/0x138) from [8001251c] 
 (show_stack+0x10/0x14)
 [8001251c] (show_stack+0x10/0x14) from [802816ac] 
 (do_raw_spin_lock+0x108/0x184)
 [802816ac] (do_raw_spin_lock+0x108/0x184) from [806a22b0] 
 (_raw_spin_lock_irqsave+0x54/0x60)
 [806a22b0] (_raw_spin_lock_irqsave+0x54/0x60) from [802f5754] 
 (uart_write+0x38/0xe0)
 [802f5754] (uart_write+0x38/0xe0) from [80455270] 
 (hci_uart_tx_wakeup+0xa4/0x168)
 [80455270] (hci_uart_tx_wakeup+0xa4/0x168) from [802dab18] 
 (tty_wakeup+0x50/0x5c)
 [802dab18] (tty_wakeup+0x50/0x5c) from [802f81a4] (imx_rtsint+0x50/0x80)
 [802f81a4] (imx_rtsint+0x50/0x80) from [802f88f4] (imx_int+0x158/0x17c)
 [802f88f4] (imx_int+0x158/0x17c) from [8007abe0] 
 (handle_irq_event_percpu+0x50/0x194)
 [8007abe0] (handle_irq_event_percpu+0x50/0x194) from [8007ad60] 
 (handle_irq_event+0x3c/0x5c)
 
 
 This patch adds more limits to the @write_wakeup, the one who wants to
 implemet the @write_wakeup should follow the limits which avoid the deadlock.
 
 Signed-off-by: Huang Shijie b32...@freescale.com
 Signed-off-by: Felipe Balbi ba...@ti.com

patch came without a subject, Peter already sent it anyway, so Greg can
ignore this one.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 09/11] bluetooth: hci_ldisc: fix deadlock condition

[Marcel Holtmann]

Hi Felipe,

 LDISCs shouldn't call tty-ops-write() from within
 -write_wakeup().
 
 -write_wakeup() is called with port lock taken and
 IRQs disabled, tty-ops-write() will try to acquire
 the same port lock and we will deadlock.
 
 Reviewed-by: Peter Hurley pe...@hurleysoftware.com
 Reported-by: Huang Shijie b32...@freescale.com
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 drivers/bluetooth/hci_ldisc.c | 24 +++-
 drivers/bluetooth/hci_uart.h  |  1 +
 2 files changed, 20 insertions(+), 5 deletions(-)

I hope these are not causing any conflicts with bluetooth-next / linux-next. If 
not, then I can let Greg take it through tty-next tree.

Acked-by: Marcel Holtmann mar...@holtmann.org

Regards

Marcel

--
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 09/11] bluetooth: hci_ldisc: fix deadlock condition

[Felipe Balbi]

On Thu, Mar 20, 2014 at 12:40:40PM -0700, Marcel Holtmann wrote:
 Hi Felipe,
 
  LDISCs shouldn't call tty-ops-write() from within
  -write_wakeup().
  
  -write_wakeup() is called with port lock taken and
  IRQs disabled, tty-ops-write() will try to acquire
  the same port lock and we will deadlock.
  
  Reviewed-by: Peter Hurley pe...@hurleysoftware.com
  Reported-by: Huang Shijie b32...@freescale.com
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
  drivers/bluetooth/hci_ldisc.c | 24 +++-
  drivers/bluetooth/hci_uart.h  |  1 +
  2 files changed, 20 insertions(+), 5 deletions(-)
 
 I hope these are not causing any conflicts with bluetooth-next /
 linux-next. If not, then I can let Greg take it through tty-next tree.
 
 Acked-by: Marcel Holtmann mar...@holtmann.org

tty-next is already closed, i'll rebase (if necessary) once -rc1 is out
;-)

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/4] clk: dt: add support for default rate/parent

[Mike Turquette]

Quoting Tero Kristo (2014-03-05 05:10:17)
 Ping.
 
 Mike, any feedback on this?

Hi Tero,

Have you seen Sylwester's approach[1]? I prefer it since it is more
device-oriented and less centralized. The clock consumer enumerates
the default parent or rate of a consumed clock. This can be made to work
like your approach by having the clock driver consume these clocks and
set them up with default rates or parents. What do you think?

Regards,
Mike

[1] https://lkml.org/lkml/2014/3/3/324

 
 -Tero
 
 On 02/13/2014 11:00 AM, Tero Kristo wrote:
  Hi,
 
  This set is a mix-match of new DT properties for generic and TI specific
  clock drivers. Basically provided for commenting purposes. The patches
  provide a way to configure clock parents / rates during boot through DT.
 
  default-rate : sets rate of a clock during boot, supported for any DT
 clock type (through generic clock driver)
  ti,default-parent : selects a default parent for a multiplexer clock,
  only supported for TI specific mux clock for now,
  as generic mux clock does not support DT clocks
 
  Patch #4 provided as a reference how to move the default rates / parents
  from kernel code to DT.
 
  Default-rate logic in patch #2 looks somewhat complicated, as the clocks
  need to be sorted based on their parents to avoid cases where a child clock
  would set its rate first, just to be overridden by its parent changing
  rate later and resulting in incorrect rate for the child clock.
 
  If the default-rate generic property is not going to fly, it can be moved
  to TI only drivers also.
 
  -Tero
 
 
  ___
  linux-arm-kernel mailing list
  linux-arm-ker...@lists.infradead.org
  http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
 
--
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

[RFC] possible removal of omap-serial

[Felipe Balbi]

Hi folks,

I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.

The original concern was wrt suspend/resume but I think it'd be a far
better approach to implement runtime PM in 8250 and write a rather small
8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
OMAP-specific details out of the way.

The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
instead of ttyS\d so removing omap-serial.c would have a direct impact
in userland. I wonder if it's an acceptable regression considering
we'd be able to reuse 8250 gaining proper Flow Control support, proper
DMA support, years and years of bug-fixes, etc.

What do you guys say ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] possible removal of omap-serial

[Greg KH]

On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
 Hi folks,
 
 I've been toying with the idea of removing
 drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
 ungly copy of 8250 driver.
 
 The original concern was wrt suspend/resume but I think it'd be a far
 better approach to implement runtime PM in 8250 and write a rather small
 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
 OMAP-specific details out of the way.
 
 The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
 instead of ttyS\d so removing omap-serial.c would have a direct impact
 in userland. I wonder if it's an acceptable regression considering
 we'd be able to reuse 8250 gaining proper Flow Control support, proper
 DMA support, years and years of bug-fixes, etc.

Breaking device node names is a contentious issue for serial ports, I
don't think you can do that :(

--
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: [RFC] possible removal of omap-serial

[Alan Cox]

On Thu, 2014-03-20 at 18:52 -0500, Felipe Balbi wrote:
 Hi folks,
 
 I've been toying with the idea of removing
 drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
 ungly copy of 8250 driver.
 
 The original concern was wrt suspend/resume but I think it'd be a far
 better approach to implement runtime PM in 8250 and write a rather small
 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
 OMAP-specific details out of the way.
 
 The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
 instead of ttyS\d so removing omap-serial.c would have a direct impact
 in userland. I wonder if it's an acceptable regression considering
 we'd be able to reuse 8250 gaining proper Flow Control support, proper
 DMA support, years and years of bug-fixes, etc.
 
 What do you guys say ?

I think it would be better even if we have to support calling it ttyO%d
somehow.

Alan


--
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: [RFC] possible removal of omap-serial

[Felipe Balbi]

Hi,

On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
 On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
  Hi folks,
  
  I've been toying with the idea of removing
  drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
  ungly copy of 8250 driver.
  
  The original concern was wrt suspend/resume but I think it'd be a far
  better approach to implement runtime PM in 8250 and write a rather small
  8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
  OMAP-specific details out of the way.
  
  The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
  instead of ttyS\d so removing omap-serial.c would have a direct impact
  in userland. I wonder if it's an acceptable regression considering
  we'd be able to reuse 8250 gaining proper Flow Control support, proper
  DMA support, years and years of bug-fixes, etc.
 
 Breaking device node names is a contentious issue for serial ports, I
 don't think you can do that :(

would an upstream udev rule creating a symbolic link from ttyO to ttyS
be enough ?

I didn't test this yet but I guess this is enough (?)

KERNEL==ttyO[0-9], GROUP=dialout, SYMLINK+=ttyS

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] possible removal of omap-serial

[Felipe Balbi]

On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
 Hi,
 
 On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
  On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
   Hi folks,
   
   I've been toying with the idea of removing
   drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
   ungly copy of 8250 driver.
   
   The original concern was wrt suspend/resume but I think it'd be a far
   better approach to implement runtime PM in 8250 and write a rather small
   8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
   OMAP-specific details out of the way.
   
   The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
   instead of ttyS\d so removing omap-serial.c would have a direct impact
   in userland. I wonder if it's an acceptable regression considering
   we'd be able to reuse 8250 gaining proper Flow Control support, proper
   DMA support, years and years of bug-fixes, etc.
  
  Breaking device node names is a contentious issue for serial ports, I
  don't think you can do that :(
 
 would an upstream udev rule creating a symbolic link from ttyO to ttyS
 be enough ?
 
 I didn't test this yet but I guess this is enough (?)
 
 KERNEL==ttyO[0-9], GROUP=dialout, SYMLINK+=ttyS

or actually it should be to other way around, ttyS would be the real
device:

KERNEL==ttyS[0-9], GROUP=dialout, SYMLINK+=ttyO

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] possible removal of omap-serial

[Greg KH]

On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
 On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
  Hi,
  
  On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
   On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,

I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.

The original concern was wrt suspend/resume but I think it'd be a far
better approach to implement runtime PM in 8250 and write a rather small
8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
OMAP-specific details out of the way.

The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
instead of ttyS\d so removing omap-serial.c would have a direct impact
in userland. I wonder if it's an acceptable regression considering
we'd be able to reuse 8250 gaining proper Flow Control support, proper
DMA support, years and years of bug-fixes, etc.
   
   Breaking device node names is a contentious issue for serial ports, I
   don't think you can do that :(
  
  would an upstream udev rule creating a symbolic link from ttyO to ttyS
  be enough ?
  
  I didn't test this yet but I guess this is enough (?)
  
  KERNEL==ttyO[0-9], GROUP=dialout, SYMLINK+=ttyS
 
 or actually it should be to other way around, ttyS would be the real
 device:
 
 KERNEL==ttyS[0-9], GROUP=dialout, SYMLINK+=ttyO

As udev rules don't ship with the kernel, this might be tough to do :(

Might be easier to make the 8250 driver handle different names like
Alan said.

greg k-h

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] possible removal of omap-serial

[Robert Nelson]

On Thu, Mar 20, 2014 at 9:36 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
 On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
  Hi,
 
  On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
   On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
Hi folks,
   
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
   
The original concern was wrt suspend/resume but I think it'd be a far
better approach to implement runtime PM in 8250 and write a rather 
small
8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get the
OMAP-specific details out of the way.
   
The question I have is: omap-serial.c calls the serial devnodes ttyO\d,
instead of ttyS\d so removing omap-serial.c would have a direct impact
in userland. I wonder if it's an acceptable regression considering
we'd be able to reuse 8250 gaining proper Flow Control support, proper
DMA support, years and years of bug-fixes, etc.
  
   Breaking device node names is a contentious issue for serial ports, I
   don't think you can do that :(
 
  would an upstream udev rule creating a symbolic link from ttyO to ttyS
  be enough ?
 
  I didn't test this yet but I guess this is enough (?)
 
  KERNEL==ttyO[0-9], GROUP=dialout, SYMLINK+=ttyS

 or actually it should be to other way around, ttyS would be the real
 device:

 KERNEL==ttyS[0-9], GROUP=dialout, SYMLINK+=ttyO

 As udev rules don't ship with the kernel, this might be tough to do :(

 Might be easier to make the 8250 driver handle different names like
 Alan said.

On the support side, I'm not looking forward to this for beagle/panda
users.  We've already converted them once from ttySx - ttyOx back in
2.6.33/2.6.34? days.  That was an irc/email/u-boot/kernel nightmare...

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
--
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: [RFC] possible removal of omap-serial

[Felipe Balbi]

On Thu, Mar 20, 2014 at 09:45:42PM -0500, Robert Nelson wrote:
 On Thu, Mar 20, 2014 at 9:36 PM, Greg KH gre...@linuxfoundation.org wrote:
  On Thu, Mar 20, 2014 at 08:37:29PM -0500, Felipe Balbi wrote:
  On Thu, Mar 20, 2014 at 08:35:57PM -0500, Felipe Balbi wrote:
   Hi,
  
   On Thu, Mar 20, 2014 at 05:12:28PM -0700, Greg KH wrote:
On Thu, Mar 20, 2014 at 06:52:10PM -0500, Felipe Balbi wrote:
 Hi folks,

 I've been toying with the idea of removing
 drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
 ungly copy of 8250 driver.

 The original concern was wrt suspend/resume but I think it'd be a far
 better approach to implement runtime PM in 8250 and write a rather 
 small
 8250-omap.c glue (much like 8250-acorn.c or 8250-dw.c) just to get 
 the
 OMAP-specific details out of the way.

 The question I have is: omap-serial.c calls the serial devnodes 
 ttyO\d,
 instead of ttyS\d so removing omap-serial.c would have a direct 
 impact
 in userland. I wonder if it's an acceptable regression considering
 we'd be able to reuse 8250 gaining proper Flow Control support, 
 proper
 DMA support, years and years of bug-fixes, etc.
   
Breaking device node names is a contentious issue for serial ports, I
don't think you can do that :(
  
   would an upstream udev rule creating a symbolic link from ttyO to ttyS
   be enough ?
  
   I didn't test this yet but I guess this is enough (?)
  
   KERNEL==ttyO[0-9], GROUP=dialout, SYMLINK+=ttyS
 
  or actually it should be to other way around, ttyS would be the real
  device:
 
  KERNEL==ttyS[0-9], GROUP=dialout, SYMLINK+=ttyO
 
  As udev rules don't ship with the kernel, this might be tough to do :(
 
  Might be easier to make the 8250 driver handle different names like
  Alan said.

I'll see if I find a way to avoid that or at least see if we find any
other way of creating a symlink... In any case, just switching back to
8250, even if just maintaining ttyO name, is already a big benefit.

 On the support side, I'm not looking forward to this for beagle/panda
 users.  We've already converted them once from ttySx - ttyOx back in
 2.6.33/2.6.34? days.  That was an irc/email/u-boot/kernel nightmare...

that's exactly why we're talking about ways to maintain backwards
compatibility here. But I'm more interested in finding a way to switch
over to ttyS and have a symlink to ttyO, that way a simple debootstrap
(or any other ARM distro minimal rootfs) would work out of the box,
without any changes, just like in normal systems.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5

[Lokesh Vutla]

From: Dave Gerlach d-gerl...@ti.com

Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.

Reported-by: Nishanth Menon n...@ti.com
Tested-by: Nishanth Menon n...@ti.com
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
This is applied on top of current linux-next.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master

 arch/arm/boot/dts/am437x-gp-evm.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..a055f7f 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -117,6 +117,11 @@
status = okay;
 };
 
+gpio5 {
+   status = okay;
+   ti,no-reset-on-init;
+};
+
 mmc1 {
status = okay;
vmmc-supply = vmmcsd_fixed;
-- 
1.7.9.5

--
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: am437x-gp-evm: Do not reset gpio5

[Felipe Balbi]

On Fri, Mar 21, 2014 at 10:50:13AM +0530, Lokesh Vutla wrote:
 From: Dave Gerlach d-gerl...@ti.com
 
 Do not reset GPIO5 at boot-up because GPIO5_7 is used
 on AM437x GP-EVM to control VTT regulators on DDR3.
 Without this some GP-EVM boards will fail to boot because
 of DDR3 corruption.
 
 Reported-by: Nishanth Menon n...@ti.com
 Tested-by: Nishanth Menon n...@ti.com
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com

every now and again we see a patch like this because yet another board
is using a GPIO to toggle DDR regulators.

Instead of constantly patching things like this, how about we try
something like below (build-tested only):

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1f33f5d..f5962ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2610,6 +2610,10 @@ static int __init _setup_reset(struct omap_hwmod *oh)
if (oh-flags  HWMOD_EXT_OPT_MAIN_CLK)
return -EPERM;
 
+   /* NEVER reset GPIO blocks */
+   if (strncmp(oh-name, gpio, 4) == 0)
+   return 0;
+
if (oh-rst_lines_cnt == 0) {
r = _enable(oh);
if (r) {
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 4243190..ce8b53a 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1130,6 +1130,29 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
 
 static const struct of_device_id omap_gpio_match[];
 
+static void omap_gpio_init_context(struct gpio_bank *p)
+{
+   struct omap_gpio_reg_offs *regs = p-regs;
+   void __iomem *base = p-base;
+
+   p-context.ctrl = readl_relaxed(base + regs-ctrl);
+   p-context.oe   = readl_relaxed(base + regs-direction);
+   p-context.wake_en  = readl_relaxed(base + regs-wkup_en);
+   p-context.leveldetect0 = readl_relaxed(base + regs-leveldetect0);
+   p-context.leveldetect1 = readl_relaxed(base + regs-leveldetect1);
+   p-context.risingdetect = readl_relaxed(base + regs-risingdetect);
+   p-context.fallingdetect = readl_relaxed(base + regs-fallingdetect);
+   p-context.irqenable1   = readl_relaxed(base + regs-irqenable);
+   p-context.irqenable2   = readl_relaxed(base + regs-irqenable2);
+
+   if (regs-set_dataout  p-regs-clr_dataout)
+   p-context.dataout = readl_relaxed(base + regs-set_dataout);
+   else
+   p-context.dataout = readl_relaxed(base + regs-dataout);
+
+   p-context_valid = true;
+}
+
 static int omap_gpio_probe(struct platform_device *pdev)
 {
struct device *dev = pdev-dev;
@@ -1246,6 +1269,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_mod_init(bank);
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
+   omap_gpio_init_context(bank);
 
pm_runtime_put(bank-dev);
 
@@ -1325,8 +1349,6 @@ update_gpio_context_count:
return 0;
 }
 
-static void omap_gpio_init_context(struct gpio_bank *p);
-
 static int omap_gpio_runtime_resume(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -1466,29 +1488,6 @@ void omap2_gpio_resume_after_idle(void)
 }
 
 #if defined(CONFIG_PM_RUNTIME)
-static void omap_gpio_init_context(struct gpio_bank *p)
-{
-   struct omap_gpio_reg_offs *regs = p-regs;
-   void __iomem *base = p-base;
-
-   p-context.ctrl = readl_relaxed(base + regs-ctrl);
-   p-context.oe   = readl_relaxed(base + regs-direction);
-   p-context.wake_en  = readl_relaxed(base + regs-wkup_en);
-   p-context.leveldetect0 = readl_relaxed(base + regs-leveldetect0);
-   p-context.leveldetect1 = readl_relaxed(base + regs-leveldetect1);
-   p-context.risingdetect = readl_relaxed(base + regs-risingdetect);
-   p-context.fallingdetect = readl_relaxed(base + regs-fallingdetect);
-   p-context.irqenable1   = readl_relaxed(base + regs-irqenable);
-   p-context.irqenable2   = readl_relaxed(base + regs-irqenable2);
-
-   if (regs-set_dataout  p-regs-clr_dataout)
-   p-context.dataout = readl_relaxed(base + regs-set_dataout);
-   else
-   p-context.dataout = readl_relaxed(base + regs-dataout);
-
-   p-context_valid = true;
-}
-
 static void omap_gpio_restore_context(struct gpio_bank *bank)
 {
writel_relaxed(bank-context.wake_en,

Then, we can even remove ti,no-reset flag from all GPIO DT nodes.

-- 
balbi


signature.asc
Description: Digital signature