Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> 
> Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> property.
> 
> If the use of /revision is limited to being a location to hold an ATAG
> value to pass to the global variable system_rev, then it would make
> sense to just copy directly from the ATAG value into system_rev in the
> same board file where you are copying the ATAGs.

Agreed. That would be simpler, and avoid a situation where someone relies
on the /revision property in DT to be set from the atags compat code
(preventing an upgrade to a newer bootloader), or on the system_rev variable
to be the same across multiple boot loaders, in the absence of other
kernel code setting it.

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] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Tony Lindgren]

* Ulf Hansson  [151228 04:18]:
> On 18 December 2015 at 23:31, Tony Lindgren  wrote:
> > * Ulf Hansson  [151218 14:20]:
> >> On 18 December 2015 at 17:14, Tony Lindgren  wrote:
> >> > * Ulf Hansson  [151207 16:20]:
> >> >> +Linus
> >> >>
> >> >> On 7 December 2015 at 23:54, Tony Lindgren  wrote:
> >> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
> >> >> > API")
> >> >> > changed the handling MMC power sequence so GPIOs no longer are 
> >> >> > optional.
> >> >> >
> >> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
> >> >> > GPIOs
> >> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
> >> >>
> >> >> Can you elaborate on this. Did it break omap5 or not? :-)
> >> >
> >> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
> >> > in Linux next or mainline trees?
> >>
> >> Ohh, I guess there where some misunderstanding. I made a bunch of
> >> comments on your patch as well, so I have been expecting a new
> >> version.
> >
> > Well this $subject patch was intended as a regression fix for v4.4-rc cycle.
> > All the other things discussed are not fixes but new features instead.
> >
> >> Sorry if that was unclear!
> >
> > I think this patch should be still fine as is, care to take a look again?
> 
> No, the patch have issues that needs to be fixed.
> http://www.spinics.net/lists/linux-mmc/msg34399.html

Oh sorry, somehow I did not notice those comments earlier, will take a look.

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 v3 00/23] Unrestricted media entity ID range support

[Mauro Carvalho Chehab]

Em Sun, 27 Dec 2015 19:11:36 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Wednesday 23 December 2015 10:32:42 Mauro Carvalho Chehab wrote:
> > Em Wed, 16 Dec 2015 16:03:01 +0200 Sakari Ailus escreveu:
> > > On Wed, Dec 16, 2015 at 03:32:15PM +0200, Sakari Ailus wrote:
> > > > This is the third version of the unrestricted media entity ID range
> > > > support set. I've taken Mauro's comments into account and fixed a number
> > > > of bugs as well (omap3isp memory leak and omap4iss stream start).
> > > 
> > > Javier: Mauro told me you might have OMAP4 hardware. Would you be able to
> > > test the OMAP4 ISS with these patches?
> > > 
> > > Thanks.
> > 
> > Sakari,
> > 
> > Testing with OMAP4 is not possible. The driver is broken: it doesn't
> > support DT, and the required pdata definition is missing.
> 
> What do you mean by missing ? struct iss_platform_data is defined in 
> include/media/omap4iss.h.
> 

As this driver is not DT, the platform data has to be part of the Kernel
tree for the driver to work. However, there are no board-specific data nor
any documentation about how to do that inside the Kernel tree. 
That means  that this driver won't work without some OOT patch.

So, on its current state, it is broken. It should either be
converted to DT and have the needed board definitions added to the
existing dts files or be removed.

Another possible approach would be to have a patch like the one
Javier and I tried to craft by adding the needed platform data
into arch/arm/mach-omap2/pdata-quirks.c, but I guess it is better
to just use DT instead.

Regards,
Mauro
--
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] mmc: pwrseq_simple: Fix regression with optional GPIOs

[Ulf Hansson]

On 18 December 2015 at 23:31, Tony Lindgren  wrote:
> * Ulf Hansson  [151218 14:20]:
>> On 18 December 2015 at 17:14, Tony Lindgren  wrote:
>> > * Ulf Hansson  [151207 16:20]:
>> >> +Linus
>> >>
>> >> On 7 December 2015 at 23:54, Tony Lindgren  wrote:
>> >> > Commit ce037275861e ("mmc: pwrseq_simple: use GPIO descriptors array 
>> >> > API")
>> >> > changed the handling MMC power sequence so GPIOs no longer are optional.
>> >> >
>> >> > This broke SDIO WLAN at least for omap5 that can't yet use the reset 
>> >> > GPIOs
>> >> > with pwrseq_simple as a wait is needed after enabling the SDIO device.
>> >>
>> >> Can you elaborate on this. Did it break omap5 or not? :-)
>> >
>> > Ulf, is this patch queued for v4.4 as a regression fix? I don't see it
>> > in Linux next or mainline trees?
>>
>> Ohh, I guess there where some misunderstanding. I made a bunch of
>> comments on your patch as well, so I have been expecting a new
>> version.
>
> Well this $subject patch was intended as a regression fix for v4.4-rc cycle.
> All the other things discussed are not fixes but new features instead.
>
>> Sorry if that was unclear!
>
> I think this patch should be still fine as is, care to take a look again?

No, the patch have issues that needs to be fixed.
http://www.spinics.net/lists/linux-mmc/msg34399.html

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

[PATCH v3 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335

[Uri Mashiach]

Device tree modifications:
- Pinmux for SPI0 and WiFi GPIOs.
- SPI0 node with wlcore as a child node.

Cc: Tony Lindgren 
Signed-off-by: Uri Mashiach 
Acked-by: Igor Grinberg 
---
v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
v2 -> v3: Move the pinctrl-0 = <_pins> to the wlcore node.

arch/arm/boot/dts/am335x-cm-t335.dts | 54 
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 42e9b66..b700940 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -11,6 +11,7 @@
 /dts-v1/;
 
 #include "am33xx.dtsi"
+#include 
 
 / {
model = "CompuLab CM-T335";
@@ -40,6 +41,15 @@
regulator-max-microvolt = <330>;
};
 
+   /* Regulator for WiFi */
+   vwlan_fixed: fixedregulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vwlan_fixed";
+   gpio = < 20 GPIO_ACTIVE_HIGH>; /* gpio0_20 */
+   enable-active-high;
+   regulator-boot-off;
+   };
+
backlight {
compatible = "pwm-backlight";
pwms = < 0 5 0>;
@@ -223,6 +233,21 @@
>;
};
 
+   spi0_pins: pinmux_spi0_pins {
+   pinctrl-single,pins = <
+   /* spi0_sclk.spi0_sclk */
+   AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE0)
+   /* spi0_d0.spi0_d0 */
+   AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLUP | MUX_MODE0)
+   /* spi0_d1.spi0_d1 */
+   AM33XX_IOPAD(0x958, PIN_INPUT | MUX_MODE0)
+   /* spi0_cs0.spi0_cs0 */
+   AM33XX_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0)
+   /* spi0_cs1.spi0_cs1 */
+   AM33XX_IOPAD(0x960, PIN_OUTPUT | MUX_MODE0)
+   >;
+   };
+
/* wl1271 bluetooth */
bluetooth_pins: pinmux_bluetooth_pins {
pinctrl-single,pins = <
@@ -230,6 +255,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLUP | MUX_MODE7)
>;
};
+
+   /* wl1271 WiFi */
+   wifi_pins: pinmux_wifi_pins {
+   pinctrl-single,pins = <
+   /* EMU1.gpio3_8 - WiFi IRQ */
+   AM33XX_IOPAD(0x9e8, PIN_INPUT_PULLUP | MUX_MODE7)
+   /* XDMA_EVENT_INTR1.gpio0_20 - WiFi enable */
+   AM33XX_IOPAD(0x9b4, PIN_OUTPUT | MUX_MODE7)
+   >;
+   };
 };
 
  {
@@ -394,3 +429,22 @@ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   ti,pindir-d0-out-d1-in = <1>;
+   /* WLS1271 WiFi */
+   wlcore: wlcore@1 {
+   compatible = "ti,wl1271";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   reg = <1>;
+   spi-max-frequency = <4800>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   interrupts-extended = < 8 IRQ_TYPE_LEVEL_HIGH>;
+   vwlan-supply = <_fixed>;
+   };
+};
-- 
2.5.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 v3 1/3] wlcore/wl12xx: spi: add power operation function

[Uri Mashiach]

The power function uses a consumer regulator access to update the WiFi
enable GPIO value.

Signed-off-by: Uri Mashiach 
---
v1 -> v2: oops fix was removed to a separate fix.
v2 -> v3: no changes

 drivers/net/wireless/ti/wlcore/spi.c | 37 
 1 file changed, 37 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 44f059f..d3a4bcb 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wlcore.h"
 #include "wl12xx_80211.h"
@@ -81,6 +82,7 @@
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
+   struct regulator *reg; /* Power regulator */
 };
 
 static void wl12xx_spi_reset(struct device *child)
@@ -318,11 +320,40 @@ static int __must_check wl12xx_spi_raw_write(struct 
device *child, int addr,
return 0;
 }
 
+/**
+ * wl12xx_spi_set_power - power on/off the wl12xx unit
+ * @child: wl12xx device handle.
+ * @enable: true/false to power on/off the unit.
+ *
+ * use the WiFi enable regulator to enable/disable the WiFi unit.
+ */
+static int wl12xx_spi_set_power(struct device *child, bool enable)
+{
+   int ret = 0;
+   struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
+
+   WARN_ON(!glue->reg);
+
+   /* Update regulator state */
+   if (enable) {
+   ret = regulator_enable(glue->reg);
+   if (ret)
+   dev_err(child, "Power enable failure\n");
+   } else {
+   ret =  regulator_disable(glue->reg);
+   if (ret)
+   dev_err(child, "Power disable failure\n");
+   }
+
+   return ret;
+}
+
 static struct wl1271_if_operations spi_ops = {
.read   = wl12xx_spi_raw_read,
.write  = wl12xx_spi_raw_write,
.reset  = wl12xx_spi_reset,
.init   = wl12xx_spi_init,
+   .power  = wl12xx_spi_set_power,
.set_block_size = NULL,
 };
 
@@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
 * comes from the board-peripherals file */
spi->bits_per_word = 32;
 
+   glue->reg = devm_regulator_get(>dev, "vwlan");
+   if (IS_ERR(glue->reg)) {
+   dev_err(glue->dev, "can't get regulator\n");
+   return PTR_ERR(glue->reg);
+   }
+
ret = spi_setup(spi);
if (ret < 0) {
dev_err(glue->dev, "spi_setup failed\n");
-- 
2.5.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 v3 2/3] wlcore/wl12xx: spi: add device tree support

[Uri Mashiach]

Add DT support for the wl1271 SPI WiFi.

Add documentation file for the wl1271 SPI WiFi.

Signed-off-by: Uri Mashiach 
Acked-by: Igor Grinberg 
---
v1 -> v2: update interrupt documentation.
  replace interrupts and interrupt-parent with interrupts-extended.
  IRQ parameters retrieved from spi_device instead of DT.
  remove redundant #ifdef CONFIG_OF
v2 -> v3: Add MODULE_DEVICE_TABLE.
  Remove #ifdef CONFIG_OF.
  Make the Kconfig symbol to depend on OF.
  Replace irqd_get_trigger_type() with irq_get_trigger_type().

 .../bindings/net/wireless/ti,wlcore,spi.txt| 34 
 drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
 drivers/net/wireless/ti/wlcore/spi.c   | 47 --
 3 files changed, 78 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
new file mode 100644
index 000..502c27e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -0,0 +1,34 @@
+* Texas Instruments wl1271 wireless lan controller
+
+The wl1271 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible :  Should be "ti,wl1271"
+- reg : Chip select address of device
+- spi-max-frequency :   Maximum SPI clocking speed of device in Hz
+- ref-clock-frequency : Reference clock frequency
+- interrupts-extended : Should contain parameters for 1 interrupt line.
+Interrupt parameters: parent, line number, type.
+- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+
+Optional properties:
+- clock-xtal :  boolean, clock is generated from XTAL
+
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+  for optional SPI connection related properties,
+
+Examples:
+
+ {
+   wl1271@1 {
+   compatible = "ti,wl1271";
+
+   reg = <1>;
+   spi-max-frequency = <4800>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   interrupts-extended = < 8 IRQ_TYPE_LEVEL_HIGH>;
+   vwlan-supply = <_fixed>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/Kconfig 
b/drivers/net/wireless/ti/wlcore/Kconfig
index 7c09954..5918080 100644
--- a/drivers/net/wireless/ti/wlcore/Kconfig
+++ b/drivers/net/wireless/ti/wlcore/Kconfig
@@ -13,7 +13,7 @@ config WLCORE
 
 config WLCORE_SPI
tristate "TI wlcore SPI support"
-   depends on WLCORE && SPI_MASTER
+   depends on WLCORE && SPI_MASTER && OF
select CRC7
---help---
  This module adds support for the SPI interface of adapters using
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index d3a4bcb..0f2fb50 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "wlcore.h"
@@ -357,6 +358,39 @@ static struct wl1271_if_operations spi_ops = {
.set_block_size = NULL,
 };
 
+static const struct of_device_id wlcore_spi_of_match_table[] = {
+   { .compatible = "ti,wl1271" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
+
+/**
+ * wlcore_probe_of - DT node parsing.
+ * @spi: SPI slave device parameters.
+ * @res: resource parameters.
+ * @glue: wl12xx SPI bus to slave device glue parameters.
+ * @pdev_data: wlcore device parameters
+ */
+static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue 
*glue,
+  struct wlcore_platdev_data *pdev_data)
+{
+   struct device_node *dt_node = spi->dev.of_node;
+   int ret;
+
+   if (of_find_property(dt_node, "clock-xtal", NULL))
+   pdev_data->ref_clock_xtal = true;
+
+   ret = of_property_read_u32(dt_node, "ref-clock-frequency",
+  _data->ref_clock_freq);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(glue->dev,
+   "can't get reference clock frequency (%d)\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int wl1271_probe(struct spi_device *spi)
 {
struct wl12xx_spi_glue *glue;
@@ -366,8 +400,6 @@ static int wl1271_probe(struct spi_device *spi)
 
memset(_data, 0x00, sizeof(pdev_data));
 
-   /* TODO: add DT parsing when needed */
-
pdev_data.if_ops = _ops;
 
glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
@@ -390,6 +422,13 @@ static int wl1271_probe(struct spi_device *spi)
return PTR_ERR(glue->reg);
}
 
+   ret = wlcore_probe_of(spi, glue, 

[PATCH v3 0/3] wlcore/wl12xx: spi: add wifi support to cm-t335

[Uri Mashiach]

Add DT support for WLS1271 SPI driver.
Add power operation function to the WLS1271 SPI driver.

Uri Mashiach (3):
  wlcore/wl12xx: spi: add power operation function
  wlcore/wl12xx: spi: add device tree support
  wlcore/wl12xx: spi: add wifi support to cm-t335

 .../bindings/net/wireless/ti,wlcore,spi.txt| 34 +
 arch/arm/boot/dts/am335x-cm-t335.dts   | 54 ++
 drivers/net/wireless/ti/wlcore/Kconfig |  2 +-
 drivers/net/wireless/ti/wlcore/spi.c   | 84 --
 4 files changed, 169 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt

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

Re: bbb kexec bug: Unhandled fault external abort on non-linefetch (0x1028) at 0xfa1ac140

[Grygorii Strashko]

On 12/28/2015 09:18 AM, Dave Young wrote:
> On 12/27/15 at 03:38pm, Dave Young wrote:
>> Here is what I get when I test kdump on Beagle bone black:
>>
>> Added a printk line at the begin of function omap_gpio_rmw:
>> printk("## %lx, %x, %x\n", base, reg, mask);
>>
>> Any hints how to fix it? I tried call the machine_kexec_mask_interrupts
>> at runtime kernel also panics so it may not limit to kdump case.
>>
>> [   66.340168] ## fa1ac000, 140, 1
>> [   66.344456] Unhandled fault: external abort on non-linefetch (0x1028) at 
>> 0xfa1ac140
>> [   66.352142] pgd = dd9f

[...]

>> [   66.727278] [] (omap_set_gpio_triggering) from [] 
>> (omap_gpio_mask_irq+0x29/0x34)

Usually such back-trace means that you are trying to access HW
which is disabled (powered off) already. Or this HW IP has never been enabled.

>> [   66.736457] [] (omap_gpio_mask_irq) from [] 
>> (machine_crash_shutdown+0xb9/0x104)
>> [   66.745551] [] (machine_crash_shutdown) from [] 
>> (crash_kexec+0x35/0x68)
>> [   66.753942] [] (crash_kexec) from [] (die+0x1b9/0x390)
>> [   66.760859] [] (die) from [] 
>> (__do_kernel_fault.part.0+0x4f/0x1cc)
>> [   66.768824] [] (__do_kernel_fault.part.0) from [] 
>> (do_page_fault+0x155/0x29c)
>> [   66.40] [] (do_page_fault) from [] 
>> (do_DataAbort+0x2f/0x88)
>> [   66.785432] [] (do_DataAbort) from [] 
>> (__dabt_svc+0x3b/0x80)
>> [   66.792858] Exception stack(0xddc39e58 to 0xddc39ea0)
>> [   66.797929] 9e40:   
>> 0063 df93647c
>> [   66.806144] 9e60: 1f26a000  0001 0063 0007 c0702e3c 
>>  ddc38000
>> [   66.814359] 9e80:  7f70d614 0030 ddc39ea8 c021e54b c021e54c 
>> 600e0033 
>> [   66.822575] [] (__dabt_svc) from [] 
>> (sysrq_handle_crash+0x18/0x1c)
>> [   66.830530] [] (sysrq_handle_crash) from [] 
>> (__handle_sysrq+0x79/0x10c)
>> [   66.838919] [] (__handle_sysrq) from [] 
>> (write_sysrq_trigger+0x45/0x50)
>> [   66.847310] [] (write_sysrq_trigger) from [] 
>> (proc_reg_write+0x43/0x68)
>> [   66.855700] [] (proc_reg_write) from [] 
>> (__vfs_write+0xf/0x8c)
>> [   66.863304] [] (__vfs_write) from [] 
>> (vfs_write+0x5f/0x128)
>> [   66.870646] [] (vfs_write) from [] 
>> (SyS_write+0x2b/0x68)
>> [   66.877729] [] (SyS_write) from [] 
>> (ret_fast_syscall+0x1/0x4c)
>> [   66.885332] Code: 443c 4643 f6a9 f9a1 (6823) 0732
>> [   66.890145] ---[ end trace 5a39094ece4dc200 ]---
>> [   66.894782] Kernel panic - not syncing: Fatal exception
>> [   66.900033] ---[ end Kernel panic - not syncing: Fatal exception
>>


-- 
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: [PATCH v2 1/3] wlcore/wl12xx: spi: add power operation function

[Grygorii Strashko]

On 12/27/2015 07:14 PM, Uri Mashiach wrote:
> Hello Grygorii,
> 
> On 12/24/2015 06:32 PM, Grygorii Strashko wrote:
>> On 12/24/2015 05:35 PM, Uri Mashiach wrote:
>>> The power function uses a consumer regulator access to update the WiFi
>>> enable GPIO value.
>>>
>>> Signed-off-by: Uri Mashiach 
>>> ---
>>> v1 -> v2: oops fix was removed to a separate fix.
>>>
>>>   drivers/net/wireless/ti/wlcore/spi.c | 37
>>> 
>>>   1 file changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/spi.c
>>> b/drivers/net/wireless/ti/wlcore/spi.c
>>>
>>
>> [...]
>>
>>> +
>>>   static struct wl1271_if_operations spi_ops = {
>>>   .read= wl12xx_spi_raw_read,
>>>   .write= wl12xx_spi_raw_write,
>>>   .reset= wl12xx_spi_reset,
>>>   .init= wl12xx_spi_init,
>>> +.power= wl12xx_spi_set_power,
>>>   .set_block_size = NULL,
>>>   };
>>>
>>> @@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
>>>* comes from the board-peripherals file */
>>>   spi->bits_per_word = 32;
>>>
>>> +glue->reg = devm_regulator_get(>dev, "vwlan");
>>> +if (IS_ERR(glue->reg)) {
>>
>> It will be more correct to handle -EPROBE_DEFER here also. Like:
>>   if (PTR_ERR(glue->reg) == -EPROBE_DEFER)
>>  return PTR_ERR(glue->reg);
>>
> 
> It seems that the IS_ERR(glue->reg) condition covers the EPROBE_DEFER case.

True. But this is not an error and it's common practice do not print
any log messages in this case from driver :)

> 
>>> +dev_err(glue->dev, "can't get regulator\n");
>>> +return PTR_ERR(glue->reg);
>>> +}
>>> +
>>>   ret = spi_setup(spi);
>>>   if (ret < 0) {
>>>   dev_err(glue->dev, "spi_setup failed\n");
>>>
>>
>>
> 


-- 
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 0/2] ti-gpmc: Add support for AAD timings

[Neil Armstrong]

This serie add support for the GPMC Advanced AAD timings on hardware supporting
the feature like the AM335x and DM816X.

Neil Armstrong (2):
  memory: omap-gpmc: Add support for AAD timings
  dt-bindings: bus: ti-gpmc: Add AAD timings properties

 Documentation/devicetree/bindings/bus/ti-gpmc.txt |  5 
 drivers/memory/omap-gpmc.c| 30 +++
 include/linux/omap-gpmc.h |  5 
 3 files changed, 40 insertions(+)

-- 
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 1/2] memory: omap-gpmc: Add support for AAD timings

[Neil Armstrong]

In order to support extended timings parameters on hardware supporting the
"AAD" mode like the AM335x or DM816x, add these entries into the GPMC driver
if the hardware is capable.

Tested on DM816x and AM335x.

Signed-off-by: Neil Armstrong 
---
 drivers/memory/omap-gpmc.c | 30 ++
 include/linux/omap-gpmc.h  |  5 +
 2 files changed, 35 insertions(+)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 6515dfc..21825dd 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -541,9 +541,20 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
GPMC_GET_TICKS(GPMC_CS_CONFIG3,  0,  3, "adv-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG3,  8, 12, "adv-rd-off-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG3, 16, 20, "adv-wr-off-ns");
+   if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+   GPMC_GET_TICKS(GPMC_CS_CONFIG3, 4, 6, "adv-aad-mux-on-ns");
+   GPMC_GET_TICKS(GPMC_CS_CONFIG3, 24, 26,
+   "adv-aad-mux-rd-off-ns");
+   GPMC_GET_TICKS(GPMC_CS_CONFIG3, 28, 30,
+   "adv-aad-mux-wr-off-ns");
+   }
 
GPMC_GET_TICKS(GPMC_CS_CONFIG4,  0,  3, "oe-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG4,  8, 12, "oe-off-ns");
+   if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+   GPMC_GET_TICKS(GPMC_CS_CONFIG4,  4,  6, "oe-aad-mux-on-ns");
+   GPMC_GET_TICKS(GPMC_CS_CONFIG4, 13, 15, "oe-aad-mux-off-ns");
+   }
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 16, 19, "we-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 24, 28, "we-off-ns");
 
@@ -734,9 +745,18 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings 
*t,
GPMC_SET_ONE(GPMC_CS_CONFIG3,  0,  3, adv_on);
GPMC_SET_ONE(GPMC_CS_CONFIG3,  8, 12, adv_rd_off);
GPMC_SET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+   if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+   GPMC_SET_ONE(GPMC_CS_CONFIG3,  4,  6, adv_aad_mux_on);
+   GPMC_SET_ONE(GPMC_CS_CONFIG3, 24, 26, adv_aad_mux_rd_off);
+   GPMC_SET_ONE(GPMC_CS_CONFIG3, 28, 30, adv_aad_mux_wr_off);
+   }
 
GPMC_SET_ONE(GPMC_CS_CONFIG4,  0,  3, oe_on);
GPMC_SET_ONE(GPMC_CS_CONFIG4,  8, 12, oe_off);
+   if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+   GPMC_SET_ONE(GPMC_CS_CONFIG4,  4,  6, oe_aad_mux_on);
+   GPMC_SET_ONE(GPMC_CS_CONFIG4, 13, 15, oe_aad_mux_off);
+   }
GPMC_SET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
GPMC_SET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
 
@@ -1722,6 +1742,12 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
of_property_read_u32(np, "gpmc,adv-on-ns", _t->adv_on);
of_property_read_u32(np, "gpmc,adv-rd-off-ns", _t->adv_rd_off);
of_property_read_u32(np, "gpmc,adv-wr-off-ns", _t->adv_wr_off);
+   of_property_read_u32(np, "gpmc,adv-aad-mux-on-ns",
+_t->adv_aad_mux_on);
+   of_property_read_u32(np, "gpmc,adv-aad-mux-rd-off-ns",
+_t->adv_aad_mux_rd_off);
+   of_property_read_u32(np, "gpmc,adv-aad-mux-wr-off-ns",
+_t->adv_aad_mux_wr_off);
 
/* WE signal timings */
of_property_read_u32(np, "gpmc,we-on-ns", _t->we_on);
@@ -1730,6 +1756,10 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
/* OE signal timings */
of_property_read_u32(np, "gpmc,oe-on-ns", _t->oe_on);
of_property_read_u32(np, "gpmc,oe-off-ns", _t->oe_off);
+   of_property_read_u32(np, "gpmc,oe-aad-mux-on-ns",
+_t->oe_aad_mux_on);
+   of_property_read_u32(np, "gpmc,oe-aad-mux-off-ns",
+_t->oe_aad_mux_off);
 
/* access and cycle timings */
of_property_read_u32(np, "gpmc,page-burst-access-ns",
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 7dee0014..d833eb4 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -51,6 +51,9 @@ struct gpmc_timings {
u32 adv_on; /* Assertion time */
u32 adv_rd_off; /* Read deassertion time */
u32 adv_wr_off; /* Write deassertion time */
+   u32 adv_aad_mux_on; /* ADV assertion time for AAD */
+   u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
+   u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
 
/* WE signals timings corresponding to GPMC_CONFIG4 */
u32 we_on;  /* WE assertion time */
@@ -59,6 +62,8 @@ struct gpmc_timings {
/* OE signals timings corresponding to GPMC_CONFIG4 */
u32 oe_on;  /* OE assertion time */
u32 oe_off; /* OE deassertion time */
+   u32 oe_aad_mux_on;  /* OE assertion time for AAD */
+   u32 oe_aad_mux_off; /* OE deassertion time 

[PATCH 2/2] dt-bindings: bus: ti-gpmc: Add AAD timings properties

[Neil Armstrong]

In order to support advanced AAD timings, add these properties to the DT
GPMC bindings.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/bus/ti-gpmc.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 704be93..0168370 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -46,6 +46,9 @@ Timing properties for child nodes. All are optional and 
default to 0.
  - gpmc,adv-on-ns: Assertion time
  - gpmc,adv-rd-off-ns: Read deassertion time
  - gpmc,adv-wr-off-ns: Write deassertion time
+ - gpmc,adv-aad-mux-on-ns: Assertion time for AAD
+ - gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD
+ - gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD
 
  WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
  - gpmc,we-on-ns   Assertion time
@@ -54,6 +57,8 @@ Timing properties for child nodes. All are optional and 
default to 0.
  OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
  - gpmc,oe-on-ns:  Assertion time
  - gpmc,oe-off-ns: Deassertion time
+ - gpmc,oe-aad-mux-on-ns:  Assertion time for AAD
+ - gpmc,oe-aad-mux-off-ns: Deassertion time for AAD
 
  Access time and cycle time timings (in nanoseconds) corresponding to
  GPMC_CONFIG5:
-- 
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: am4372: fix irq type for arm twd and global timer

[Grygorii Strashko]

As per ARM documentation
PPI(0) ID27 - global timer interrupt is rising-edge sensitive.
PPI(2) ID29 - twd interrupt is rising-edge sensitive.

and the same is proved by GIC distributor register value
GIC_DIST_CONFIG(0xC04) = 0x7DC0.

Hence, set IRQ triggering type to IRQ_TYPE_EDGE_RISING
for ARM TWD and Global timers.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am4372.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index de8791a..dfa1a29 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -72,7 +72,7 @@
global_timer: timer@48240200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x48240200 0x100>;
-   interrupts = ;
+   interrupts = ;
interrupt-parent = <>;
clocks = <_periphclk>;
};
@@ -80,7 +80,7 @@
local_timer: timer@48240600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x48240600 0x100>;
-   interrupts = ;
+   interrupts = ;
interrupt-parent = <>;
clocks = <_periphclk>;
};
-- 
2.6.4

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

[PATCH] ARM: dts: am437x: pixcir_tangoc: use correct flags for irq types

[Grygorii Strashko]

Now IRQs for Pixcir Tangoc touchscreen are defined using
IRQ_TYPE_NONE in am437x-gp-evm.dts and am43x-epos-evm.dts wich
do not correspond HW.

Hence, update am437x-gp-evm.dts and am43x-epos-evm.dts files
and use correct flag IRQ_TYPE_EDGE_FALLING for irq types.

While here, remove duplicated irq declaration for pixcir_ts@5c node
in am437x-gp-evm.dts.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am437x-gp-evm.dts  | 4 +---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index d2450ab..fc4c371 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -590,8 +590,6 @@
pinctrl-names = "default";
pinctrl-0 = <_ts_pins>;
reg = <0x5c>;
-   interrupt-parent = <>;
-   interrupts = <22 0>;
 
attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
 
@@ -599,7 +597,7 @@
 * 0x264 represents the offset of padconf register of
 * gpio3_22 from am43xx_pinmux base.
 */
-   interrupts-extended = < 22 IRQ_TYPE_NONE>,
+   interrupts-extended = < 22 IRQ_TYPE_EDGE_FALLING>,
  <_pinmux 0x264>;
interrupt-names = "tsc", "wakeup";
 
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 47954ed..29c6580 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -491,7 +491,7 @@
pinctrl-0 = <_ts_pins>;
reg = <0x5c>;
interrupt-parent = <>;
-   interrupts = <17 0>;
+   interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
 
attb-gpio = < 17 GPIO_ACTIVE_HIGH>;
 
-- 
2.6.4

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

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > * Arnd Bergmann  [150515 14:26]:
> > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > If setting up the generic binding is expected to take a while,
> > > you can naturally pass it in pdata while waiting for the generic
> > > binding to get merged.
> > 
> > Yes, good idea. So the n900 machine can use auxdata to pass this for
> > the time being, while the binding and generic implementation is
> > being worked out.
> > 
> 
> Ok, so what is needed to finish this patch series?

I don't know where we are at this point. Has either the auxdata approach
or the generic binding been worked on at all?

If not, please try to get the auxdata variant to work, it should not be hard
at all because there is no dependency on a generic binding.

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 1/3] wlcore/wl12xx: spi: add power operation function

[Uri Mashiach]

Hi Grygorii,

On 12/28/2015 01:59 PM, Grygorii Strashko wrote:

On 12/27/2015 07:14 PM, Uri Mashiach wrote:

Hello Grygorii,

On 12/24/2015 06:32 PM, Grygorii Strashko wrote:

On 12/24/2015 05:35 PM, Uri Mashiach wrote:

The power function uses a consumer regulator access to update the WiFi
enable GPIO value.

Signed-off-by: Uri Mashiach 
---
v1 -> v2: oops fix was removed to a separate fix.

   drivers/net/wireless/ti/wlcore/spi.c | 37

   1 file changed, 37 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c



[...]


+
   static struct wl1271_if_operations spi_ops = {
   .read= wl12xx_spi_raw_read,
   .write= wl12xx_spi_raw_write,
   .reset= wl12xx_spi_reset,
   .init= wl12xx_spi_init,
+.power= wl12xx_spi_set_power,
   .set_block_size = NULL,
   };

@@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
* comes from the board-peripherals file */
   spi->bits_per_word = 32;

+glue->reg = devm_regulator_get(>dev, "vwlan");
+if (IS_ERR(glue->reg)) {


It will be more correct to handle -EPROBE_DEFER here also. Like:
   if (PTR_ERR(glue->reg) == -EPROBE_DEFER)
  return PTR_ERR(glue->reg);



It seems that the IS_ERR(glue->reg) condition covers the EPROBE_DEFER case.


True. But this is not an error and it's common practice do not print
any log messages in this case from driver :)



Sorry, already posted v3.
Will be in v4.




+dev_err(glue->dev, "can't get regulator\n");
+return PTR_ERR(glue->reg);
+}
+
   ret = spi_setup(spi);
   if (ret < 0) {
   dev_err(glue->dev, "spi_setup failed\n");











--
Thanks,
Uri
--
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] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > * Arnd Bergmann  [150515 14:26]:
> > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > If setting up the generic binding is expected to take a while,
> > > > you can naturally pass it in pdata while waiting for the
> > > > generic binding to get merged.
> > > 
> > > Yes, good idea. So the n900 machine can use auxdata to pass this
> > > for the time being, while the binding and generic implementation
> > > is being worked out.
> > 
> > Ok, so what is needed to finish this patch series?
> 
> I don't know where we are at this point. Has either the auxdata
> approach or the generic binding been worked on at all?

What are auxdata data? And what do you mean with "generic binding" 
approach?

> If not, please try to get the auxdata variant to work, it should not
> be hard at all because there is no dependency on a generic binding.
> 
>   Arnd


-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > * Arnd Bergmann  [150515 14:26]:
> > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > If setting up the generic binding is expected to take a while,
> > > > > you can naturally pass it in pdata while waiting for the
> > > > > generic binding to get merged.
> > > > 
> > > > Yes, good idea. So the n900 machine can use auxdata to pass this
> > > > for the time being, while the binding and generic implementation
> > > > is being worked out.
> > > 
> > > Ok, so what is needed to finish this patch series?
> > 
> > I don't know where we are at this point. Has either the auxdata
> > approach or the generic binding been worked on at all?
> 
> What are auxdata data? 

I mean you can add the platform data to the omap_auxdata_lookup[] table
for this board.

> And what do you mean with "generic binding" approach?

Start a discussion to specify slot names and implement that in the
mmc driver core, so we can remove the hack from the OMAP driver and
make it work the same way for any machine.

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 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote:
> > On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > > > * Arnd Bergmann  [150515 14:26]:
> > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > > > If setting up the generic binding is expected to take a
> > > > > > > while, you can naturally pass it in pdata while waiting
> > > > > > > for the generic binding to get merged.
> > > > > > 
> > > > > > Yes, good idea. So the n900 machine can use auxdata to pass
> > > > > > this for the time being, while the binding and generic
> > > > > > implementation is being worked out.
> > > > > 
> > > > > Ok, so what is needed to finish this patch series?
> > > > 
> > > > I don't know where we are at this point. Has either the auxdata
> > > > approach or the generic binding been worked on at all?
> > > 
> > > What are auxdata data?
> > 
> > I mean you can add the platform data to the omap_auxdata_lookup[]
> > table for this board.
> 
> But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?

Yes.

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 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Pali Rohár]

On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote:
> On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > > * Arnd Bergmann  [150515 14:26]:
> > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > > If setting up the generic binding is expected to take a
> > > > > > while, you can naturally pass it in pdata while waiting
> > > > > > for the generic binding to get merged.
> > > > > 
> > > > > Yes, good idea. So the n900 machine can use auxdata to pass
> > > > > this for the time being, while the binding and generic
> > > > > implementation is being worked out.
> > > > 
> > > > Ok, so what is needed to finish this patch series?
> > > 
> > > I don't know where we are at this point. Has either the auxdata
> > > approach or the generic binding been worked on at all?
> > 
> > What are auxdata data?
> 
> I mean you can add the platform data to the omap_auxdata_lookup[]
> table for this board.

But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff

[Nishanth Menon]

On 12/20/2015 11:46 PM, Keerthy wrote:

+linux-pm.

> In few rare conditions like during boot up the orderly_poweroff
> function might not be able to complete fully leaving the device
> running at dangerously high temperatures. Hence adding a backup
> workqueue to act after a known period of time and poweroff the device.
> 


> Suggested-by: Nishanth Menon 
> Reported-by: Nishanth Menon 

The specific case I hit was a critical temperature event as soon as
the hwmon device was probed (the driver tmp102 was a kernel module).

> Signed-off-by: Keerthy 
> ---
>  drivers/thermal/Kconfig|  9 +
>  drivers/thermal/thermal_core.c | 26 ++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 8cc4ac6..25584ee 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -92,6 +92,15 @@ config THERMAL_DEFAULT_GOV_POWER_ALLOCATOR
>  
>  endchoice
>  
> +config THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +int "Thermal shutdown  backup delay in milli-seconds"
> +depends on THERMAL
> +default "5000"
> +---help---
> +The number of milliseconds to delay after orderly_poweroff call.

Probably needs a rephrase.

> +
> +Default: 5000 (5 seconds)
> +
>  config THERMAL_GOV_FAIR_SHARE
>   bool "Fair-share thermal governor"
>   help
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index d9e525c..b793857 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -61,6 +61,12 @@ static DEFINE_MUTEX(thermal_governor_lock);
>  
>  static struct thermal_governor *def_governor;
>  
> +#ifdef CONFIG_THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +#define BKUP_SHUTDOWN_DELAY CONFIG_THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +#else
> +#define BKUP_SHUTDOWN_DELAY 5000
> +#endif
> +

I am not sure if this #ifdeffery is even needed.


Eduardo, Rui: If this is not the suggested technique, maybe you guys
could suggest how we could handle a case where userspace might be
hungup due to some reason and a case where a critical temperature
event in the middle of device probe was triggered?

Obviously, we'd like to take into consideration userspace latencies as
well- but that is very specific to fs being run.. not really a simple
problem, IMHO..

>  static struct thermal_governor *__find_governor(const char *name)
>  {
>   struct thermal_governor *pos;
> @@ -423,6 +429,18 @@ static void handle_non_critical_trips(struct 
> thermal_zone_device *tz,
>  def_governor->throttle(tz, trip);
>  }
>  
> +static void bkup_shutdown_func(struct work_struct *unused);
> +static DECLARE_DELAYED_WORK(bkup_shutdown_work, bkup_shutdown_func);
> +
> +static void bkup_shutdown_func(struct work_struct *work)
> +{
> + pr_warn("Orderly_poweroff has failed! Attempting kernel_power_off\n");
> + kernel_power_off();
> +
> + pr_warn("kernel_power_off has failed! Attempting emergency_restart\n");
> + emergency_restart();

I think documentation is necessary that we are hoping for bootloader
to be able to detect and halt as needed -> risk here obviously is an
infinite reboot loop :( .


> +}
> +
>  static void handle_critical_trips(struct thermal_zone_device *tz,
>   int trip, enum thermal_trip_type trip_type)
>  {
> @@ -443,6 +461,14 @@ static void handle_critical_trips(struct 
> thermal_zone_device *tz,
>   dev_emerg(>device,
> "critical temperature reached(%d C),shutting down\n",
> tz->temperature / 1000);
> + /**

needs to be kernel doc style?

> +  * This is a backup option to shutdown the
> +  * system in case orderly_poweroff
> +  * fails
Maybe adjust to 80char?

> +  */
> + schedule_delayed_work(_shutdown_work,
> +   msecs_to_jiffies(BKUP_SHUTDOWN_DELAY));
> +
>   orderly_poweroff(true);
>   }
>  }
> 


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

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Frank Rowand]

Adding devicetree-spec, and commenting below.

On 12/24/2015 11:02 AM, Pali Rohár wrote:
> On Monday 06 July 2015 22:26:09 Pali Rohár wrote:
>> With this patch "/revision" DT entry is used to set global system_rev
>> variable. DT "/revision" is expected to be u32 numeric value.
>>
>> TODO: add documentation
>>
>> Signed-off-by: Pali Rohár 
>> ---
>>  arch/arm/kernel/devtree.c |   12 ++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
>> index 11c54de..7d82749 100644
>> --- a/arch/arm/kernel/devtree.c
>> +++ b/arch/arm/kernel/devtree.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  #include 
>> @@ -26,6 +27,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  
>>  #ifdef CONFIG_SMP
>> @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char 
>> *const **match)
>>  const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>>  {
>>  const struct machine_desc *mdesc, *mdesc_best = NULL;
>> +unsigned long dt_root;
>> +const u32 *rev;
>>  
>>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>>  DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
>> @@ -215,17 +219,16 @@ const struct machine_desc * __init 
>> setup_machine_fdt(unsigned int dt_phys)
>>  if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
>>  return NULL;
>>  
>> +dt_root = of_get_flat_dt_root();
>>  mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>>  
>>  if (!mdesc) {
>>  const char *prop;
>>  int size;
>> -unsigned long dt_root;
>>  
>>  early_print("\nError: unrecognized/unsupported "
>>  "device tree compatible list:\n[ ");
>>  
>> -dt_root = of_get_flat_dt_root();
>>  prop = of_get_flat_dt_prop(dt_root, "compatible", );
>>  while (size > 0) {
>>  early_print("'%s' ", prop);
>> @@ -246,5 +249,10 @@ const struct machine_desc * __init 
>> setup_machine_fdt(unsigned int dt_phys)
>>  /* Change machine number to match the mdesc we're using */
>>  __machine_arch_type = mdesc->nr;
>>  
>> +/* Set system revision from DT */
>> +rev = of_get_flat_dt_prop(dt_root, "revision", NULL);
>> +if (rev)
>> +system_rev = fdt32_to_cpu(*rev);
>> +
>>  return mdesc;
>>  }
> 
> This patch and second one (with subject "[PATCH 2/5] arm: boot: convert
> ATAG_REVISION to DT "/revision" entry") are still needed.
> 
> Are there any objections for them? If not, I will add missing DT
> documentation and will resend them.

Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
property.

If the use of /revision is limited to being a location to hold an ATAG
value to pass to the global variable system_rev, then it would make
sense to just copy directly from the ATAG value into system_rev in the
same board file where you are copying the ATAGs.

-Frank

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Paul Kocialkowski]

Hi Milo, thanks for the review,

Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
> Hi Paul,
> 
> On 23/12/15 20:56, Mark Brown wrote:
> > On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >
> >> +  gpio = lp->pdata->enable_gpio;
> >> +  if (!gpio_is_valid(gpio))
> >> +  return 0;
> >> +
> >> +  /* Always set enable GPIO high. */
> >> +  ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X 
> >> EN");
> >> +  if (ret) {
> >> +  dev_err(lp->dev, "gpio request err: %d\n", ret);
> >> +  return ret;
> >> +  }
> >
> > This isn't really adding support for the enable GPIO as the changelog
> > suggests, it's requesting but not managing the GPIO.  Since there is
> > core support for manging enable GPIOs this seems especially silly,
> > please tell the core about the GPIO and then it will work at runtime
> > too.
> >
> 
> With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in 
> LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only 
> can be controlled by external pin when CONFIG pin is grounded.
> 
> Please see the description at page 5 of the datasheet.
> 
>   http://www.ti.com/lit/ds/symlink/lp8725.pdf

After reading the datasheets thoroughly, it seems to me that for the
lp8720, the EN pin is used to enable the regulators output, which is a
good fit for the core regulator GPIO framework, as there is no reason to
keep it on when no regulator is in use. The serial interface is already
available when EN=0 and regulators can be configured in that state. The
lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
EN=0"). On the other hand, it is indeed used as a power-on pin when
CONFIG=1.

Since my intent here is to cover the lp8720 use case, I suggest that we
implement this using the core regulator GPIO framework (I have patches
ready for that) and leave out the case where CONFIG=1, which could be
dealt with later by providing that piece of information via platform
data (and devicetree) and then either use the regulator GPIO framework
(when CONFIG=0 and default) or register the GPIO within the driver and
keep it on at all times (when CONFIG=1).

I could most certainly implement that behaviour, but I'd rather leave it
to someone else (or at least the testing) since I don't have any lp8725
to play with.

What do you think?

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part

[PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+

[Yong Li]

Based on the below
commit ae3c99a26c60 ("ARM: 7806/1: allow DEBUG_UNCOMPRESS for Tegra"),
change the .data section to .text section,
to enable DEBUG_UNCOMPRESS for OMAP2+ platforms
Tested okay using BeagleBone Black

Signed-off-by: Yong Li 
---
 arch/arm/Kconfig.debug |  2 +-
 arch/arm/include/debug/omap2plus.S | 13 ++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 259c0ca..e5ae36a 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1596,7 +1596,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
 config DEBUG_UNCOMPRESS
bool
depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
-   default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
+   default y if DEBUG_LL && (!DEBUG_OMAP2PLUS_UART || !ZBOOT_ROM) && \
 (!DEBUG_TEGRA_UART || !ZBOOT_ROM)
help
  This option influences the normal decompressor output for
diff --git a/arch/arm/include/debug/omap2plus.S 
b/arch/arm/include/debug/omap2plus.S
index 6d867ae..12421f9 100644
--- a/arch/arm/include/debug/omap2plus.S
+++ b/arch/arm/include/debug/omap2plus.S
@@ -58,11 +58,18 @@
 
 #define UART_OFFSET(addr)  ((addr) & 0x00ff)
 
+#if defined(ZIMAGE)
+   omap_uart_phys: .word   0
+   omap_uart_virt: .word   0
+   omap_uart_lsr:  .word   0
+#else
+
.pushsection .data
-omap_uart_phys:.word   0
-omap_uart_virt:.word   0
-omap_uart_lsr: .word   0
+   omap_uart_phys: .word   0
+   omap_uart_virt: .word   0
+   omap_uart_lsr:  .word   0
.popsection
+#endif
 
.macro  addruart, rp, rv, tmp
 
-- 
2.1.4

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

[Milo Kim]

Hi Paul,

On 29/12/15 07:49, Paul Kocialkowski wrote:

Hi Milo, thanks for the review,

Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :

Hi Paul,

On 23/12/15 20:56, Mark Brown wrote:

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:


+   gpio = lp->pdata->enable_gpio;
+   if (!gpio_is_valid(gpio))
+   return 0;
+
+   /* Always set enable GPIO high. */
+   ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X 
EN");
+   if (ret) {
+   dev_err(lp->dev, "gpio request err: %d\n", ret);
+   return ret;
+   }


This isn't really adding support for the enable GPIO as the changelog
suggests, it's requesting but not managing the GPIO.  Since there is
core support for manging enable GPIOs this seems especially silly,
please tell the core about the GPIO and then it will work at runtime
too.



With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
can be controlled by external pin when CONFIG pin is grounded.

Please see the description at page 5 of the datasheet.

http://www.ti.com/lit/ds/symlink/lp8725.pdf


After reading the datasheets thoroughly, it seems to me that for the
lp8720, the EN pin is used to enable the regulators output, which is a
good fit for the core regulator GPIO framework, as there is no reason to
keep it on when no regulator is in use. The serial interface is already
available when EN=0 and regulators can be configured in that state. The
lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
EN=0"). On the other hand, it is indeed used as a power-on pin when
CONFIG=1.


I think it's different use case. LP8720/5 are designed for system PMU, 
so some regulators are enabled by default after the device is on. EN pin 
is used for turning on/off the chip. This pin does not control regulator 
outputs directly. It's separate functional block in the silicon.


On the other hand, 'ena_gpio' is used for each regulator control itself.
For example, WM8994 has two LDOs which are controlled by external pins. 
LDOs are enabled/disabled through LDO1ENA and LDO2ENA pins. In this 
case, 'ena_gpio' is used.


http://www.cirrus.com/en/pubs/proDatasheet/WM8994_v4.4.pdf
(please refer to page 224 and 225)

Best regards,
Milo
--
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: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

[Tomi Valkeinen]

On 25/12/15 15:29, Ivaylo Dimitrov wrote:
> 
> Hi Tomi,
> 
> On 13.01.2014 12:20, Tomi Valkeinen wrote:
>> On 2014-01-11 11:39, Ivaylo Dimitrov wrote:
>>
>>> The patch does not apply cleanly on top of rc7, however I applied it by
>>> hand. So far it seems it fixes the issue brought by
>>> c37dd677988ca50bc8bc60ab5ab053720583c168, though I didn't test if
>>> mutex_lock/mutex_unlock are complementary in every code path (at least
>>> not explicitly, I guess maemo is doing it for us anyway :) ).
>>
>> Ok, thanks.
>>
>>> So, shall I send a patch incorporating your code changes, or you will do
>>> it?
>>
>> I can handle it.
>>
>>   Tomi
>>
>>
> 
> I still don't see those fixes in mainline, shall I send a patch?

Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.

 Tomi



signature.asc
Description: OpenPGP digital signature