Re: twl4030_charger: need changes to get probed?

[Sebastian Reichel]

Hi,

On Mon, Mar 09, 2015 at 11:06:53AM +1100, NeilBrown wrote:
 On Sat, 7 Mar 2015 22:01:02 +0100 Sebastian Reichel s...@debian.org wrote:
  platform_driver_probe() does not support deferred probing.
  
  Neil, can you take this patch into your series for the next round?
 
 I could, but I do wonder if it is the right thing to do.
 
 Shouldn't we fix platform_driver_probe() to support deferred probing.

well most drivers use platform_driver_register anyways. Other
subsystems, like e.g. i2c have converted all drivers already.
In drivers/power/ there are only three drivers using
platform_driver_probe:

drivers/power/avs/smartreflex.c - ok here
drivers/power/reset/brcmstb-reboot.c - looks ok, too
drivers/power/twl4030_charger.c - should probably be converted

 As I understand it, it refused to retry a probe if there is an error, and the
 comments suggest that such retrying is avoided because it would be a waste
 of time:
 
   /*
* Prevent driver from requesting probe deferral to avoid further
* futile probe attempts.
*/
 
 In this case, it isn't futile.

All drivers would benefit of being probed again if they returned
EPROBEDEFER, but their probe function can't be called again if
they use driver_platform_probe, since the probe function will be
unloaded when it should be called again. Apart from that the
.probe function pointer is not set. Thus trying to probe the
driver again at a later point is a waste of time and futile,
since it will definitely fail.

 Earlier there is a comment saying:
 
  * Use this instead of platform_driver_register() when you know the device
  * is not hotpluggable and has already been registered, and you want to
  * remove its run-once probe() infrastructure from memory after the driver
  * has bound to the device.
 
 I presume all this applies.  I assume that the only problem is a probe-order
 thing.  So maybe we should fix platform_driver_probe() to do the right thing
 with -EPROBEDEFER??
 
 Trouble is, I really don't understand the  point or mechanism for
 platform_driver_probe(), so I cannot suggest anything.
 But I have been annoyed before that platform_driver_probe doesn't cope with
 EPROBEDEFER, so I would like it fixed.

platform_driver_probe is not about probe-order, but about not having
the probe function in memory once the driver is loaded. So the probe
function cannot be called again. If you don't want this use
platform_driver_register, as most drivers actually do.

I guess we should add some coccinelle scripts for detection of
potentially broken drivers (e.g. everything requesting gpios/pinctrl
together with platform_driver_register).

-- Sebastian


signature.asc
Description: Digital signature

[GIT PULL] OMAP-GPMC driver updates for v4.1

[Roger Quadros]

Hi Arnd,

Based on Tony's request I will be sending you pull requests for OMAP-GPMC driver
hence forth.

Please pull in these OMAP-GPMC driver fixes for v4.1.
Patches have been tested for GPMC-NAND on dra7-evm and omap3-beagle.

Thanks.

The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:

  Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)

are available in the git repository at:

  g...@github.com:rogerq/linux.git tags/gpmc-omap-for-v4.1

for you to fetch changes up to 4b613e9b4bbe94545a588a100e09006d827a7ebe:

  ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters 
(2015-03-06 12:55:32 +0200)


OMAP-GPMC driver fixes for v4.1

* Fixed WAITMONITORINGTIME programming to be based on
GPMC_CLK instead of GPMC_FCLK. The GPMC clock divider
programming is fixed for both synchronous and asynchronous
modes.
* Allow GPMC's children of default bus type to be populated in
the device tree.
* Improved DEBUG output data and format.
* Prevent writing 1 into reserved bits of GPMC_CONFIG7.


Robert ABEL (8):
  ARM OMAP2+ GPMC: don't undef DEBUG
  ARM OMAP2+ GPMC: add bus children
  ARM OMAP2+ GPMC: fix debug output alignment
  ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
  ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
  ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME
  ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug
  ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters

Semen Protsenko (2):
  ARM: OMAP2+: gpmc: Fix writing in gpmc_cs_set_memconf
  ARM: OMAP2+: gpmc: make gpmc_cs_get_name() static

 arch/arm/mach-omap2/gpmc-nand.c|  18 +
 arch/arm/mach-omap2/gpmc-onenand.c |   4 +-
 arch/arm/mach-omap2/usb-tusb6010.c |   4 +-
 drivers/memory/omap-gpmc.c | 358 
+++-
 include/linux/omap-gpmc.h  |   3 +-
 5 files changed, 305 insertions(+), 82 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions

[Rafael J. Wysocki]

On Sunday, March 08, 2015 11:43:34 AM Alan Stern wrote:
 On Sat, 7 Mar 2015, Rafael J. Wysocki wrote:
 
  But this is part of a bigger picture.  Namely, if a separete wakeup 
  interrupt
  is required for a device, the device's power.can_wakeup flag cannot be set
  until that interrupt has been successfully requested.  Also for devices that
  can signal wakeup via their own IO interrupts, it would make sense to allow
  those interrupts to be registered somehow as wakeup interrupts.
  
  So I wonder if we can define a new struct along the lines of your
  struct wakeirq_source, but call it struct wake_irq and make it look
  something like this:
  
  struct wake_irq {
 struct device *dev;
 int irq;
 irq_handler_t handler;
  };
  
  Then, add a struct wake_irq pointer to struct dev_pm_info *and* to
  struct wakeup_source.  Next, make dev_pm_request_wake_irq() allocate the
  structure and request the interrupt and only set the pointer to it from
  struct dev_pm_info *along* *with* power.can_wakeup if all that was
  successful.
  
  For devices that use their own IO IRQ for wakeup, we can add something
  like dev_pm_set_wake_irq() that will work analogously, but without 
  requesting
  the interrupt.  It will just set the dev and irq members of struct wake_irq
  and point struct dev_pm_info to it and set its power.can_wakeup flag.
  
  Then, device_wakeup_enable() will be able to see that the device has a
  wakeup IRQ and it may then point its own struct wake_irq pointer to that.
  The core may then use that pointer to trigger enable_irq_wake() for the
  IRQ in question and it will cover the devices that don't need separate
  wakeup interrupts too.
  
  Does that make sense to you?
 
 Can we back up a little?  What is the basic problem the two of you are 
 trying to solve?

Essentially, code duplication between drivers that all need to do the same
thing which can be moved to the core quite easily.

Rafael

--
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 0/6] dmaengine/dra7x: DMA router (crossbar support)

[Peter Ujfalusi]

Hi,

On 02/24/2015 04:21 PM, Peter Ujfalusi wrote:
 Hi,
 
 The series adds support for DMA router type of devices. They are used in SoCs
 which has more peripherals with DMA request lines than the DMA controller can
 handle.
 The router itself is not part of the DMA controller and it's operation should 
 be
 transparent (as it is in the HW) for the SW stack.
 
 This series takes into accound the comments Sricharan received for his version
 of the crossbar driver:
 https://lkml.org/lkml/2014/3/7/199
 
 This implementation is not tied to any DMA driver so it is possible to use the
 framework by other vendors, also ACPI version of binding can be easy enough to
 be added.
 
 The omap-dma part of changes are based on the dma property name change series:
 https://lkml.org/lkml/2015/2/20/182
 
 but the code has fallback so it is working w/o the changes in that series.

Gentle ping on this series before I send the V2 with the comments from Russell
and Paul addressed.

Kind Regards,
Péter

 
 Regards,
 Peter
 ---
 Peter Ujfalusi (6):
   dmaengine: of_dma: Support for DMA routers
   dmaengine: Add driver for TI DMA crossbar on DRA7x
   dmaengine: omap-dma: Use defines for dma channels and request count
   dmaengine: omap-dma: Take DMA request number from DT if it is
 available
   dmaengine: omap-dma: Remove mapping between virtual channels and
 requests
   ARM: DTS: dra7x: Integrate sDMA crossbar
 
  Documentation/devicetree/bindings/dma/dma.txt |  27 
  arch/arm/boot/dts/dra7.dtsi   |  57 
  drivers/dma/Kconfig   |   4 +
  drivers/dma/Makefile  |   1 +
  drivers/dma/dmaengine.c   |   7 +
  drivers/dma/of-dma.c  |  92 +
  drivers/dma/omap-dma.c|  24 +++-
  drivers/dma/ti-dma-crossbar.c | 191 
 ++
  include/linux/dmaengine.h |  17 +++
  include/linux/of_dma.h|  21 +++
  10 files changed, 413 insertions(+), 28 deletions(-)
  create mode 100644 drivers/dma/ti-dma-crossbar.c
 

--
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: RGB LED control (was Re: advanced LED controllers)

[Måns Rullgård]

Geert Uytterhoeven ge...@linux-m68k.org writes:

 Hi Pavel,

 On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek pa...@ucw.cz wrote:
 Ok, so I played with RGB LED a bit, and we have quite a gap in
 documentation: what 50% brightness means is non-trivial and very
 important in case we want to do smooth blinking and color transitions.

 Signed-off-by: Pavel Machek pa...@ucw.cz

 diff --git a/Documentation/ABI/testing/sysfs-class-led 
 b/Documentation/ABI/testing/sysfs-class-led
 index 3646ec8..649d7a6 100644
 --- a/Documentation/ABI/testing/sysfs-class-led
 +++ b/Documentation/ABI/testing/sysfs-class-led
 @@ -8,6 +8,11 @@ Description:
 non-zero brightness settings. The value is between 0 and
 /sys/class/leds/led/max_brightness.

 +   If LED supports continuous brightness settings, 50% 
 brightness
 +   should correspond to 50% brightness perceived by human, in a 
 similar
 +   manner pixel brightness on monitor does (not 50% PWM).

 How many drivers do it right? How many don't?

 For those that don't, perhaps we handle the conversion between perceived and
 pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate
 the need for conversion?

Some LED controllers do the right thing in hardware, so any adjustment
done in the core needs to be optional.

-- 
Måns Rullgård
m...@mansr.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

[PATCH v5 1/3] dt: bindings: add wl18xx wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wl18xx
wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
 .../devicetree/bindings/net/wireless/ti,wl18xx.txt | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
new file mode 100644
index 000..9dcf535
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
@@ -0,0 +1,39 @@
+TI Wilink8 (wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink8 wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible : Should be ti,wl18xx.
+ - compatible: should be one of the following:
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_NONE;
+   };
+};
-- 
1.8.5.2.229.g4448466.dirty

--
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 v5 2/3] wl18xx: add basic device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

For now, parse only the irq used. Other (optional) properties
can be added later on.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wlcore/sdio.c | 80 ---
 1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index d3dd7bf..ee556ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,69 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl1801 },
+   { .compatible = ti,wl1805 },
+   { .compatible = ti,wl1807 },
+   { .compatible = ti,wl1831 },
+   { .compatible = ti,wl1835 },
+   { .compatible = ti,wl1837 },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+   return NULL;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   /* first, look for DT data */
+   pdata = wlcore_probe_of(dev);
+   if (pdata)
+   return pdata;
+
+   /* if not found - fallback to static platform data */
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   dev_err(dev, No platform data set\n);
+   return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +310,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +341,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +375,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +388,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue);
 }
 
-- 
1.8.5.2.229.g4448466.dirty

--
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 11/18] omap3isp: Replace many MMIO regions by two

[Tony Lindgren]

* Laurent Pinchart laurent.pinch...@ideasonboard.com [150307 15:43]:
 Hi Sakari,
 
 Thank you for the patch.
 
 (CC'ing linux-omap and Tony)
 
 On Saturday 07 March 2015 23:41:08 Sakari Ailus wrote:
  The omap3isp MMIO register block is contiguous in the MMIO register space
  apart from the fact that the ISP IOMMU register block is in the middle of
  the area. Ioremap it at two occasions, and keep the rest of the layout of
  the register space internal to the omap3isp driver.
  
  Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 
  ---
   arch/arm/mach-omap2/devices.c |   66 +--
   arch/arm/mach-omap2/omap34xx.h|   36 +--
 
 Once again you might be asked to split this. However, it would be pretty 
 painful, so it would be nice if we could merge everything through the Linux 
 media tree. You will need an ack from Tony.

These changes look fine to me and should not conflict with anything
I'm planning to queue, so please feel free to take them along with
the other isp changes:

Acked-by: Tony Lindgren t...@atomide.com
 
   drivers/media/platform/omap3isp/isp.c |  113 --
   drivers/media/platform/omap3isp/isp.h |4 +-
   4 files changed, 66 insertions(+), 153 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
  index e945957..990338f 100644
  --- a/arch/arm/mach-omap2/devices.c
  +++ b/arch/arm/mach-omap2/devices.c
  @@ -74,72 +74,12 @@ omap_postcore_initcall(omap3_l3_init);
   static struct resource omap3isp_resources[] = {
  {
  .start  = OMAP3430_ISP_BASE,
  -   .end= OMAP3430_ISP_END,
  +   .end= OMAP3430_ISP_BASE + 0x12fc,
  .flags  = IORESOURCE_MEM,
  },
  {
  -   .start  = OMAP3430_ISP_CCP2_BASE,
  -   .end= OMAP3430_ISP_CCP2_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_CCDC_BASE,
  -   .end= OMAP3430_ISP_CCDC_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_HIST_BASE,
  -   .end= OMAP3430_ISP_HIST_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_H3A_BASE,
  -   .end= OMAP3430_ISP_H3A_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_PREV_BASE,
  -   .end= OMAP3430_ISP_PREV_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_RESZ_BASE,
  -   .end= OMAP3430_ISP_RESZ_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_SBL_BASE,
  -   .end= OMAP3430_ISP_SBL_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_CSI2A_REGS1_BASE,
  -   .end= OMAP3430_ISP_CSI2A_REGS1_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3430_ISP_CSIPHY2_BASE,
  -   .end= OMAP3430_ISP_CSIPHY2_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3630_ISP_CSI2A_REGS2_BASE,
  -   .end= OMAP3630_ISP_CSI2A_REGS2_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3630_ISP_CSI2C_REGS1_BASE,
  -   .end= OMAP3630_ISP_CSI2C_REGS1_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3630_ISP_CSIPHY1_BASE,
  -   .end= OMAP3630_ISP_CSIPHY1_END,
  -   .flags  = IORESOURCE_MEM,
  -   },
  -   {
  -   .start  = OMAP3630_ISP_CSI2C_REGS2_BASE,
  -   .end= OMAP3630_ISP_CSI2C_REGS2_END,
  +   .start  = OMAP3430_ISP_BASE2,
  +   .end= OMAP3430_ISP_BASE2 + 0x0600,
  .flags  = IORESOURCE_MEM,
  },
  {
  diff --git a/arch/arm/mach-omap2/omap34xx.h b/arch/arm/mach-omap2/omap34xx.h
  index c0d1b4b..ed0024d 100644
  --- a/arch/arm/mach-omap2/omap34xx.h
  +++ b/arch/arm/mach-omap2/omap34xx.h
  @@ -46,39 +46,9 @@
  
   #define OMAP34XX_IC_BASE   0x4820
  
  -#define OMAP3430_ISP_BASE  (L4_34XX_BASE + 0xBC000)
  -#define OMAP3430_ISP_CBUFF_BASE(OMAP3430_ISP_BASE + 0x0100)
  -#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
  -#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
  -#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
  -#define OMAP3430_ISP_H3A_BASE  

Re: [PATCH 11/24] ARM: OMAP2+: clock: remove support for legacy mpurate command line param

[Tony Lindgren]

* Tero Kristo t-kri...@ti.com [150309 05:56]:
 On 03/06/2015 06:25 PM, Tony Lindgren wrote:
 * Tero Kristo t-kri...@ti.com [150306 08:10]:
 On 03/06/2015 05:32 PM, Tony Lindgren wrote:
 * Tero Kristo t-kri...@ti.com [150306 04:29]:
 The legacy support is wrong and dangerous, as it doesn't take any
 OPPs into account and does not scale voltages. Switching mpurate should
 be handled through cpufreq.
 
 Hmm I wonder if some systems actually rely on the mpurate cmdline
 parameter. If this cannot be fixed properly, you should at least
 print an error here.
 
 Yea, I was kind of worried about this comment. We have also an option of
 doing this through clock driver, but I was hesitant of doing this either.
 Isn't having a global kernel option like this frowned upon anyway? I believe
 this piece of init code gets executed on every board on multiarch kernel.
 
 Well the option has been there probably for 10 years already so we
 can't just drop it like that. Chances are it's unused though, so I
 suggest you just print out a warning for it.
 
 It's called from omap_arch_initcall which checks for soc_is_omap()
 so that's not an issue. But when moving the code, you naturally
 need to check the moved code initcall usage.
 
 This patch is not really needed for the set itself btw, it can just be
 dropped if you feel it actually is used by someone. Reverting it from the
 set just causes a minor merge conflict and you can't remove two of the
 otherwise empty clock files.

How about set it up in a way where it can be easily reverted later
on if there is need for that?
 
 You could also just move the code over to clock.c maybe, merge these and do
 a soc type check to reach the same behaviour.

If it's needed yeah.

Regards,

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

Re: [PATCH] dma: cppi41: add missing directions bitfield

[Felipe Balbi]

On Wed, Mar 04, 2015 at 06:13:23PM +0530, Vinod Koul wrote:
 On Wed, Feb 25, 2015 at 04:54:02PM -0600, Felipe Balbi wrote:
  Without those we will see a kernel WARN()
  when loading musb on am335x devices.
  
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
   drivers/dma/cppi41.c | 1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
  index 512cb8e2805e..4e9cc8e8100c 100644
  --- a/drivers/dma/cppi41.c
  +++ b/drivers/dma/cppi41.c
  @@ -926,6 +926,7 @@ static int cppi41_dma_probe(struct platform_device 
  *pdev)
  cdd-ddev.device_issue_pending = cppi41_dma_issue_pending;
  cdd-ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg;
  cdd-ddev.device_terminate_all = cppi41_stop_chan;
  +   cdd-ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
  cdd-ddev.dev = dev;
  INIT_LIST_HEAD(cdd-ddev.channels);
  cpp41_dma_info.dma_cap = cdd-ddev.cap_mask;
 Along with this please set src/dstn_addr_widths and residue_granularity
 please

will do.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions

[Tony Lindgren]

* Alan Stern st...@rowland.harvard.edu [150308 08:41]:
 On Fri, 6 Mar 2015, Tony Lindgren wrote:
 
I'll verify again, but I believe the issue was that without doing
mark_last_busy here the device falls back asleep right away.
 
 As it should.  If you don't increment the usage counter (for example, 
 by calling pm_runtime_get instead of pm_request_resume) and you don't 
 update last_busy then you are telling the PM core that the device 
 currently isn't busy and it hasn't been in use since the last time it 
 was suspended.  Under those circumstances, the PM core is _supposed_ to 
 suspend the device right away.

OK so it's a feature then.
 
That probably should be fixed in pm_runtime in general if that's
the case.
   
   It's up to the subsystem to handle this.  For example, the USB 
   subsystem's runtime-resume routine calls pm_runtime_mark_last_busy.
  
  Hmm.. OK thanks this probably explains why pm_request_resume() did
  not work.
  
  For omaps, I could call this from the interconnect related code,
  but then how dow we deal with the subsystems that don't call it?
 
 Start by determining _why_ they don't call it.  Maybe they have a good 
 reason.  If they don't then fix them.

Yes I'll check, it's just probably because the drivers have been
calling it instead.
 
Considering the above, should we add a new function something like
pm_resume_complete() that does not need irq_safe set but does
not return until the device has completed resume?
   
   That doesn't make sense.  You're asking for a routine that is allowed
   to sleep but can safely be called in interrupt context.
  
  Oh it naturally would not work in irq context, it's for the bottom
  half again.
 
 In other words, you're suggesting we add a function that runs in 
 process context and doesn't return until the device is fully resumed?  
 That's exactly what pm_runtime_resume does right now.

But doesn't it only wait for completion if the driver is marked with
pm_runtime_irq_safe()?
 
   But I'll take a look if we can just call
  pm_request_resume() and disable_irq() on the wakeirq in without
  waiting for the device driver runtime_suspend to disable the wakeirq.
  That would minimize the interface to just dev_pm_request_wakeirq()
  and dev_pm_free_wakeirq().
 
 Will that be acceptable in systems with shared IRQ lines?

Not without us keeping track of when the wakeirq is enabled or
disabled :)

Regards,

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

Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions

[Alan Stern]

On Mon, 9 Mar 2015, Tony Lindgren wrote:

 Considering the above, should we add a new function something like
 pm_resume_complete() that does not need irq_safe set but does
 not return until the device has completed resume?

That doesn't make sense.  You're asking for a routine that is allowed
to sleep but can safely be called in interrupt context.
   
   Oh it naturally would not work in irq context, it's for the bottom
   half again.
  
  In other words, you're suggesting we add a function that runs in 
  process context and doesn't return until the device is fully resumed?  
  That's exactly what pm_runtime_resume does right now.
 
 But doesn't it only wait for completion if the driver is marked with
 pm_runtime_irq_safe()?

Put it this way: pm_runtime_resume invokes a -runtime_resume
callback routine (the subsystem's or the driver's or whichever), and it
assumes that if the routine returns 0 then the device has been resumed.  
It doesn't really _wait_ for anything; it just calls the callback
routine.

It behaves this way whether or not the irq_safe flag is set.  The only
difference is that if irq_safe is set then the callback routine is
invoked with interrupts disabled (and in this case pm_runtime_resume
may be called in interrupt context -- normally it can be called only in
process context).

Alan Stern

--
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 10/18] omap3isp: Move the syscon register out of the ISP register maps

[Tony Lindgren]

* Sakari Ailus sakari.ai...@iki.fi [150307 15:44]:
 Hi Laurent,
 
 On Sun, Mar 08, 2015 at 01:34:17AM +0200, Laurent Pinchart wrote:
  Hi Sakari,
  
  Thank you for the patch.
  
  (CC'ing linux-omap and Tony)
 
 Thanks.
 
  On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
   The syscon register isn't part of the ISP, use it through the syscom 
   driver
   regmap instead. The syscom block is considered to be from 343x on ISP
   revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
   
   Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
   ---
arch/arm/boot/dts/omap3.dtsi|2 +-
arch/arm/mach-omap2/devices.c   |   10 --
drivers/media/platform/omap3isp/isp.c   |   19 +++
drivers/media/platform/omap3isp/isp.h   |   19 +--
drivers/media/platform/omap3isp/ispcsiphy.c |   20 +---
  
  You might be asked to split the patch into two, let's see what Tony says.
  
5 files changed, 42 insertions(+), 28 deletions(-)
   
   diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
   index 01b7111..fe0b293 100644
   --- a/arch/arm/boot/dts/omap3.dtsi
   +++ b/arch/arm/boot/dts/omap3.dtsi
   @@ -183,7 +183,7 @@
   
 omap3_scm_general: tisyscon@48002270 {
 compatible = syscon;
   - reg = 0x48002270 0x2f0;
   + reg = 0x48002270 0x2f4;
 };
   
 pbias_regulator: pbias_regulator {

Can you please send the above dts change separately as a fix describing
what goes wrong? Let's get that out of the way for the -rc, otherwise
we're going to probably get conflicts with Tero's dts changes.

   diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
   index 1afb50d..e945957 100644
   --- a/arch/arm/mach-omap2/devices.c
   +++ b/arch/arm/mach-omap2/devices.c
   @@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
 .flags  = IORESOURCE_MEM,
 },
 {
   - .start  = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
   - .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE 
   + 3,
   - .flags  = IORESOURCE_MEM,
   - },
   - {
   - .start  = OMAP343X_CTRL_BASE + 
   OMAP3630_CONTROL_CAMERA_PHY_CTRL,
   - .end= OMAP343X_CTRL_BASE + 
   OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
   - .flags  = IORESOURCE_MEM,
   - },
   - {
 .start  = 24 + OMAP_INTC_START,
 .flags  = IORESOURCE_IRQ,
 }

Looks good to me, teel free to merge this part along with the other
isp changes:

Acked-by: Tony Lindgren t...@atomide.com


   diff --git a/drivers/media/platform/omap3isp/isp.c
   b/drivers/media/platform/omap3isp/isp.c index 68d7edfc..4ff4bbd 100644
   --- a/drivers/media/platform/omap3isp/isp.c
   +++ b/drivers/media/platform/omap3isp/isp.c
   @@ -51,6 +51,7 @@
#include linux/dma-mapping.h
#include linux/i2c.h
#include linux/interrupt.h
   +#include linux/mfd/syscon.h
#include linux/module.h
#include linux/omap-iommu.h
#include linux/platform_device.h
   @@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1  OMAP3_ISP_IOMEM_RESZ |
1  OMAP3_ISP_IOMEM_SBL |
1  OMAP3_ISP_IOMEM_CSI2A_REGS1 |
   -1  OMAP3_ISP_IOMEM_CSIPHY2 |
   -1  OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
   +1  OMAP3_ISP_IOMEM_CSIPHY2,
   + .syscon_offset = 0xdc,
   + .phy_type = ISP_PHY_TYPE_3430,
 },
 {
 .isp_rev = ISP_REVISION_15_0,
   @@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1  OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1  OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1  OMAP3_ISP_IOMEM_CSIPHY1 |
   -1  OMAP3_ISP_IOMEM_CSI2C_REGS2 |
   -1  OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
   +1  OMAP3_ISP_IOMEM_CSI2C_REGS2,
   + .syscon_offset = 0x2f0,
   + .phy_type = ISP_PHY_TYPE_3630,
 },
};
   
   @@ -2352,6 +2355,14 @@ static int isp_probe(struct platform_device *pdev)
 }
 }
   
   + isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0);
   + isp-syscon_offset = isp_res_maps[m].syscon_offset;
   + isp-phy_type = isp_res_maps[m].phy_type;
  
  You could move those two lines after the error check to keep the check 
  closer 
  to the source of error.
 
 Ack.
 
  Apart from that,
  
  Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 
 Thanks for the acks!
 
 -- 
 Kind regards,
 
 Sakari Ailus
 e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk
--
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  

[PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

Add wl18xx (wilink8) bindings to omap3-igep0030-rev-g and
omap3-igep0020-rev-f dts files, instead of defining the
platform data through the pdata-quirks.

The patch was compile-tested only.

Signed-off-by: Eliad Peller el...@wizery.com
---
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 +
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 +
 arch/arm/mach-omap2/pdata-quirks.c | 2 --
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts 
b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index cc8bd0c..8e5b44e 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -42,4 +42,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio6;
+   interrupts = 17 IRQ_TYPE_NONE;
+   };
 };
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts 
b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 9326b28..02c4eec 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -64,4 +64,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 8 IRQ_TYPE_NONE;
+   };
 };
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..abc8a20 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -159,14 +159,12 @@ static struct platform_device btwilink_device = {
 
 static void __init omap3_igep0020_rev_f_legacy_init(void)
 {
-   legacy_init_wl12xx(0, 0, 177);
platform_device_register(wl18xx_device);
platform_device_register(btwilink_device);
 }
 
 static void __init omap3_igep0030_rev_g_legacy_init(void)
 {
-   legacy_init_wl12xx(0, 0, 136);
platform_device_register(wl18xx_device);
platform_device_register(btwilink_device);
 }
-- 
1.8.5.2.229.g4448466.dirty

--
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] gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq

[Linus Walleij]

On Fri, Mar 6, 2015 at 8:26 PM,  grygorii.stras...@linaro.org wrote:

 From: Grygorii Strashko grygorii.stras...@linaro.org

 GPIOLib core implemnts irqchip-irq_request/release_resources callbacks
 internally and these callbacks already contain clalls of
 gpiochip_lock/unlock_as_irq().

 Hence, remove unnecessary call of gpiochip_unlock_as_irq() from
 omap_gpio_irq_shutdown().

 Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org

Looks like a simple oversight. Patch applied.

Yours,
Linus Walleij
--
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] i2c: omap: implement bus recovery

[Felipe Balbi]

On Thu, Feb 19, 2015 at 12:06:49PM -0600, Felipe Balbi wrote:
 If either SCL or SDA are stuck low, we need to
 recover the bus using the procedure described
 on section 3.1.16 of the I2C specification.
 
 Note that we're trying to implement the procedure
 exactly as described by that section. First we
 check which line is stuck low, then implement
 one or the other procedure. If SDA recovery procedure
 fails, we reset our IP in an attempt to make it work.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 Tested with AM437x IDK, AM437x SK, BeagleBoneBlack and Beagle X15 with
 1000 iterations of i2cdetect on all available buses.
 
 That said, I couldn't get any device to hold the bus busy so I could
 see this working. If anybody has any good way of forcing a condition
 so that we need bus recovery, I'd be glad to look at.

ping

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] PM / Wakeirq: Add minimal device wakeirq helper functions

[Tony Lindgren]

* Alan Stern st...@rowland.harvard.edu [150309 08:42]:
 On Mon, 9 Mar 2015, Tony Lindgren wrote:
 
  Considering the above, should we add a new function something like
  pm_resume_complete() that does not need irq_safe set but does
  not return until the device has completed resume?
 
 That doesn't make sense.  You're asking for a routine that is allowed
 to sleep but can safely be called in interrupt context.

Oh it naturally would not work in irq context, it's for the bottom
half again.
   
   In other words, you're suggesting we add a function that runs in 
   process context and doesn't return until the device is fully resumed?  
   That's exactly what pm_runtime_resume does right now.
  
  But doesn't it only wait for completion if the driver is marked with
  pm_runtime_irq_safe()?
 
 Put it this way: pm_runtime_resume invokes a -runtime_resume
 callback routine (the subsystem's or the driver's or whichever), and it
 assumes that if the routine returns 0 then the device has been resumed.  
 It doesn't really _wait_ for anything; it just calls the callback
 routine.
 
 It behaves this way whether or not the irq_safe flag is set.  The only
 difference is that if irq_safe is set then the callback routine is
 invoked with interrupts disabled (and in this case pm_runtime_resume
 may be called in interrupt context -- normally it can be called only in
 process context).

Oh right you are. Looking at rpm_resume() again, it's the RPM_ASYNC that
was causing problems to me earlier, not the irq_safe. Sorry it seems I
was a bit confused. And yes, pm_runtime_resume() does not set RPM_ASYNC
like you pointed out earlier so no need to do anything there.

Regards,

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

[PATCH] mfd: menelaus: rmove incorrect __exit markups

[Dmitry Torokhov]

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
---
 drivers/mfd/menelaus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9f01aef..5269ff2 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1259,7 +1259,7 @@ fail:
return err;
 }
 
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
 {
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
 
@@ -1280,7 +1280,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name   = DRIVER_NAME,
},
.probe  = menelaus_probe,
-   .remove = __exit_p(menelaus_remove),
+   .remove = menelaus_remove,
.id_table   = menelaus_id,
 };
 
-- 
2.2.0.rc0.207.ga3a616c


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

Re: [PATCH] mfd: menelaus: rmove incorrect __exit markups

[Tony Lindgren]

* Dmitry Torokhov dmitry.torok...@gmail.com [150309 10:49]:
 Even if bus is not hot-pluggable, the devices can be unbound from the
 driver via sysfs, so we should not be using __exit annotations on
 remove() methods. The only exception is drivers registered with
 platform_driver_probe() which specifically disables sysfs bind/unbind
 attributes.
 
 Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com

Acked-by: Tony Lindgren t...@atomide.com

 ---
  drivers/mfd/menelaus.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
 index 9f01aef..5269ff2 100644
 --- a/drivers/mfd/menelaus.c
 +++ b/drivers/mfd/menelaus.c
 @@ -1259,7 +1259,7 @@ fail:
   return err;
  }
  
 -static int __exit menelaus_remove(struct i2c_client *client)
 +static int menelaus_remove(struct i2c_client *client)
  {
   struct menelaus_chip*menelaus = i2c_get_clientdata(client);
  
 @@ -1280,7 +1280,7 @@ static struct i2c_driver menelaus_i2c_driver = {
   .name   = DRIVER_NAME,
   },
   .probe  = menelaus_probe,
 - .remove = __exit_p(menelaus_remove),
 + .remove = menelaus_remove,
   .id_table   = menelaus_id,
  };
  
 -- 
 2.2.0.rc0.207.ga3a616c
 
 
 -- 
 Dmitry
--
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] phy: Add a driver for dm816x USB PHY

[Tony Lindgren]

* Bin Liu binml...@gmail.com [150309 14:35]:
 On Mon, Mar 9, 2015 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
  * Felipe Balbi ba...@ti.com [150309 14:21]:
  On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
   On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
Hi,
   
On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com 
wrote:
 Add a minimal driver for dm816x USB. Otherwise we can just use
 the existing musb_am335x and musb_dsps on dm816x.
   
dm816x has the almost identical usbss as that in am335x, we should be
able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
   
Tony's using the same musb glue layers, this is just a phy driver,
right ?
  
   Can the current am335x phy driver be adopted too? I remember it is
   under drivers/usb/phy/.
 
  Tony will be best to answer, but according to our IRC discussions, it's
  too different. Tony ?
 
  Well we should check again between dm814x and am335x documentation
  against the $subject driver as the dm816x docs were buggy and I may
  have gotten a wrong idea initially.
 
 Will it make our life a little easier by comparing the usb drivers for
 dm81xx and am335x in previous TI kernel releases? I cam dig out the
 source code if that helps.

Yeah that probably helps if you've dealt with dm814x earlier :)
Just don't look at the dm816x trm, only the errata pdf works for
dm816x phy.

Note that we still are missing basic support for dm814x in mainline,
I'm planning to tackle that at some point but I don't know when I'm
going to get to it..

Regards,

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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Bin Liu]

Hi,

On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
 Add a minimal driver for dm816x USB. Otherwise we can just use
 the existing musb_am335x and musb_dsps on dm816x.

dm816x has the almost identical usbss as that in am335x, we should be
able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

Regards,
-Bin.


 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

 --- /dev/null
 +++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
 @@ -0,0 +1,24 @@
 +Device tree binding documentation for am816x USB PHY
 +=
 +
 +Required properties:
 +- compatible : should be ti,dm816x-usb-phy
 +- reg : offset and length of the PHY register set.
 +- reg-names : name for the phy registers
 +- clocks : phandle to the clock
 +- clock-names : name of the clock
 +- syscon: phandle for the syscon node to access misc registers
 +- #phy-cells : from the generic PHY bindings, must be 1
 +- syscon: phandle for the syscon node to access misc registers
 +
 +Example:
 +
 +usb_phy0: usb-phy@20 {
 +   compatible = ti,dm8168-usb-phy;
 +   reg = 0x20 0x8;
 +   reg-names = phy;
 +   clocks = main_fapll 6;
 +   clock-names = refclk;
 +   #phy-cells = 0;
 +   syscon = scm_conf;
 +};
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
 depends on OF
 select GENERIC_PHY

 +config PHY_DM816X_USB
 +   tristate TI dm816x USB PHY driver
 +   depends on ARCH_OMAP2PLUS
 +   select GENERIC_PHY
 +   help
 + Enable this for dm81xx USB to work.
 +
  config PHY_EXYNOS_MIPI_VIDEO
 tristate S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver
 depends on HAS_IOMEM
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -5,6 +5,7 @@
  obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
  obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
  obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
 +obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
  obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
  obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 --- /dev/null
 +++ b/drivers/phy/phy-dm816x-usb.c
 @@ -0,0 +1,295 @@
 +/*
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/regmap.h
 +
 +#include linux/slab.h
 +#include linux/of.h
 +#include linux/io.h
 +#include linux/usb/phy_companion.h
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/pm_runtime.h
 +#include linux/delay.h
 +#include linux/phy/phy.h
 +#include linux/of_platform.h
 +
 +#include linux/mfd/syscon.h
 +
 +/*
 + * TRM has two sets of USB_CTRL registers.. The correct register bits
 + * are in TRM section 24.9.8.2 USB_CTRL Register.
 + */
 +#define DM816X_USB_CTRL_PHYCLKSRC  BIT(8)  /* 1 = PLL ref clock */
 +#define DM816X_USB_CTRL_PHYSLEEP1  BIT(1)
 +#define DM816X_USB_CTRL_PHYSLEEP0  BIT(0)
 +
 +#define DM816X_USBPHY_CTRL_TXRISETUNE  1
 +#define DM816X_USBPHY_CTRL_TXVREFTUNE  0xc
 +#define DM816X_USBPHY_CTRL_TXPREEMTUNE 0x2
 +
 +struct dm816x_usb_phy {
 +   struct regmap *syscon;
 +   struct device *dev;
 +   unsigned int instance;
 +   struct clk *refclk;
 +   struct usb_phy phy;
 +   unsigned int usb_ctrl;  /* Shared between phy0 and phy1 */
 +   unsigned int usbphy_ctrl;
 +};
 +
 +static int dm816x_usb_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
 +{
 +   otg-host = host;
 +   if (!host)
 +   otg-state = OTG_STATE_UNDEFINED;
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_set_peripheral(struct usb_otg *otg,
 +struct usb_gadget *gadget)
 +{
 +   otg-gadget = gadget;
 +   if (!gadget)
 +   otg-state = OTG_STATE_UNDEFINED;
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_power_off(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +
 +   pm_runtime_put(phy-dev);
 +
 +   return 0;
 +}
 +
 +static int dm816x_usb_phy_power_on(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +
 +   return pm_runtime_get_sync(phy-dev);
 +}
 +
 +static int dm816x_usb_phy_init(struct phy *x)
 +{
 +   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
 +   

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [150309 14:21]:
 On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
  On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
   On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
   Hi,
  
   On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.
  
   dm816x has the almost identical usbss as that in am335x, we should be
   able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
  
   Tony's using the same musb glue layers, this is just a phy driver,
   right ?
  
  Can the current am335x phy driver be adopted too? I remember it is
  under drivers/usb/phy/.
 
 Tony will be best to answer, but according to our IRC discussions, it's
 too different. Tony ?

Well we should check again between dm814x and am335x documentation
against the $subject driver as the dm816x docs were buggy and I may
have gotten a wrong idea initially. 

Regards,

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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Bin Liu]

On Mon, Mar 9, 2015 at 4:20 PM, Tony Lindgren t...@atomide.com wrote:
 * Bin Liu binml...@gmail.com [150309 14:17]:
 On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
  On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
  Hi,
 
  On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
   Add a minimal driver for dm816x USB. Otherwise we can just use
   the existing musb_am335x and musb_dsps on dm816x.
 
  dm816x has the almost identical usbss as that in am335x, we should be
  able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
 
  Tony's using the same musb glue layers, this is just a phy driver,
  right ?

 Can the current am335x phy driver be adopted too? I remember it is
 under drivers/usb/phy/.

 Yes this is just the phy, other than that things work the same.

 I believe this is different from the am335x phy, and more similar to
 what we have in old drivers/usb/musb/davinci.c. Chances are dm814x
 is same as am335x phy.

Alright, I only played the dm814x board a few times, but never with
dm816x, and thought dm816x and dm814x usbss are the same and very
close to am335x - am335x came out later than dm81xx and has some
improvement in usbss.


 But yeah, we really should do a proper phy driver for am335x too
 along the same lines. Might even be be able to combine those drivers
 with just different compatible values to set the quirks and the
 enable/disable functions.

Ok, I agreed we can make dm816x working first, then gradually move
am335x aligned to the framework.

Regards,
-Bin.


 Regards,

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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Felipe Balbi]

On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
 On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
  On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
  Hi,
 
  On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
   Add a minimal driver for dm816x USB. Otherwise we can just use
   the existing musb_am335x and musb_dsps on dm816x.
 
  dm816x has the almost identical usbss as that in am335x, we should be
  able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
 
  Tony's using the same musb glue layers, this is just a phy driver,
  right ?
 
 Can the current am335x phy driver be adopted too? I remember it is
 under drivers/usb/phy/.

Tony will be best to answer, but according to our IRC discussions, it's
too different. Tony ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync

[Pavel Machek]

On Sun 2015-03-08 11:01:01, Pali Rohár wrote:
 Function pm_runtime_get_sync could fail and we need to check return
 value to prevent kernel crash.
 
 Signed-off-by: Pali Rohár pali.ro...@gmail.com

Acked-by: Pavel Machek pa...@ucw.cz

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
 --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 @@ -64,4 +64,13 @@
 vmmc-supply = lbep5clwmc_wlen;
 bus-width = 4;
 non-removable;
 +
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   wlcore: wlcore@2 {
 +   compatible = ti,wl1835;
 +   reg = 2;
 +   interrupt-parent = gpio5;
 +   interrupts = 8 IRQ_TYPE_NONE;
 +   };


 Why IRQ_TYPE_NONE?

i simply mirrored the current board file (which only sets the irq number).

 I was expecting you to remove all calls to legacy_init_wl12xx from this file,
 including the ones for wl12xx aside from the wl18xx ones you removed, but
 if that's enough to clean out the platform_data handling from the wlcore
 driver, it's good enough as a start.
not sure i'm following - can you elaborate?

i'll summarize the way i see it. please correct me if i'm wrong.

both wl18xx and wl12xx use the platform data to get the irq number.
wl12xx (only) also needs some additional clock definitions to be
passed. there's currently some issue with specifying some the of clock
sources, so i preferred starting only with (the simpler) wl18xx
bindings.

for platforms with wl18xx, we can remove the pdata-quirk, as all the
data (i.e. irq) can be passed by the new DT bindings.
however, for platforms with wl12xx, we still need to pass the clock
definitions (along with the irq), so we have to keep
legacy_init_wl12xx for the time being (and that's also why we have to
currently keep the platform_data handling in the wlcore driver)

do you have something else in mind?

Eliad.
--
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] phy: Add a driver for dm816x USB PHY

[Bin Liu]

On Mon, Mar 9, 2015 at 4:26 PM, Tony Lindgren t...@atomide.com wrote:
 * Felipe Balbi ba...@ti.com [150309 14:21]:
 On Mon, Mar 09, 2015 at 04:17:29PM -0500, Bin Liu wrote:
  On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
   On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
   Hi,
  
   On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.
  
   dm816x has the almost identical usbss as that in am335x, we should be
   able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
  
   Tony's using the same musb glue layers, this is just a phy driver,
   right ?
 
  Can the current am335x phy driver be adopted too? I remember it is
  under drivers/usb/phy/.

 Tony will be best to answer, but according to our IRC discussions, it's
 too different. Tony ?

 Well we should check again between dm814x and am335x documentation
 against the $subject driver as the dm816x docs were buggy and I may
 have gotten a wrong idea initially.

Will it make our life a little easier by comparing the usb drivers for
dm81xx and am335x in previous TI kernel releases? I cam dig out the
source code if that helps.

Regards,
-Bin,


 Regards,

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

Re: ARM: OMPA4+: is it expected dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); to fail?

[Arnd Bergmann]

On Thursday 05 March 2015 20:55:07 grygorii.stras...@linaro.org wrote:
 Hi All,
 
 Now I can see very interesting behavior related to 
 dma_coerce_mask_and_coherent()
 and friends which I'd like to explain and clarify.
 
 Below is set of questions I have (why - I explained below):
 - Is expected dma_coerce_mask_and_coherent(DMA_BIT_MASK(64)) and friends to 
 fail on 32 bits HW?

No. dma_coerce_mask_and_coherent() is meant to ignore the actual mask. It's
usually considered a bug to use this function for that reason.

 - What is expected value for max_pfn: max_phys_pfn or max_phys_pfn + 1?
 
 - What is expected value for struct memblock_region-size: mem_range_size or 
 mem_range_size - 1?
 
 - What is expected value to be returned by memblock_end_of_DRAM():
   @base + @size(max_phys_addr + 1) or @base + @size - 1(max_phys_addr)?
 
 
 I'm working with BeaglBoard-X15 (AM572x/DRA7xx) board and have following code 
 in OMAP ASOC driver
 which is failed SOMETIMES during the boot with error -EIO.
 === to omap-pcm.c:
 omap_pcm_new() {
 ...
   ret = dma_coerce_mask_and_coherent(card-dev, DMA_BIT_MASK(64));
 ^^ failed sometimes
   if (ret)
   return ret;
 }

The code should be fixed to use dma_set_mask_and_coherent(), which is expected 
to
fail if the bus is incapable of addressing all RAM within the mask.

 I'd be very appreciated for any comments/clarification on questions I've 
 listed at the
 beginning of my e-mail - there are no patches from my side as I'd like to 
 understand 
 expected behavior of the kernel first (especially taking into account that any
 memblock changes might affect on at least half of arches). 

Is the device you have actually 64-bit capable?

Is the bus it is connected to 64-bit wide?

Does the dma-ranges property of the parent bus reflect the correct address 
width?

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

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Bin Liu]

On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
 Hi,

 On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
  Add a minimal driver for dm816x USB. Otherwise we can just use
  the existing musb_am335x and musb_dsps on dm816x.

 dm816x has the almost identical usbss as that in am335x, we should be
 able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

 Tony's using the same musb glue layers, this is just a phy driver,
 right ?

Can the current am335x phy driver be adopted too? I remember it is
under drivers/usb/phy/.

Regards,
-Bin.


 --
 balbi
--
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] phy: Add a driver for dm816x USB PHY

[Tony Lindgren]

* Bin Liu binml...@gmail.com [150309 14:17]:
 On Mon, Mar 9, 2015 at 4:13 PM, Felipe Balbi ba...@ti.com wrote:
  On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
  Hi,
 
  On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
   Add a minimal driver for dm816x USB. Otherwise we can just use
   the existing musb_am335x and musb_dsps on dm816x.
 
  dm816x has the almost identical usbss as that in am335x, we should be
  able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?
 
  Tony's using the same musb glue layers, this is just a phy driver,
  right ?
 
 Can the current am335x phy driver be adopted too? I remember it is
 under drivers/usb/phy/.

Yes this is just the phy, other than that things work the same.

I believe this is different from the am335x phy, and more similar to
what we have in old drivers/usb/musb/davinci.c. Chances are dm814x
is same as am335x phy.

But yeah, we really should do a proper phy driver for am335x too
along the same lines. Might even be be able to combine those drivers
with just different compatible values to set the quirks and the
enable/disable functions.

Regards,

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

[PATCH] phy: Add a driver for dm816x USB PHY

[Tony Lindgren]

Add a minimal driver for dm816x USB. Otherwise we can just use
the existing musb_am335x and musb_dsps on dm816x.

Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
@@ -0,0 +1,24 @@
+Device tree binding documentation for am816x USB PHY
+=
+
+Required properties:
+- compatible : should be ti,dm816x-usb-phy
+- reg : offset and length of the PHY register set.
+- reg-names : name for the phy registers
+- clocks : phandle to the clock
+- clock-names : name of the clock
+- syscon: phandle for the syscon node to access misc registers
+- #phy-cells : from the generic PHY bindings, must be 1
+- syscon: phandle for the syscon node to access misc registers
+
+Example:
+
+usb_phy0: usb-phy@20 {
+   compatible = ti,dm8168-usb-phy;
+   reg = 0x20 0x8;
+   reg-names = phy;
+   clocks = main_fapll 6;
+   clock-names = refclk;
+   #phy-cells = 0;
+   syscon = scm_conf;
+};
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF
select GENERIC_PHY
 
+config PHY_DM816X_USB
+   tristate TI dm816x USB PHY driver
+   depends on ARCH_OMAP2PLUS
+   select GENERIC_PHY
+   help
+ Enable this for dm81xx USB to work.
+
 config PHY_EXYNOS_MIPI_VIDEO
tristate S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver
depends on HAS_IOMEM
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
--- /dev/null
+++ b/drivers/phy/phy-dm816x-usb.c
@@ -0,0 +1,295 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/phy/phy.h
+#include linux/of_platform.h
+
+#include linux/mfd/syscon.h
+
+/*
+ * TRM has two sets of USB_CTRL registers.. The correct register bits
+ * are in TRM section 24.9.8.2 USB_CTRL Register.
+ */
+#define DM816X_USB_CTRL_PHYCLKSRC  BIT(8)  /* 1 = PLL ref clock */
+#define DM816X_USB_CTRL_PHYSLEEP1  BIT(1)
+#define DM816X_USB_CTRL_PHYSLEEP0  BIT(0)
+
+#define DM816X_USBPHY_CTRL_TXRISETUNE  1
+#define DM816X_USBPHY_CTRL_TXVREFTUNE  0xc
+#define DM816X_USBPHY_CTRL_TXPREEMTUNE 0x2
+
+struct dm816x_usb_phy {
+   struct regmap *syscon;
+   struct device *dev;
+   unsigned int instance;
+   struct clk *refclk;
+   struct usb_phy phy;
+   unsigned int usb_ctrl;  /* Shared between phy0 and phy1 */
+   unsigned int usbphy_ctrl;
+};
+
+static int dm816x_usb_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+   otg-host = host;
+   if (!host)
+   otg-state = OTG_STATE_UNDEFINED;
+
+   return 0;
+}
+
+static int dm816x_usb_phy_set_peripheral(struct usb_otg *otg,
+struct usb_gadget *gadget)
+{
+   otg-gadget = gadget;
+   if (!gadget)
+   otg-state = OTG_STATE_UNDEFINED;
+
+   return 0;
+}
+
+static int dm816x_usb_phy_power_off(struct phy *x)
+{
+   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+
+   pm_runtime_put(phy-dev);
+
+   return 0;
+}
+
+static int dm816x_usb_phy_power_on(struct phy *x)
+{
+   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+
+   return pm_runtime_get_sync(phy-dev);
+}
+
+static int dm816x_usb_phy_init(struct phy *x)
+{
+   struct dm816x_usb_phy *phy = phy_get_drvdata(x);
+   unsigned int val;
+   int error;
+
+   error = pm_runtime_get_sync(phy-dev);
+   if (error)
+   return error;
+
+   if (clk_get_rate(phy-refclk) != 2400)
+   dev_warn(phy-dev, nonstandard phy refclk\n);
+
+   /* Set PLL ref clock and put phys to sleep */
+   error = regmap_update_bits(phy-syscon, phy-usb_ctrl,
+

Re: [PATCH] phy: Add a driver for dm816x USB PHY

[Felipe Balbi]

On Mon, Mar 09, 2015 at 04:11:28PM -0500, Bin Liu wrote:
 Hi,
 
 On Mon, Mar 9, 2015 at 3:51 PM, Tony Lindgren t...@atomide.com wrote:
  Add a minimal driver for dm816x USB. Otherwise we can just use
  the existing musb_am335x and musb_dsps on dm816x.
 
 dm816x has the almost identical usbss as that in am335x, we should be
 able to adopt musb_am335x and musb_dsps for dm816x, and dm814x too?

Tony's using the same musb glue layers, this is just a phy driver,
right ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v5 2/3] wl18xx: add basic device-tree support

[Arnd Bergmann]

On Monday 09 March 2015 17:36:41 Eliad Peller wrote:
 @@ -323,11 +388,14 @@ out:
  static void wl1271_remove(struct sdio_func *func)
  {
 struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
 +   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
 +   struct wl12xx_platform_data *pdata = pdev_data-pdata;
  
 /* Undo decrement done above in wl1271_probe */
 pm_runtime_get_noresume(func-dev);
  
 platform_device_unregister(glue-core);
 +   wlcore_del_platform_data(pdata);
 kfree(glue);
  }
  
 

The third patch looks ok, but now you should remove the wl12xx_platform_data
from the wlcore code, since it's not used any more, it was broken to start
with (as it supports only one instance) and we want to prevent others from
adding new users of that. Since the only thing you need is the irq number,
you can directly add the irq number to struct wlcore_platdev_data and
remove the pdata pointer there.

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

OMAP baseline test results for v4.0-rc3

[Paul Walmsley]

Here are some basic OMAP test results for Linux v4.0-rc3.
Logs and other details at:

http://www.pwsan.com/omap/testlogs/test_v4.0-rc3/20150308193049/


Test summary


Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
  omap1_defconfig_5912osk_only

Build: uImage+dtb:
Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
  omap2plus_defconfig/omap4-panda,
  omap2plus_defconfig/omap4-panda-es,
  omap2plus_defconfig/omap4-var-som,
  omap2plus_defconfig/omap3-evm-37xx,
  omap2plus_defconfig_n800_only_a/omap2420-n800,
  omap2plus_defconfig/omap2430-sdp,
  omap2plus_defconfig/am3517-evm,
  omap2plus_defconfig/omap3-beagle,
  omap2plus_defconfig/omap3-beagle-xm,
  omap2plus_defconfig/omap3-sbc-t3517,
  omap2plus_defconfig/omap5-uevm,
  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_n800_only_a,
  omap2plus_defconfig_n800_multi_omap2xxx,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only,
  rmk_omap3430_ldp_oldconfig,
  rmk_omap3430_ldp_allnoconfig,
  rmk_omap4430_sdp_oldconfig,
  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
  omap1_defconfig_5912osk_only

Build warnings from toolchain: uImage+dtb:
(none)

Build warnings from toolchain: zImage:
FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
  omap2plus_defconfig_n800_only_a,
  omap2plus_defconfig_n800_multi_omap2xxx,
  omap2plus_defconfig_2430sdp_only,
  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
  omap2plus_defconfig_omap2_4_only,
  omap2plus_defconfig_omap3_4_only,
  omap2plus_defconfig_omap5_only,
  omap2plus_defconfig_dra7xx_only,
  omap2plus_defconfig_am43xx_only,
  rmk_omap3430_ldp_oldconfig,
  rmk_omap4430_sdp_oldconfig, multi_v7_defconfig

Boot to userspace:
FAIL ( 1/17): 2430sdp
skip ( 2/17): 5912osk, 3517evm
Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes,
  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm,
  5430es2sbct54, 2420n800

Kernel warnings during boot to userspace:
FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517

PM: chip retention via suspend:
FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp,
  5430es2uevm, 5430es2sbct54
Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm

PM: chip retention via dynamic idle:
FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp,
  5430es2uevm, 5430es2sbct54
Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle,
  3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle,
  3730es12beaglexm

PM: chip off via dynamic idle:
Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle,
  3730es12beaglexm

Kernel warnings during PM test:
FAIL ( 2/17): 4430es2panda, 4460varsomom

Obsolete Kconfig symbols:
FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.0-rc2 (13a7a6ac0a11197edcd0f756a035f472b42cdf8b)):
   text data  bsstotal  kernel
  +1521  +24  +64+1609  omap1_defconfig
  +1489  +16  +64+1569  omap1_defconfig_1510innovator_only
  +1521  +24  +64+1609  omap1_defconfig_5912osk_only
  +7910  -80  +64+7894  multi_v7_defconfig
  +1650   -8  +64+1706  omap2plus_defconfig
  +1546   -8  +64+1602  omap2plus_defconfig_2430sdp_only
  +1642  +32  +64+1738  omap2plus_defconfig_am33xx_only
  +1642  +24  +64+1730  omap2plus_defconfig_am43xx_only
  +1650   -8  +64+1706  

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Arnd Bergmann]

On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
 --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 @@ -64,4 +64,13 @@
 vmmc-supply = lbep5clwmc_wlen;
 bus-width = 4;
 non-removable;
 +
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   wlcore: wlcore@2 {
 +   compatible = ti,wl1835;
 +   reg = 2;
 +   interrupt-parent = gpio5;
 +   interrupts = 8 IRQ_TYPE_NONE;
 +   };
 

Why IRQ_TYPE_NONE?

I was expecting you to remove all calls to legacy_init_wl12xx from this file,
including the ones for wl12xx aside from the wl18xx ones you removed, but
if that's enough to clean out the platform_data handling from the wlcore
driver, it's good enough as a start.

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

Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges

[Suman Anna]

Tony,

On 03/05/2015 10:57 AM, Tony Lindgren wrote:
 * Suman Anna s-a...@ti.com [150305 08:47]:
 On 03/05/2015 09:40 AM, Tony Lindgren wrote:
 * Dave Gerlach d-gerl...@ti.com [150304 20:14]:
 Dave,

 Looks like the commit message disappeared during your patch preparation.

 Signed-off-by: Suman Anna s-a...@ti.com
 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index acd3705..086415c 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -77,10 +77,23 @@
 */
soc {
compatible = ti,omap-infra;
 +  #address-cells = 1;
 +  #size-cells = 1;
 +  ranges = 0x0 0x44d0 0x4000,
 +   0x8 0x44d8 0x2000;
 +

 I think putting the ranges here will cause issues for adding
 ranges for anything else.

 How about do something like this instead (untested):

 ocp {
 l4_wkup: l4_wkup@44c0 {
 compatible = am335-l4-wkup, simple-bus;
 ranges = 0 0x44c0 0x3f;

 wkup_m3: wkup_m3@44d0 {
 compatible = ti,am3353-wkup-m3;
 reg = 0x100 0x4000,   /* M3 UMEM */
   0x18  0x2000;   /* M3 DMEM */
 ti,hwmods = wkup_m3;
 ti,pm-firmware = am335x-pm-firmware.elf;
 };

 ...
 };
 };

 That way we can start moving also the other l4_wkup components there
 eventuallly without having to redo the ranges again for wkup_m3.

 You can also look at how the scm_conf was done for dm816x.dtsi for an
 example, and the recent large set of patches posted by Tero.

I have taken a look at both the above. The L4_WKUP range includes the
PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0
etc. What all do we want to move here eventually? Depending on that, we
may have to use 2 address cells like in Tero's PRCM cleanup series
rather than the single cell translation used by you in dm816x.dtsi so
that we can retain the relative addresses w.r.t the existing node bases
in the derivative child nodes.

regards
Suman
--
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 v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Tony Lindgren]

* Eliad Peller el...@wizery.com [150309 14:03]:
 On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
  On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
  --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
  +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
  @@ -64,4 +64,13 @@
  vmmc-supply = lbep5clwmc_wlen;
  bus-width = 4;
  non-removable;
  +
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   wlcore: wlcore@2 {
  +   compatible = ti,wl1835;
  +   reg = 2;
  +   interrupt-parent = gpio5;
  +   interrupts = 8 IRQ_TYPE_NONE;
  +   };
 
 
  Why IRQ_TYPE_NONE?
 
 i simply mirrored the current board file (which only sets the irq number).
 
  I was expecting you to remove all calls to legacy_init_wl12xx from this 
  file,
  including the ones for wl12xx aside from the wl18xx ones you removed, but
  if that's enough to clean out the platform_data handling from the wlcore
  driver, it's good enough as a start.
 not sure i'm following - can you elaborate?
 
 i'll summarize the way i see it. please correct me if i'm wrong.
 
 both wl18xx and wl12xx use the platform data to get the irq number.
 wl12xx (only) also needs some additional clock definitions to be
 passed. there's currently some issue with specifying some the of clock
 sources, so i preferred starting only with (the simpler) wl18xx
 bindings.
 
 for platforms with wl18xx, we can remove the pdata-quirk, as all the
 data (i.e. irq) can be passed by the new DT bindings.
 however, for platforms with wl12xx, we still need to pass the clock
 definitions (along with the irq), so we have to keep
 legacy_init_wl12xx for the time being (and that's also why we have to
 currently keep the platform_data handling in the wlcore driver)
 
 do you have something else in mind?

I think what Arnd is saying is we've now removed all the wl12xx using
legacy platforms, so all of them can boot with just data from dts.

Regards,

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

Re: RGB LED control (was Re: advanced LED controllers)

[Geert Uytterhoeven]

Hi Pavel,

On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek pa...@ucw.cz wrote:
 Ok, so I played with RGB LED a bit, and we have quite a gap in
 documentation: what 50% brightness means is non-trivial and very
 important in case we want to do smooth blinking and color transitions.

 Signed-off-by: Pavel Machek pa...@ucw.cz

 diff --git a/Documentation/ABI/testing/sysfs-class-led 
 b/Documentation/ABI/testing/sysfs-class-led
 index 3646ec8..649d7a6 100644
 --- a/Documentation/ABI/testing/sysfs-class-led
 +++ b/Documentation/ABI/testing/sysfs-class-led
 @@ -8,6 +8,11 @@ Description:
 non-zero brightness settings. The value is between 0 and
 /sys/class/leds/led/max_brightness.

 +   If LED supports continuous brightness settings, 50% brightness
 +   should correspond to 50% brightness perceived by human, in a 
 similar
 +   manner pixel brightness on monitor does (not 50% PWM).

How many drivers do it right? How many don't?

For those that don't, perhaps we handle the conversion between perceived and
pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate
the need for conversion?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 11/24] ARM: OMAP2+: clock: remove support for legacy mpurate command line param

[Tero Kristo]

On 03/06/2015 06:25 PM, Tony Lindgren wrote:

* Tero Kristo t-kri...@ti.com [150306 08:10]:

On 03/06/2015 05:32 PM, Tony Lindgren wrote:

* Tero Kristo t-kri...@ti.com [150306 04:29]:

The legacy support is wrong and dangerous, as it doesn't take any
OPPs into account and does not scale voltages. Switching mpurate should
be handled through cpufreq.


Hmm I wonder if some systems actually rely on the mpurate cmdline
parameter. If this cannot be fixed properly, you should at least
print an error here.


Yea, I was kind of worried about this comment. We have also an option of
doing this through clock driver, but I was hesitant of doing this either.
Isn't having a global kernel option like this frowned upon anyway? I believe
this piece of init code gets executed on every board on multiarch kernel.


Well the option has been there probably for 10 years already so we
can't just drop it like that. Chances are it's unused though, so I
suggest you just print out a warning for it.

It's called from omap_arch_initcall which checks for soc_is_omap()
so that's not an issue. But when moving the code, you naturally
need to check the moved code initcall usage.


This patch is not really needed for the set itself btw, it can just be 
dropped if you feel it actually is used by someone. Reverting it from 
the set just causes a minor merge conflict and you can't remove two of 
the otherwise empty clock files.


You could also just move the code over to clock.c maybe, merge these and 
do a soc type check to reach the same behaviour.


-Tero
--
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: RGB LED control (was Re: advanced LED controllers)

[Pavel Machek]

On Mon 2015-03-09 09:08:37, Geert Uytterhoeven wrote:
 Hi Pavel,
 
 On Sun, Mar 8, 2015 at 9:57 PM, Pavel Machek pa...@ucw.cz wrote:
  Ok, so I played with RGB LED a bit, and we have quite a gap in
  documentation: what 50% brightness means is non-trivial and very
  important in case we want to do smooth blinking and color transitions.
 
  Signed-off-by: Pavel Machek pa...@ucw.cz
 
  diff --git a/Documentation/ABI/testing/sysfs-class-led 
  b/Documentation/ABI/testing/sysfs-class-led
  index 3646ec8..649d7a6 100644
  --- a/Documentation/ABI/testing/sysfs-class-led
  +++ b/Documentation/ABI/testing/sysfs-class-led
  @@ -8,6 +8,11 @@ Description:
  non-zero brightness settings. The value is between 0 and
  /sys/class/leds/led/max_brightness.
 
  +   If LED supports continuous brightness settings, 50% 
  brightness
  +   should correspond to 50% brightness perceived by human, in 
  a similar
  +   manner pixel brightness on monitor does (not 50% PWM).
 
 How many drivers do it right? How many don't?

Not sure. leds-lp5523.c gets is wrong. Easy test is to attempt to set
electric indigo color
(http://en.wikipedia.org/wiki/Indigo#Violet-blue) and see what comes
out.

 For those that don't, perhaps we handle the conversion between perceived and
 pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate
 the need for conversion?

There is not that many drivers that support smooth power
adjustments. But yes, we can probably conversion in the core for
trivial case.

Unfortunately, we only have 8-bits of precision to work with... 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html