[PATCH] regulator: tps65217: remove tps65217.dtsi file

2015-10-26 Thread Heiko Schocher 
remove tps65217.dtsi and adapt all boards, which
used it.

Signed-off-by: Heiko Schocher 
---
Suggested by Mark Brown, see:
https://lkml.org/lkml/2015/10/21/581

 .../devicetree/bindings/regulator/tps65217.txt | 78 --
 arch/arm/boot/dts/am335x-bone-common.dtsi  | 14 +++-
 arch/arm/boot/dts/am335x-chilisom.dtsi | 14 +++-
 arch/arm/boot/dts/am335x-nano.dts  | 14 +++-
 arch/arm/boot/dts/am335x-pepper.dts| 14 +++-
 arch/arm/boot/dts/am335x-sl50.dts  | 13 +++-
 arch/arm/boot/dts/tps65217.dtsi| 56 
 7 files changed, 58 insertions(+), 145 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/regulator/tps65217.txt
 delete mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt 
b/Documentation/devicetree/bindings/regulator/tps65217.txt
deleted file mode 100644
index 4f05d20..000
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-TPS65217 family of regulators
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- regulators: list of regulators provided by this controller, must be named
-  after their hardware counterparts: dcdc[1-3] and ldo[1-4]
-- regulators: This is the list of child nodes that specify the regulator
-  initialization data for defined regulators. Not all regulators for the given
-  device need to be present. The definition for each of these nodes is defined
-  using the standard binding for regulators found at
-  Documentation/devicetree/bindings/regulator/regulator.txt.
-
-Optional properties:
-- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
-
-  The valid names for regulators are:
-  tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
-   tps: tps@24 {
-   compatible = "ti,tps65217";
-   ti,pmic-shutdown-controller;
-
-   regulators {
-   dcdc1_reg: dcdc1 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <180>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   dcdc2_reg: dcdc2 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   dcdc3_reg: dcc3 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <150>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo1_reg: ldo1 {
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo2_reg: ldo2 {
-   regulator-min-microvolt = <90>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo3_reg: ldo3 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-
-   ldo4_reg: ldo4 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-boot-on;
-   regulator-always-on;
-   };
-   };
-   };
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index fec7834..0c4bde0 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,10 +285,8 @@
};
 };
 
-
-/include/ "tps65217.dtsi"
-
  {
+   compatible = "ti,tps65217";
/*
 * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
 * mode") at poweroff.  Most BeagleBone versions do not support RTC-only
@@ -309,12 +307,17 @@
ti,pmic-shutdown-controller;
 
regulators {
+   #address-cells = <1>;
+   #size-cells = <0>;

Re: [PATCH v10 2/4] PM / Domains: add setter for dev.pm_domain

2015-10-26 Thread Tomeu Vizoso 
On 25 October 2015 at 16:18, Rafael J. Wysocki  wrote:
> On Wednesday, October 21, 2015 05:34:12 PM Tomeu Vizoso wrote:
>> Adds a function that sets the pointer to dev_pm_domain in struct device
>> and that warns if the device has already finished probing. The reason
>> why we want to enforce that is because in the general case that can
>> cause problems and also that we can simplify code quite a bit if we can
>> always assume that.
>>
>> This patch also changes all current code that directly sets the
>> dev.pm_domain pointer.
>>
>> Signed-off-by: Tomeu Vizoso 
>> Reviewed-by: Ulf Hansson 
>> ---
>>
>> Changes in v9:
>> - Add docs noting the need for the device lock to be held before calling
>>   dev_pm_domain_set()
>>
>> Changes in v8:
>> - Add dev_pm_domain_set() and update code to use it
>>
>>  arch/arm/mach-omap2/omap_device.c |  7 ---
>>  drivers/acpi/acpi_lpss.c  |  5 +++--
>>  drivers/acpi/device_pm.c  |  5 +++--
>>  drivers/base/power/clock_ops.c|  5 +++--
>>  drivers/base/power/common.c   | 21 +
>>  drivers/base/power/domain.c   |  4 ++--
>>  drivers/gpu/vga/vga_switcheroo.c  | 10 +-
>>  drivers/misc/mei/pci-me.c |  5 +++--
>>  drivers/misc/mei/pci-txe.c|  5 +++--
>>  include/linux/pm_domain.h |  3 +++
>>  10 files changed, 50 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_device.c 
>> b/arch/arm/mach-omap2/omap_device.c
>> index 4cb8fd9f741f..204101d11632 100644
>> --- a/arch/arm/mach-omap2/omap_device.c
>> +++ b/arch/arm/mach-omap2/omap_device.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct 
>> platform_device *pdev)
>>   r->name = dev_name(>dev);
>>   }
>>
>> - pdev->dev.pm_domain = _device_pm_domain;
>> + dev_pm_domain_set(>dev, _device_pm_domain);
>>
>>   if (device_active) {
>>   omap_device_enable(pdev);
>> @@ -180,7 +181,7 @@ odbfd_exit1:
>>  odbfd_exit:
>>   /* if data/we are at fault.. load up a fail handler */
>>   if (ret)
>> - pdev->dev.pm_domain = _device_fail_pm_domain;
>> + dev_pm_domain_set(>dev, _device_fail_pm_domain);
>>
>>   return ret;
>>  }
>> @@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
>>  {
>>   pr_debug("omap_device: %s: registering\n", pdev->name);
>>
>> - pdev->dev.pm_domain = _device_pm_domain;
>> + dev_pm_domain_set(>dev, _device_pm_domain);
>>   return platform_device_add(pdev);
>>  }
>>
>> diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
>> index f51bd0d0bc17..cc6e1abc69b3 100644
>> --- a/drivers/acpi/acpi_lpss.c
>> +++ b/drivers/acpi/acpi_lpss.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct 
>> notifier_block *nb,
>>
>>   switch (action) {
>>   case BUS_NOTIFY_ADD_DEVICE:
>> - pdev->dev.pm_domain = _lpss_pm_domain;
>> + dev_pm_domain_set(>dev, _lpss_pm_domain);
>>   if (pdata->dev_desc->flags & LPSS_LTR)
>>   return sysfs_create_group(>dev.kobj,
>> _attr_group);
>> @@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct 
>> notifier_block *nb,
>>   case BUS_NOTIFY_DEL_DEVICE:
>>   if (pdata->dev_desc->flags & LPSS_LTR)
>>   sysfs_remove_group(>dev.kobj, _attr_group);
>> - pdev->dev.pm_domain = NULL;
>> + dev_pm_domain_set(>dev, NULL);
>>   break;
>>   default:
>>   break;
>> diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
>> index 4806b7f856c4..8c5955bf9bbf 100644
>> --- a/drivers/acpi/device_pm.c
>> +++ b/drivers/acpi/device_pm.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "internal.h"
>> @@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, 
>> bool power_off)
>>   struct acpi_device *adev = ACPI_COMPANION(dev);
>>
>>   if (adev && dev->pm_domain == _general_pm_domain) {
>> - dev->pm_domain = NULL;
>> + dev_pm_domain_set(dev, NULL);
>>   acpi_remove_pm_notifier(adev);
>>   if (power_off) {
>>   /*
>> @@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool 
>> power_on)
>>   return -EBUSY;
>>
>>   acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
>> - dev->pm_domain = _general_pm_domain;
>> + dev_pm_domain_set(dev, _general_pm_domain);
>>   if (power_on) {
>>   acpi_dev_pm_full_power(adev);
>>   acpi_device_wakeup(adev,

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

2015-10-26 Thread Brian Norris 
Hi Roger,

I'm not too familiar with OMAP platforms, and I might have missed out on
prior discussions/context, so please forgive if I'm asking silly or old
questions here.

On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.

Have you pinpointed the exact causes for the performance increase, or
can you give an educated guess? AIUI, you're reducing the number of
interrupts needed for NAND prefetch mode, but you're also removing a bit
of abstraction and implementing hooks that look awfully like the
existing abstractions:

+   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
+   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
+   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
+   u32 (*nand_irq_status)(void);

That's not really a problem if there's a good reason for them (brcmnand
implements similar hooks because of quirks in the implementation of
interrupts across various BRCM SoCs, and it's not worth writing irqchip
drivers for those cases). I'm mainly curious for an explanation.

Regards,
Brian
--
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 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

2015-10-26 Thread Brian Norris 
+ others

A few comments below.

On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> The GPMC WAIT pin status are now available over gpiolib.
> Update the omap_dev_ready() function to use gpio instead of
> directly accessing GPMC register space.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/mtd/nand/omap2.c | 29 
> +---
>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>  2 files changed, 19 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 228f498..d0f2620 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -184,6 +185,8 @@ struct omap_nand_info {
>   /* fields specific for BCHx_HW ECC scheme */
>   struct device   *elm_dev;
>   struct device_node  *of_node;
> + /* NAND ready gpio */
> + struct gpio_desc*ready_gpiod;
>  };
>  
>  /**
> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
> nand_chip *chip)
>  }
>  
>  /**
> - * omap_dev_ready - calls the platform specific dev_ready function
> + * omap_dev_ready - checks the NAND Ready GPIO line
>   * @mtd: MTD device structure
> + *
> + * Returns true if ready and false if busy.
>   */
>  static int omap_dev_ready(struct mtd_info *mtd)
>  {
> - unsigned int val = 0;
>   struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>   mtd);
>  
> - val = readl(info->reg.gpmc_status);
> -
> - if ((val & 0x100) == 0x100) {
> - return 1;
> - } else {
> - return 0;
> - }
> + return gpiod_get_value(info->ready_gpiod);
>  }
>  
>  /**
> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>   info->reg = pdata->reg;
>   info->of_node = pdata->of_node;
>   info->ecc_opt = pdata->ecc_opt;
> - info->dev_ready = pdata->dev_ready;
> + if (pdata->dev_ready)
> + dev_info(>dev, "pdata->dev_ready is 
> deprecated\n");
> +
>   info->xfer_type = pdata->xfer_type;
>   info->devsize = pdata->devsize;
>   info->elm_of_node = pdata->elm_of_node;
> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>   nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>   nand_chip->cmd_ctrl  = omap_hwcontrol;
>  
> + info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> + GPIOD_IN);

Others have been looking at using GPIOs for the ready/busy pin too. At a
minimum, we need an updated DT binding doc for this, since I see you're
adding this via device tree in a later patch (I don't see any DT binding
patch for this; but I could just be overlooking it). It'd also be great
if this support was moved to nand_dt_init() so other platforms can
benefit, but I won't require that.

Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
(the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
really care, but the name should be going into a doc, so we can choose
the same one everywhere.

EDIT: looks like the discussion was partly here [1] and it seems we're
landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Regards,
Brian

[0] "Previous" may be subject to debate, as both series have been going
for several revisions.
[1] http://patchwork.ozlabs.org/patch/515327/
[2] http://patchwork.ozlabs.org/patch/526819/

> + if (IS_ERR(info->ready_gpiod)) {
> + dev_err(dev, "failed to get ready gpio\n");
> + return PTR_ERR(info->ready_gpiod);
> + }
> +
>   /*
>* If RDY/BSY line is connected to OMAP then use the omap ready
>* function and the generic nand_wait function which reads the status
> @@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device *pdev)
>* chip delay which is slightly more than tR (AC Timing) of the NAND
>* device and read status register until you get a failure or success
>*/
> - if (info->dev_ready) {
> + if (info->ready_gpiod) {
>   nand_chip->dev_ready = omap_dev_ready;
>   nand_chip->chip_delay = 0;
>   } else {
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
> b/include/linux/platform_data/mtd-nand-omap2.h
> index ff27e5a..19e509d 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -70,7 +70,6 @@ struct omap_nand_platform_data {
>   int cs;
>   struct mtd_partition*parts;
>   int nr_parts;
> - booldev_ready;
>   boolflash_bbt;
>

Re: [PATCH v2 00/14] dmaenigne: edma/ti-crossbar: fixes, new bindings

2015-10-26 Thread Vinod Koul 
On Fri, Oct 16, 2015 at 10:17:58AM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since v1:
> - Comments in the memcpy optimization patch extended
> - The crossbar patch has been improved:
>  - debug prints changed
>  - fallback xbar parameters now type specific as the fallback values for DRA7
>are not valid for AM33xx crossbar.
> - New patch for Kconfig to select the crossbar in case the eDMA is used on 
> OMAP
>   platforms
> 
I am applying this series and Please note that this has ARM patches which i
have not heard any objections so applying :)

-- 
~Vinod
--
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: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

2015-10-26 Thread Javier Martinez Canillas 
Hello Andrew,

On Sun, Oct 25, 2015 at 2:05 AM, Andrew F. Davis  wrote:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments. AM33XX_IOPAD allows us to use part of the
> pinctrl physical address as in the TRM instead of an offset.
>
> Signed-off-by: Andrew F. Davis 
> ---

I haven't verified the values against the TRM, but assuming there are correct:

Reviewed-by: Javier Martinez Canillas 

Best regards,
Javier
--
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] regulator: tps65217: remove tps65217.dtsi file

2015-10-26 Thread Mark Brown 
On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote:
> remove tps65217.dtsi and adapt all boards, which
> used it.

Acked-by: Mark Brown 

but really this is a DTS change so I'd expect it to go via arm-soc
rather than me.


signature.asc
Description: PGP signature

[PATCH] ARM: OMAP1: fix incorrect INT_DMA_LCD

2015-10-26 Thread Aaro Koskinen 
Commit 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for
sparse IRQ") turned on SPARSE_IRQ on OMAP1, but forgot to change
the number of INT_DMA_LCD. This broke the boot at least on Nokia 770,
where the device hangs during framebuffer initialization.

Fix by defining INT_DMA_LCD like the other interrupts.

Cc: sta...@vger.kernel.org
Fixes: 685e2d08c54b ("ARM: OMAP1: Change interrupt numbering for sparse IRQ")
Signed-off-by: Aaro Koskinen 
---
 include/linux/omap-dma.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index e5a7013..88fa8af 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -17,7 +17,7 @@
 
 #include 
 
-#define INT_DMA_LCD25
+#define INT_DMA_LCD(NR_IRQS_LEGACY + 25)
 
 #define OMAP1_DMA_TOUT_IRQ (1 << 0)
 #define OMAP_DMA_DROP_IRQ  (1 << 1)
-- 
2.4.0

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

[PATCH] ARM: dts: Enable Shared Transport and Bluetooth on LogicPD Torpedo + Wireless module

2015-10-26 Thread Adam Ford 
Configure the shared transport which enables communication with GPS/Bluetooth 
module.
Setup UART2 for communication at 3MBps with flow control.
Setup GPIO_162 as Bluetooth Enable.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index c8091ff..b7460ea 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -32,6 +32,18 @@
enable-active-high;
vin-supply = <>;
};
+
+   kim {
+   compatible = "kim";
+   nshutdown_gpio = <162>; /* Bank3, pin21 */
+   dev_name = "/dev/ttyO1";
+   flow_cntrl = <1>;
+   baud_rate = <30>;
+   };
+
+   btwilink {
+   compatible = "btwilink";
+   };
 };
 
  {
@@ -157,6 +169,21 @@
OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)   
/* mcbsp2_dx */
>;
};
+   uart2_pins: pinmux_uart2_pins {
+pinctrl-single,pins = <
+OMAP3_CORE1_IOPAD(0x2174, PIN_INPUT | MUX_MODE0)   
/* uart2_cts.uart2_cts */
+OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE0)  
/* uart2_rts .uart2_rts*/
+OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE0)  
/* uart2_tx.uart2_tx */
+OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)   
/* uart2_rx.uart2_rx */
+   OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)   
/* GPIO_162,BT_EN */
+>;
+};
+};
+
+ {
+   interrupts-extended = < 73 _pmx_core OMAP3_UART2_RX>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins>;
 };
 
 _pmx_core2 {
-- 
1.9.1

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

Question about TI Shared Transport

2015-10-26 Thread Adam Ford 
Gigi,

I am working on modifying the DTS and DTSI files for the LogicPD Torpedo which 
Tony added in Kernel 4.2

There was a flurry of activity earlier this year regarding device tree bindings 
for the shared transport and using the Bluetooth with it as seen here:  
https://patchwork.ozlabs.org/patch/464777/

I was able to get the Logic PD device to work with Bluetooth and the Shared 
Transport using the instructions found 
http://processors.wiki.ti.com/index.php/Shared_Transport_Driver#Device_Tree_kernel

When I attempted to submit patches for the btwilink, the check script noted 
that the documentation for btwlink and shared transport bindings were missing.  
It seems like there might be a new way to attach the BTWILINK to the UART, but 
I wasn't sure if there was a better solution available yet.

I also noticed that using the shared transport mechanism in 4.2.x worked, but 
trying the same method in 4.3 resulted in a segmentation fault.  Does anyone 
have any updated instructions for the proper way to use the BTWILINK?

Thank you,
adam

Adam Ford  //  Sr. Apps Engineer
Logic PD
411 Washington Ave N, Suite 400  
Minneapolis, MN 55401
M // 612.246.6391
T // 612.436.5117x7113
F // 612.672.6489
adam.f...@logicpd.com  
Logic PD // Twitter // LinkedIn

NOTICE: Important disclaimers and limitations apply to this email.
Please see this web page for our disclaimers and limitations:
http://logicpd.com/email-disclaimer/


--
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 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-26 Thread Franklin S Cooper Jr. 


On 10/23/2015 02:00 PM, Paul Walmsley wrote:
> On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote:
>
>> ELM address information is provided by device tree. No longer need
>> to include this information within hwmod.
>>
>> Signed-off-by: Franklin S Cooper Jr 
> The OMAP4 DTS files don't have the ELM address space declared.  I'm going 
> to drop that portion of your patch.  Could you please send a two-patch 
> series that first adds the ELM address space to the OMAP4 DTS file and 
> then subsequently drops it from the OMAP4 hwmod data file?
Hi Paul,

Sorry about that. I can create the patches but I don't see any board omap4
board that has nand support. So I'm not going to be able to test to insure if
omap_elm.c will work as is.

Should I just drop omap4 from this patchset or should I just add the elm node
to omap4.dtsi and if people report an issue with omap_elm then we can fix it?


>
>
> - Paul

--
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: Question about TI Shared Transport

2015-10-26 Thread Grygorii Strashko 

On 10/26/2015 03:58 PM, Adam Ford wrote:

Gigi,

I am working on modifying the DTS and DTSI files for the LogicPD Torpedo which 
Tony added in Kernel 4.2

There was a flurry of activity earlier this year regarding device tree bindings 
for the shared transport and using the Bluetooth with it as seen here:  
https://patchwork.ozlabs.org/patch/464777/

I was able to get the Logic PD device to work with Bluetooth and the Shared 
Transport using the instructions found 
http://processors.wiki.ti.com/index.php/Shared_Transport_Driver#Device_Tree_kernel

When I attempted to submit patches for the btwilink, the check script noted 
that the documentation for btwlink and shared transport bindings were missing.  
It seems like there might be a new way to attach the BTWILINK to the UART, but 
I wasn't sure if there was a better solution available yet.

I also noticed that using the shared transport mechanism in 4.2.x worked, but 
trying the same method in 4.3 resulted in a segmentation fault.  Does anyone 
have any updated instructions for the proper way to use the BTWILINK?



It is not worked because OF support was reverted:
c0bd1b9 Revert "ti-st: add device tree support"


--
regards,
-grygorii
--
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: Question about TI Shared Transport

2015-10-26 Thread Adam Ford 
The revert appears in the 4.2.4 log as well, so it happened before 4.2 was 
released. From what I can see, that ti-st directory hasn't changed between 
4.2.4 and the 4.3.

-Original Message-
From: Grygorii Strashko [mailto:grygorii.stras...@ti.com] 
Sent: Monday, October 26, 2015 9:55 AM
To: Adam Ford ; 'gigi.jos...@ti.com' 
; 'mar...@holtmann.org' ; 
'devicet...@vger.kernel.org' 
Cc: 'Tony Lindgren' ; 'linux-omap@vger.kernel.org' 
; Sekhar Nori 
Subject: Re: Question about TI Shared Transport

On 10/26/2015 03:58 PM, Adam Ford wrote:
> Gigi,
>
> I am working on modifying the DTS and DTSI files for the LogicPD Torpedo 
> which Tony added in Kernel 4.2
>
> There was a flurry of activity earlier this year regarding device tree 
> bindings for the shared transport and using the Bluetooth with it as seen 
> here:  https://patchwork.ozlabs.org/patch/464777/
>
> I was able to get the Logic PD device to work with Bluetooth and the Shared 
> Transport using the instructions found 
> http://processors.wiki.ti.com/index.php/Shared_Transport_Driver#Device_Tree_kernel
>
> When I attempted to submit patches for the btwilink, the check script noted 
> that the documentation for btwlink and shared transport bindings were 
> missing.  It seems like there might be a new way to attach the BTWILINK to 
> the UART, but I wasn't sure if there was a better solution available yet.
>
> I also noticed that using the shared transport mechanism in 4.2.x worked, but 
> trying the same method in 4.3 resulted in a segmentation fault.  Does anyone 
> have any updated instructions for the proper way to use the BTWILINK?
>

It is not worked because OF support was reverted:
c0bd1b9 Revert "ti-st: add device tree support"


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

[PATCH] ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit

2015-10-26 Thread Adam Ford 
When used with the Logic PD development kit, this makes the I2C buses match
the BSP released by Logic PD.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 36387b1..8b803ed 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -99,6 +99,14 @@
};
 };
 
+ {
+   clock-frequency = <40>;
+};
+
+ {
+   clock-frequency = <40>;
+};
+
 /*
  * Only found on the wireless SOM. For the SOM without wireless, the pins for
  * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
-- 
1.9.1

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

[PATCH] ARM: dts: Enable Shared Transport and Bluetooth on LogicPD Torpedo + Wireless module

2015-10-26 Thread Adam Ford 
Configure the shared transport which enables communication with GPS/Bluetooth 
module.
Setup UART2 for communication at 3MBps with flow control.
Setup GPIO_162 as Bluetooth Enable.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index c8091ff..0ce3bc0 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -32,6 +32,18 @@
enable-active-high;
vin-supply = <>;
};
+
+   kim {
+   compatible = "kim";
+   nshutdown_gpio = <162>; /* Bank3, pin21 */
+   dev_name = "/dev/ttyO1";
+   flow_cntrl = <1>;
+   baud_rate = <30>;
+   };
+
+   btwilink {
+   compatible = "btwilink";
+   };
 };
 
  {
@@ -157,6 +169,21 @@
OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0)   
/* mcbsp2_dx */
>;
};
+   uart2_pins: pinmux_uart2_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x2174, PIN_INPUT | MUX_MODE0)
/* uart2_cts.uart2_cts */
+   OMAP3_CORE1_IOPAD(0x2176, PIN_OUTPUT | MUX_MODE0)   
/* uart2_rts .uart2_rts*/
+   OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE0)   
/* uart2_tx.uart2_tx */
+   OMAP3_CORE1_IOPAD(0x217a, PIN_INPUT | MUX_MODE0)
/* uart2_rx.uart2_rx */
+   OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)   
/* GPIO_162,BT_EN */
+   >;
+   };
+};
+
+ {
+   interrupts-extended = < 73 _pmx_core OMAP3_UART2_RX>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
 _pmx_core2 {
-- 
1.9.1

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

[PATCH] ARM: dts: Set VAUX1 and VAUX4 on Logic PD Torpedo

2015-10-26 Thread Adam Ford 
The schematic expects VAUX1 to be 3.0V attached to the debug port.
The schematic expects VAUX4 to be 1.8V.
VAUX4 powers VDDS_CSI2 on processor.

Signed-off-by: Adam Ford 
---
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index afc13e5..b07d1d9 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,6 +73,16 @@
};
 };
 
+ {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+};
+
+ {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+};
+
  {
status = "okay";
 };
-- 
1.9.1

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

Re: [PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-26 Thread Paul Walmsley 
Hi Franklin,

On Mon, 26 Oct 2015, Franklin S Cooper Jr. wrote:

> On 10/23/2015 02:00 PM, Paul Walmsley wrote:
> > On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote:
> >
> >> ELM address information is provided by device tree. No longer need
> >> to include this information within hwmod.
> >>
> >> Signed-off-by: Franklin S Cooper Jr 
> > The OMAP4 DTS files don't have the ELM address space declared.  I'm going 
> > to drop that portion of your patch.  Could you please send a two-patch 
> > series that first adds the ELM address space to the OMAP4 DTS file and 
> > then subsequently drops it from the OMAP4 hwmod data file?
> Hi Paul,
> 
> Sorry about that. I can create the patches but I don't see any board omap4
> board that has nand support. So I'm not going to be able to test to insure if
> omap_elm.c will work as is.
> 
> Should I just drop omap4 from this patchset or should I just add the elm node
> to omap4.dtsi and if people report an issue with omap_elm then we can fix it?

Please write the OMAP4 patches since we're trying to get the data cleaned 
up.  You don't need to worry about the DRA7/335x/437x platforms; those 
patches have already been merged.  The ELM hwmod should be initialized 
even on boards without NAND, so that should be a reasonable test of the 
register address space, at least.  Please note in the patch description 
whether your patches are untested, tested just to initialize/boot, or 
whether they've been tested on an active NAND flash workload.

thanks

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