from:"Jean\-Michel Hautbois"

[PATCH v4] media: spi: Add support for LMH0395

2014-09-10 Thread Jean-Michel Hautbois

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

LMH0395 enables the use of up to two outputs.
These can be configured using DT.

Controls should be accessible from userspace too.
This will have to be done later.

v2: Add DT support
v3: Change the bit set/clear in output_type as disabled means 'set the bit'
v4: Clearer description of endpoints usage in Doc, and some init changes.
Add a dependency on OF and don't test CONFIG_OF anymore.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  48 +++
 MAINTAINERS|   6 +
 drivers/media/spi/Kconfig  |  14 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 354 +
 5 files changed, 423 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..7cc0026
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,48 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port LMH0395
+
+  SDI input0
+  SDI output   1,2
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = ti,lmh0395;
+   reg = 1;
+   spi-max-frequency = 2000;
+   ports {
+   port@0 {
+   reg = 0;
+   sdi0_in: endpoint {};
+   };
+   port@1 {
+   reg = 1;
+   sdi0_out0: endpoint {};
+   };
+   port@2 {
+   reg = 2;
+   /* endpoint not specified, disable output */
+   };
+   };
+   };
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S:   Maintained
 F: sound/soc/codecs/lm49453*
 F: sound/soc/codecs/isabelle*
 
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
 TI LP855x BACKLIGHT DRIVER
 M: Milo Kim milo@ti.com
 S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..bcb1ab1
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate LMH0395 equalizer
+   depends on VIDEO_V4L2  SPI  MEDIA_CONTROLLER  OF
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..3eca0df
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,354 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * 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

Re: PFUZE100 regulator not going off when PWRON is 0

2014-09-09 Thread Jean-Michel Hautbois

2014-09-09 4:41 GMT+02:00 Robin Gong :
> Thanks for Mark's forward.
>
> Hi Jean-Michel,
>   Yes, SWxOMODE can be set as 1 to active sleep mode if PWRON turn-off event
> occurs. And the voltage of sleep mode can be set in other register SWxOFF. But
> by default, SWxOMODE is 0 which means all SW will be turned off while PWRON go
> form 1 to 0. For your issue, I hope you check the hardware design, and measure
> PWRON pin to see whether it has been pulled low once your push reset key.

Thank you both, we found an electrical issue which made it not going down to 0V.
Regards,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] media: spi: Add support for LMH0395

2014-09-09 Thread Jean-Michel Hautbois

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

LMH0395 enables the use of up to two outputs.
These can be configured using DT.

Controls should be accessible from userspace too.
This will have to be done later.

Signed-off-by: Jean-Michel Hautbois 
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  44 +++
 MAINTAINERS|   6 +
 drivers/media/spi/Kconfig  |  14 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 360 +
 5 files changed, 425 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port LMH0395
+
+  SDI input0
+  SDI output   1,2
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = "ti,lmh0395";
+   reg = <1>;
+   spi-max-frequency = <2000>;
+   ports {
+   port@0 {
+   reg = <0>;
+   sdi0_in: endpoint {};
+   };
+   port@1 {
+   reg=<1>;
+   sdi0_out0: endpoint {};
+   };
+   };
+   };
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S:   Maintained
 F: sound/soc/codecs/lm49453*
 F: sound/soc/codecs/isabelle*
 
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
 TI LP855x BACKLIGHT DRIVER
 M: Milo Kim 
 S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate "LMH0395 equalizer"
+   depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..fe5c5f8
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,360 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "d

[PATCH] mmc: Add delay between CMD6 and CMD13 for Sandisk eMMC cards

2014-09-09 Thread Jean-Michel Hautbois

Tested on a i.MX6 board, with Sandisk SDIN5D1-2G.
Without this patch, I/O errors occur.
This eMMC seems to have a different Manufacturer ID as it reads 0x45
and not 0x2 as specified in datasheet.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/mmc/core/mmc_ops.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index f51b5ba..91babaa 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -458,6 +458,15 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, 
u8 value,
if (!use_busy_signal)
return 0;
 
+   /* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
+* before sending CMD13 after CMD6
+* On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in datasheet
+*/
+   if (card->cid.manfid == CID_MANFID_SANDISK ||
+   card->cid.manfid == 0x45) {
+   msleep(1);
+   }
+
/*
 * CRC errors shall only be ignored in cases were CMD13 is used to poll
 * to detect busy completion.
-- 
2.0.4

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

[PATCH v2] media: spi: Add support for LMH0395

2014-09-09 Thread Jean-Michel Hautbois

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

LMH0395 enables the use of up to two outputs.
These can be configured using DT.

Controls should be accessible from userspace too...

Signed-off-by: Jean-Michel Hautbois 
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  44 +++
 MAINTAINERS|   6 +
 drivers/media/spi/Kconfig  |  14 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 355 +
 5 files changed, 420 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port LMH0395
+
+  SDI input0
+  SDI output   1,2
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = "ti,lmh0395";
+   reg = <1>;
+   spi-max-frequency = <2000>;
+   ports {
+   port@0 {
+   reg = <0>;
+   sdi0_in: endpoint {};
+   };
+   port@1 {
+   reg=<1>;
+   sdi0_out0: endpoint {};
+   };
+   };
+   };
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S:   Maintained
 F: sound/soc/codecs/lm49453*
 F: sound/soc/codecs/isabelle*
 
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
 TI LP855x BACKLIGHT DRIVER
 M: Milo Kim 
 S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate "LMH0395 equalizer"
+   depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..ecf8f83
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,355 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-1)");
+
+#define

[PATCH v2] media: spi: Add support for LMH0395

2014-09-09 Thread Jean-Michel Hautbois

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

LMH0395 enables the use of up to two outputs.
These can be configured using DT.

Controls should be accessible from userspace too...

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  44 +++
 MAINTAINERS|   6 +
 drivers/media/spi/Kconfig  |  14 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 355 +
 5 files changed, 420 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port LMH0395
+
+  SDI input0
+  SDI output   1,2
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = ti,lmh0395;
+   reg = 1;
+   spi-max-frequency = 2000;
+   ports {
+   port@0 {
+   reg = 0;
+   sdi0_in: endpoint {};
+   };
+   port@1 {
+   reg=1;
+   sdi0_out0: endpoint {};
+   };
+   };
+   };
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S:   Maintained
 F: sound/soc/codecs/lm49453*
 F: sound/soc/codecs/isabelle*
 
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
 TI LP855x BACKLIGHT DRIVER
 M: Milo Kim milo@ti.com
 S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate LMH0395 equalizer
+   depends on VIDEO_V4L2  SPI  MEDIA_CONTROLLER
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..ecf8f83
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,355 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * 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/ioctl.h
+#include linux/module.h
+#include linux/of.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/spi/spi.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2

[PATCH] mmc: Add delay between CMD6 and CMD13 for Sandisk eMMC cards

2014-09-09 Thread Jean-Michel Hautbois

Tested on a i.MX6 board, with Sandisk SDIN5D1-2G.
Without this patch, I/O errors occur.
This eMMC seems to have a different Manufacturer ID as it reads 0x45
and not 0x2 as specified in datasheet.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/mmc/core/mmc_ops.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index f51b5ba..91babaa 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -458,6 +458,15 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, 
u8 value,
if (!use_busy_signal)
return 0;
 
+   /* WORKAROUND: for Sandisk eMMC cards, it might need certain delay
+* before sending CMD13 after CMD6
+* On SDIN5D1-2G MANFID is 0x45 and not 0x2 as specified in datasheet
+*/
+   if (card-cid.manfid == CID_MANFID_SANDISK ||
+   card-cid.manfid == 0x45) {
+   msleep(1);
+   }
+
/*
 * CRC errors shall only be ignored in cases were CMD13 is used to poll
 * to detect busy completion.
-- 
2.0.4

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

[PATCH v3] media: spi: Add support for LMH0395

2014-09-09 Thread Jean-Michel Hautbois

This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.

LMH0395 enables the use of up to two outputs.
These can be configured using DT.

Controls should be accessible from userspace too.
This will have to be done later.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 .../devicetree/bindings/media/spi/lmh0395.txt  |  44 +++
 MAINTAINERS|   6 +
 drivers/media/spi/Kconfig  |  14 +
 drivers/media/spi/Makefile |   1 +
 drivers/media/spi/lmh0395.c| 360 +
 5 files changed, 425 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
 create mode 100644 drivers/media/spi/Kconfig
 create mode 100644 drivers/media/spi/Makefile
 create mode 100644 drivers/media/spi/lmh0395.c

diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt 
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97 
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI 
standards.
+
+Required Properties :
+- compatible: Must be ti,lmh0395
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port LMH0395
+
+  SDI input0
+  SDI output   1,2
+
+Example:
+
+ecspi@0201 {
+   ...
+   ...
+
+   lmh0395@1 {
+   compatible = ti,lmh0395;
+   reg = 1;
+   spi-max-frequency = 2000;
+   ports {
+   port@0 {
+   reg = 0;
+   sdi0_in: endpoint {};
+   };
+   port@1 {
+   reg=1;
+   sdi0_out0: endpoint {};
+   };
+   };
+   };
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S:   Maintained
 F: sound/soc/codecs/lm49453*
 F: sound/soc/codecs/isabelle*
 
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
 TI LP855x BACKLIGHT DRIVER
 M: Milo Kim milo@ti.com
 S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+   tristate LMH0395 equalizer
+   depends on VIDEO_V4L2  SPI  MEDIA_CONTROLLER
+   ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..fe5c5f8
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,360 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014  Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * 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/ioctl.h
+#include linux/module.h
+#include linux/of.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/spi/spi.h
+#include linux/videodev2.h
+#include media/v4l2

Re: PFUZE100 regulator not going off when PWRON is 0

2014-09-09 Thread Jean-Michel Hautbois

2014-09-09 4:41 GMT+02:00 Robin Gong b38...@freescale.com:
 Thanks for Mark's forward.

 Hi Jean-Michel,
   Yes, SWxOMODE can be set as 1 to active sleep mode if PWRON turn-off event
 occurs. And the voltage of sleep mode can be set in other register SWxOFF. But
 by default, SWxOMODE is 0 which means all SW will be turned off while PWRON go
 form 1 to 0. For your issue, I hope you check the hardware design, and measure
 PWRON pin to see whether it has been pulled low once your push reset key.

Thank you both, we found an electrical issue which made it not going down to 0V.
Regards,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] adv7604: Add support for i2c_new_secondary_device

2014-09-05 Thread Jean-Michel Hautbois

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.

If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.

Signed-off-by: Jean-Michel Hautbois 
---
 .../devicetree/bindings/media/i2c/adv7604.txt  | 17 ++-
 drivers/media/i2c/adv7604.c| 53 ++
 2 files changed, 48 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,8 +10,12 @@ Required Properties:
 
   - compatible: Must contain one of the following
 - "adi,adv7611" for the ADV7611
+- "adi,adv7604" for the ADV7604
 
-  - reg: I2C slave address
+  - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
 
   - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
 detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -32,6 +36,12 @@ The digital output port node must contain at least one 
endpoint.
 Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+  - reg-names : Names of maps with programmable addresses.
+   It can contain any map needing another address than default one.
+   Possible maps names are :
+ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe", "rep",
+   "edid", "hdmi", "test", "cp", "vdp"
+ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
 
 Optional Endpoint Properties:
 
@@ -50,7 +60,10 @@ Example:
 
hdmi_receiver@4c {
compatible = "adi,adv7611";
-   reg = <0x4c>;
+   /* edid page will be accessible @ 0x66 on i2c bus */
+   /* other maps keep their default addresses */
+   reg = <0x4c 0x66>;
+   reg-names = "main", "edid";
 
reset-gpios = < 0 GPIO_ACTIVE_LOW>;
hpd-gpios = < 2 GPIO_ACTIVE_HIGH>;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d4fa213..8336c02 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,22 @@ static const struct adv7604_video_standards 
adv7604_prim_mode_hdmi_gr[] = {
{ },
 };
 
+static const char const *adv7604_secondary_names[] = {
+   [ADV7604_PAGE_IO] = "main",
+   [ADV7604_PAGE_AVLINK] = "avlink",
+   [ADV7604_PAGE_CEC] = "cec",
+   [ADV7604_PAGE_INFOFRAME] = "infoframe",
+   [ADV7604_PAGE_ESDP] = "esdp",
+   [ADV7604_PAGE_DPP] = "dpp",
+   [ADV7604_PAGE_AFE] = "afe",
+   [ADV7604_PAGE_REP] = "rep",
+   [ADV7604_PAGE_EDID] = "edid",
+   [ADV7604_PAGE_HDMI] = "hdmi",
+   [ADV7604_PAGE_TEST] = "test",
+   [ADV7604_PAGE_CP] = "cp",
+   [ADV7604_PAGE_VDP] = "vdp"
+};
+
 /* --- */
 
 static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2544,25 @@ static void adv7604_unregister_clients(struct 
adv7604_state *state)
 }
 
 static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
-   u8 addr, u8 io_reg)
+   unsigned int i)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   struct adv7604_platform_data *pdata = client->dev.platform_data;
+   unsigned int io_reg = 0xf2 + i;
+   unsigned int default_addr = io_read(sd, io_reg) >> 1;
+   struct i2c_client *new_client;
+
+   if (pdata && pdata->i2c_addresses[i])
+   new_client = i2c_new_dummy(client->adapter,
+   pdata->i2c_addresses[i]);
+   else
+   new_client = i2c_new_secondary_device(client,
+   adv7604_secondary_names[i], default_addr);
 
-   if (addr)
-   io_write(sd, io_reg, addr << 1);
-   return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+   if (new_client)
+   io_write(sd, io_reg, new_client->addr &l

[PATCH 2/2] adv7604: Add DT parsing support

2014-09-05 Thread Jean-Michel Hautbois

This allows specifying I²C secodnary addresses different from default ones.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/media/i2c/adv7604.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 8336c02..75613a4 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2705,6 +2705,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
 
 static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = "adi,adv7611", .data = _chip_info[ADV7611] },
+   { .compatible = "adi,adv7604", .data = _chip_info[ADV7604] },
{ }
 };
 MODULE_DEVICE_TABLE(of, adv7604_of_id);
-- 
2.0.4

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

[PATCH] i2c: Add generic support passing secondary devices addresses

2014-09-05 Thread Jean-Michel Hautbois

Some I2C devices have multiple addresses assigned, for example each address
corresponding to a different internal register map page of the device.
So far drivers which need support for this have handled this with a driver
specific and non-generic implementation, e.g. passing the additional address
via platform data.

This patch provides a new helper function called i2c_new_secondary_device()
which is intended to provide a generic way to get the secondary address
as well as instantiate a struct i2c_client for the secondary address.

The function expects a pointer to the primary i2c_client, a name
for the secondary address and an optional default address. The name is used
as a handle to specify which secondary address to get.

The default address is used as a fallback in case no secondary address
was explicitly specified. In case no secondary address and no default
address were specified the function returns NULL.

For now the function only supports look-up of the secondary address
from devicetree, but it can be extended in the future
to for example support board files and/or ACPI.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/i2c/i2c-core.c | 40 
 include/linux/i2c.h|  8 
 2 files changed, 48 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..ef31d6f 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -798,6 +798,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter 
*adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
+/**
+ * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * @client: Handle to the primary client
+ * @name: Handle to specify which secondary address to get
+ * @default_addr: Used as a fallback if no secondary address was specified
+ * Context: can sleep
+ *
+ * This returns an I2C client bound to the "dummy" driver based on DT parsing.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+   const char *name,
+   u16 default_addr)
+{
+   int i;
+   u32 addr;
+   struct device_node *np;
+
+   np = client->dev.of_node;
+
+   if (np) {
+   i = of_property_match_string(np, "reg-names", name);
+   if (i >= 0)
+   of_property_read_u32_index(np, "reg", i, );
+   else if (default_addr != 0)
+   addr = default_addr;
+   else
+   addr = NULL;
+   } else {
+   addr = default_addr;
+   }
+
+   dev_dbg(>adapter->dev, "Address for %s : 0x%x\n", name, addr);
+   return i2c_new_dummy(client->adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
 /* - */
 
 /* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a95efeb..0f190e6 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,14 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *, 
unsigned short addr);
 extern struct i2c_client *
 i2c_new_dummy(struct i2c_adapter *adap, u16 address);
 
+/* Helper function providing a generic way to get the secondary address
+ * as well as a client handle to this extra address.
+ */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+   const char *name,
+   u32 default_addr);
+
 extern void i2c_unregister_device(struct i2c_client *);
 #endif /* I2C */
 
-- 
2.0.4

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

[PATCH] i2c: Add generic support passing secondary devices addresses

2014-09-05 Thread Jean-Michel Hautbois

Some I2C devices have multiple addresses assigned, for example each address
corresponding to a different internal register map page of the device.
So far drivers which need support for this have handled this with a driver
specific and non-generic implementation, e.g. passing the additional address
via platform data.

This patch provides a new helper function called i2c_new_secondary_device()
which is intended to provide a generic way to get the secondary address
as well as instantiate a struct i2c_client for the secondary address.

The function expects a pointer to the primary i2c_client, a name
for the secondary address and an optional default address. The name is used
as a handle to specify which secondary address to get.

The default address is used as a fallback in case no secondary address
was explicitly specified. In case no secondary address and no default
address were specified the function returns NULL.

For now the function only supports look-up of the secondary address
from devicetree, but it can be extended in the future
to for example support board files and/or ACPI.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/i2c/i2c-core.c | 40 
 include/linux/i2c.h|  8 
 2 files changed, 48 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..ef31d6f 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -798,6 +798,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter 
*adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
+/**
+ * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * @client: Handle to the primary client
+ * @name: Handle to specify which secondary address to get
+ * @default_addr: Used as a fallback if no secondary address was specified
+ * Context: can sleep
+ *
+ * This returns an I2C client bound to the dummy driver based on DT parsing.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+   const char *name,
+   u16 default_addr)
+{
+   int i;
+   u32 addr;
+   struct device_node *np;
+
+   np = client-dev.of_node;
+
+   if (np) {
+   i = of_property_match_string(np, reg-names, name);
+   if (i = 0)
+   of_property_read_u32_index(np, reg, i, addr);
+   else if (default_addr != 0)
+   addr = default_addr;
+   else
+   addr = NULL;
+   } else {
+   addr = default_addr;
+   }
+
+   dev_dbg(client-adapter-dev, Address for %s : 0x%x\n, name, addr);
+   return i2c_new_dummy(client-adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
 /* - */
 
 /* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a95efeb..0f190e6 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,14 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *, 
unsigned short addr);
 extern struct i2c_client *
 i2c_new_dummy(struct i2c_adapter *adap, u16 address);
 
+/* Helper function providing a generic way to get the secondary address
+ * as well as a client handle to this extra address.
+ */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+   const char *name,
+   u32 default_addr);
+
 extern void i2c_unregister_device(struct i2c_client *);
 #endif /* I2C */
 
-- 
2.0.4

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

[PATCH 2/2] adv7604: Add DT parsing support

2014-09-05 Thread Jean-Michel Hautbois

This allows specifying I²C secodnary addresses different from default ones.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/media/i2c/adv7604.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 8336c02..75613a4 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2705,6 +2705,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
 
 static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+   { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
{ }
 };
 MODULE_DEVICE_TABLE(of, adv7604_of_id);
-- 
2.0.4

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

[PATCH 1/2] adv7604: Add support for i2c_new_secondary_device

2014-09-05 Thread Jean-Michel Hautbois

The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.

If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 .../devicetree/bindings/media/i2c/adv7604.txt  | 17 ++-
 drivers/media/i2c/adv7604.c| 53 ++
 2 files changed, 48 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt 
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,8 +10,12 @@ Required Properties:
 
   - compatible: Must contain one of the following
 - adi,adv7611 for the ADV7611
+- adi,adv7604 for the ADV7604
 
-  - reg: I2C slave address
+  - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
 
   - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
 detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -32,6 +36,12 @@ The digital output port node must contain at least one 
endpoint.
 Optional Properties:
 
   - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+  - reg-names : Names of maps with programmable addresses.
+   It can contain any map needing another address than default one.
+   Possible maps names are :
+ADV7604 : main, avlink, cec, infoframe, esdp, dpp, afe, rep,
+   edid, hdmi, test, cp, vdp
+ADV7611 : main, cec, infoframe, afe, rep, edid, hdmi, cp
 
 Optional Endpoint Properties:
 
@@ -50,7 +60,10 @@ Example:
 
hdmi_receiver@4c {
compatible = adi,adv7611;
-   reg = 0x4c;
+   /* edid page will be accessible @ 0x66 on i2c bus */
+   /* other maps keep their default addresses */
+   reg = 0x4c 0x66;
+   reg-names = main, edid;
 
reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d4fa213..8336c02 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,22 @@ static const struct adv7604_video_standards 
adv7604_prim_mode_hdmi_gr[] = {
{ },
 };
 
+static const char const *adv7604_secondary_names[] = {
+   [ADV7604_PAGE_IO] = main,
+   [ADV7604_PAGE_AVLINK] = avlink,
+   [ADV7604_PAGE_CEC] = cec,
+   [ADV7604_PAGE_INFOFRAME] = infoframe,
+   [ADV7604_PAGE_ESDP] = esdp,
+   [ADV7604_PAGE_DPP] = dpp,
+   [ADV7604_PAGE_AFE] = afe,
+   [ADV7604_PAGE_REP] = rep,
+   [ADV7604_PAGE_EDID] = edid,
+   [ADV7604_PAGE_HDMI] = hdmi,
+   [ADV7604_PAGE_TEST] = test,
+   [ADV7604_PAGE_CP] = cp,
+   [ADV7604_PAGE_VDP] = vdp
+};
+
 /* --- */
 
 static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2544,25 @@ static void adv7604_unregister_clients(struct 
adv7604_state *state)
 }
 
 static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
-   u8 addr, u8 io_reg)
+   unsigned int i)
 {
struct i2c_client *client = v4l2_get_subdevdata(sd);
+   struct adv7604_platform_data *pdata = client-dev.platform_data;
+   unsigned int io_reg = 0xf2 + i;
+   unsigned int default_addr = io_read(sd, io_reg)  1;
+   struct i2c_client *new_client;
+
+   if (pdata  pdata-i2c_addresses[i])
+   new_client = i2c_new_dummy(client-adapter,
+   pdata-i2c_addresses[i]);
+   else
+   new_client = i2c_new_secondary_device(client,
+   adv7604_secondary_names[i], default_addr);
 
-   if (addr)
-   io_write(sd, io_reg, addr  1);
-   return i2c_new_dummy(client-adapter, io_read(sd, io_reg)  1);
+   if (new_client)
+   io_write(sd, io_reg, new_client-addr  1);
+
+   return new_client;
 }
 
 static const struct adv7604_reg_seq adv7604_recommended_settings_afe[] = {
@@ -2717,20 +2745,6 @@ static int adv7604_parse_dt(struct adv7604_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state-pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED;
 
-   /* Use the default I2C addresses. */
-   state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
-   state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40;
-   state

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-04 Thread Jean-Michel Hautbois

2014-09-04 11:37 GMT+02:00 Jean-Michel Hautbois
:
> Hi Ulf,
>
>> I am not sure adding a DT binding for non access to rpmb would be
>> needed. At least until we heard of a similar case as Adrian describes
>> but for rpmb.
>>
>> BTW, I just posted a patch which disabled partition scan of the boot
>> area, what to you think about that?
>> http://marc.info/?l=linux-mmc=140973496402028=2
>>
>> Finally I am also wondering whether we could and thus should, handle
>> these situations entirely without using a host cap. In principle what
>> we need is a more sophisticated error handling when the switch errors
>> occurs, while trying to switch to the boot area/rpmb partitions. Could
>> you maybe investigate that option, before we decide to add a new DT
>> binding?
>
> According to me and what Hsin-Hsiang Tseng wrote, it seems that we
> should be able to have access to boot partitions if we want to give a
> possibility of writing u-boot in one (or both) of them. This is the
> way the i.MX6 will boot on a eMMC if I read the reference manual
> correctly, but I didn't tested it yet.
> But there is no need to scan those partitions at boot, as there will
> probably never be a partition table inside, as you said.
> All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
> and a way to tell which one is used as default boot partition.
>
> This is my point of view, but I didn't read JESD84-A441 so I don't
> know if this is the good way.
>
> Regards,
> JM

BTW, here is an interesting commit from Freescale tree :
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.0_ga=28774b788ae0de5d88045dd60cac3656c305821d

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-04 Thread Jean-Michel Hautbois

Hi Ulf,

> I am not sure adding a DT binding for non access to rpmb would be
> needed. At least until we heard of a similar case as Adrian describes
> but for rpmb.
>
> BTW, I just posted a patch which disabled partition scan of the boot
> area, what to you think about that?
> http://marc.info/?l=linux-mmc=140973496402028=2
>
> Finally I am also wondering whether we could and thus should, handle
> these situations entirely without using a host cap. In principle what
> we need is a more sophisticated error handling when the switch errors
> occurs, while trying to switch to the boot area/rpmb partitions. Could
> you maybe investigate that option, before we decide to add a new DT
> binding?

According to me and what Hsin-Hsiang Tseng wrote, it seems that we
should be able to have access to boot partitions if we want to give a
possibility of writing u-boot in one (or both) of them. This is the
way the i.MX6 will boot on a eMMC if I read the reference manual
correctly, but I didn't tested it yet.
But there is no need to scan those partitions at boot, as there will
probably never be a partition table inside, as you said.
All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
and a way to tell which one is used as default boot partition.

This is my point of view, but I didn't read JESD84-A441 so I don't
know if this is the good way.

Regards,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-04 Thread Jean-Michel Hautbois

Hi Ulf,

 I am not sure adding a DT binding for non access to rpmb would be
 needed. At least until we heard of a similar case as Adrian describes
 but for rpmb.

 BTW, I just posted a patch which disabled partition scan of the boot
 area, what to you think about that?
 http://marc.info/?l=linux-mmcm=140973496402028w=2

 Finally I am also wondering whether we could and thus should, handle
 these situations entirely without using a host cap. In principle what
 we need is a more sophisticated error handling when the switch errors
 occurs, while trying to switch to the boot area/rpmb partitions. Could
 you maybe investigate that option, before we decide to add a new DT
 binding?

According to me and what Hsin-Hsiang Tseng wrote, it seems that we
should be able to have access to boot partitions if we want to give a
possibility of writing u-boot in one (or both) of them. This is the
way the i.MX6 will boot on a eMMC if I read the reference manual
correctly, but I didn't tested it yet.
But there is no need to scan those partitions at boot, as there will
probably never be a partition table inside, as you said.
All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
and a way to tell which one is used as default boot partition.

This is my point of view, but I didn't read JESD84-A441 so I don't
know if this is the good way.

Regards,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-04 Thread Jean-Michel Hautbois

2014-09-04 11:37 GMT+02:00 Jean-Michel Hautbois
jean-michel.hautb...@vodalys.com:
 Hi Ulf,

 I am not sure adding a DT binding for non access to rpmb would be
 needed. At least until we heard of a similar case as Adrian describes
 but for rpmb.

 BTW, I just posted a patch which disabled partition scan of the boot
 area, what to you think about that?
 http://marc.info/?l=linux-mmcm=140973496402028w=2

 Finally I am also wondering whether we could and thus should, handle
 these situations entirely without using a host cap. In principle what
 we need is a more sophisticated error handling when the switch errors
 occurs, while trying to switch to the boot area/rpmb partitions. Could
 you maybe investigate that option, before we decide to add a new DT
 binding?

 According to me and what Hsin-Hsiang Tseng wrote, it seems that we
 should be able to have access to boot partitions if we want to give a
 possibility of writing u-boot in one (or both) of them. This is the
 way the i.MX6 will boot on a eMMC if I read the reference manual
 correctly, but I didn't tested it yet.
 But there is no need to scan those partitions at boot, as there will
 probably never be a partition table inside, as you said.
 All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
 and a way to tell which one is used as default boot partition.

 This is my point of view, but I didn't read JESD84-A441 so I don't
 know if this is the good way.

 Regards,
 JM

BTW, here is an interesting commit from Freescale tree :
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.0_gaid=28774b788ae0de5d88045dd60cac3656c305821d

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-03 Thread Jean-Michel Hautbois

2014-09-03 11:09 GMT+02:00 Ulf Hansson :
> On 3 September 2014 11:02, Adrian Hunter  wrote:
>> On 09/03/2014 11:30 AM, Ulf Hansson wrote:
>>> On 2 September 2014 17:49, Jean-Michel Hautbois
>>>  wrote:
>>>> This property is useful when we don't want to access boot partitions on 
>>>> eMMC
>>>>
>>>> Signed-off-by: Jean-Michel Hautbois 
>>>> ---
>>>>  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
>>>>  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
>>>>  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
>>>>  3 files changed, 10 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
>>>> b/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> index 431716e..59cc854 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
>>>> @@ -40,6 +40,7 @@ Optional properties:
>>>>  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
>>>>  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
>>>>  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
>>>> +- no-boot-part : when preset, tells to access boot partitions
>>>>
>>>>  *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
>>>> controllers line
>>>>  polarity properties, we have to fix the meaning of the "normal" and 
>>>> "inverted"
>>>> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
>>>> b/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> index ccec0e3..439e663 100644
>>>> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
>>>> @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
>>>> if (of_property_read_u32(np, "fsl,delay-line", 
>>>> >delay_line))
>>>> boarddata->delay_line = 0;
>>>>
>>>> +   if (of_find_property(np, "no-boot-part", NULL))
>>>> +   boarddata->access_boot_part = false;
>>>> +   else
>>>> +   boarddata->access_boot_part = true;
>>>> +
>>>> return 0;
>>>>  }
>>>>  #else
>>>> @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
>>>> platform_device *pdev)
>>>> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>>> }
>>>>
>>>> +   if (!boarddata->access_boot_part)
>>>> +   host->mmc->caps2 |= MMC_CAP2_BOOTPART_NOACC;
>>>> +
>>>
>>> Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
>>> Does it describe the hardware in some form?
>>>
>>> Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
>>> at all. If there are cards that don't supports the BOOT area,
>>> shouldn't we have a card quirk for it instead of a host cap? Maybe
>>> Adrian Hunter, how originally wrote the patch for adding
>>> MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
>>> it!?
>>
>> It was added because platform firmware was able to prevent access to the
>> boot partitions (for security I think), so attempts to access them would
>> fail messily.  It was not related to any specific card.
>
> Adrian, appreciate your clarification. After all it seems like adding
> a DT binding for it should be appropriate.
>
> Kind regards
> Uffe

Thanks Adrian :).
Well, there is boot partitions and rpmb partition, and maybe should we
have a binding to prevent access to both of them ?
Something else came to my mind, when you want to boot on eMMC, do you
need to write u-boot in boot partitions or is it written at the
logical adress 0 which is what fdisk uses as start ?
Because, if this is not usuable but just scanned I can't see why we
bother doing it... ?

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PFUZE100 regulator not going off when PWRON is 0

2014-09-03 Thread Jean-Michel Hautbois

Hi,

I have a custom i.MX6 based board, but PMIC part is exactly the same
as the Freescale SabreSD board.
I have a reset button, which makes the PWRON signal on PFUZE100 go from 1 to 0.
I thought this would reset the chip, and thus all voltages would go to
0, but this is not the case. It seems that SWxOMODE registers are
involved in this process, accorgind to the datasheet, but I don't
think this is implemented right now.

I also removed regulator-always-on for my SW2 pin in order to get it
off, but this has no effect.

Thanks for your advices,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PFUZE100 regulator not going off when PWRON is 0

2014-09-03 Thread Jean-Michel Hautbois

Hi,

I have a custom i.MX6 based board, but PMIC part is exactly the same
as the Freescale SabreSD board.
I have a reset button, which makes the PWRON signal on PFUZE100 go from 1 to 0.
I thought this would reset the chip, and thus all voltages would go to
0, but this is not the case. It seems that SWxOMODE registers are
involved in this process, accorgind to the datasheet, but I don't
think this is implemented right now.

I also removed regulator-always-on for my SW2 pin in order to get it
off, but this has no effect.

Thanks for your advices,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-03 Thread Jean-Michel Hautbois

2014-09-03 11:09 GMT+02:00 Ulf Hansson ulf.hans...@linaro.org:
 On 3 September 2014 11:02, Adrian Hunter adrian.hun...@intel.com wrote:
 On 09/03/2014 11:30 AM, Ulf Hansson wrote:
 On 2 September 2014 17:49, Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com wrote:
 This property is useful when we don't want to access boot partitions on 
 eMMC

 Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
 ---
  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
  3 files changed, 10 insertions(+)

 diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
 b/Documentation/devicetree/bindings/mmc/mmc.txt
 index 431716e..59cc854 100644
 --- a/Documentation/devicetree/bindings/mmc/mmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
 @@ -40,6 +40,7 @@ Optional properties:
  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 +- no-boot-part : when preset, tells to access boot partitions

  *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
 controllers line
  polarity properties, we have to fix the meaning of the normal and 
 inverted
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 index ccec0e3..439e663 100644
 --- a/drivers/mmc/host/sdhci-esdhc-imx.c
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 if (of_property_read_u32(np, fsl,delay-line, 
 boarddata-delay_line))
 boarddata-delay_line = 0;

 +   if (of_find_property(np, no-boot-part, NULL))
 +   boarddata-access_boot_part = false;
 +   else
 +   boarddata-access_boot_part = true;
 +
 return 0;
  }
  #else
 @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
 platform_device *pdev)
 host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
 }

 +   if (!boarddata-access_boot_part)
 +   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
 +

 Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
 Does it describe the hardware in some form?

 Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
 at all. If there are cards that don't supports the BOOT area,
 shouldn't we have a card quirk for it instead of a host cap? Maybe
 Adrian Hunter, how originally wrote the patch for adding
 MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
 it!?

 It was added because platform firmware was able to prevent access to the
 boot partitions (for security I think), so attempts to access them would
 fail messily.  It was not related to any specific card.

 Adrian, appreciate your clarification. After all it seems like adding
 a DT binding for it should be appropriate.

 Kind regards
 Uffe

Thanks Adrian :).
Well, there is boot partitions and rpmb partition, and maybe should we
have a binding to prevent access to both of them ?
Something else came to my mind, when you want to boot on eMMC, do you
need to write u-boot in boot partitions or is it written at the
logical adress 0 which is what fdisk uses as start ?
Because, if this is not usuable but just scanned I can't see why we
bother doing it... ?

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-02 Thread Jean-Michel Hautbois

This property is useful when we don't want to access boot partitions on eMMC

Signed-off-by: Jean-Michel Hautbois 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
 drivers/mmc/host/sdhci-esdhc-imx.c| 8 
 include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
 3 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 431716e..59cc854 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -40,6 +40,7 @@ Optional properties:
 - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
 - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
 - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
+- no-boot-part : when preset, tells to access boot partitions

 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index ccec0e3..439e663 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
if (of_property_read_u32(np, "fsl,delay-line", >delay_line))
boarddata->delay_line = 0;

+   if (of_find_property(np, "no-boot-part", NULL))
+   boarddata->access_boot_part = false;
+   else
+   boarddata->access_boot_part = true;
+
return 0;
 }
 #else
@@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
*pdev)
host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
}

+   if (!boarddata->access_boot_part)
+   host->mmc->caps2 |= MMC_CAP2_BOOTPART_NOACC;
+
err = sdhci_add_host(host);
if (err)
goto disable_clk;
diff --git a/include/linux/platform_data/mmc-esdhc-imx.h 
b/include/linux/platform_data/mmc-esdhc-imx.h
index 75f70f6..a34ee9e 100644
--- a/include/linux/platform_data/mmc-esdhc-imx.h
+++ b/include/linux/platform_data/mmc-esdhc-imx.h
@@ -46,5 +46,6 @@ struct esdhc_platform_data {
unsigned int f_max;
bool support_vsel;
unsigned int delay_line;
+   bool access_boot_part;
 };
 #endif /* __ASM_ARCH_IMX_ESDHC_H */

2.0.4

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

[PATCH] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

2014-09-02 Thread Jean-Michel Hautbois

This property is useful when we don't want to access boot partitions on eMMC

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
 drivers/mmc/host/sdhci-esdhc-imx.c| 8 
 include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
 3 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 431716e..59cc854 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -40,6 +40,7 @@ Optional properties:
 - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
 - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
 - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
+- no-boot-part : when preset, tells to access boot partitions

 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the normal and inverted
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
index ccec0e3..439e663 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
if (of_property_read_u32(np, fsl,delay-line, boarddata-delay_line))
boarddata-delay_line = 0;

+   if (of_find_property(np, no-boot-part, NULL))
+   boarddata-access_boot_part = false;
+   else
+   boarddata-access_boot_part = true;
+
return 0;
 }
 #else
@@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct platform_device 
*pdev)
host-quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
}

+   if (!boarddata-access_boot_part)
+   host-mmc-caps2 |= MMC_CAP2_BOOTPART_NOACC;
+
err = sdhci_add_host(host);
if (err)
goto disable_clk;
diff --git a/include/linux/platform_data/mmc-esdhc-imx.h 
b/include/linux/platform_data/mmc-esdhc-imx.h
index 75f70f6..a34ee9e 100644
--- a/include/linux/platform_data/mmc-esdhc-imx.h
+++ b/include/linux/platform_data/mmc-esdhc-imx.h
@@ -46,5 +46,6 @@ struct esdhc_platform_data {
unsigned int f_max;
bool support_vsel;
unsigned int delay_line;
+   bool access_boot_part;
 };
 #endif /* __ASM_ARCH_IMX_ESDHC_H */

2.0.4

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

Re: [PATCH] misc: lattice-ecp3-config: Add missing MODULE_FIRMWARE()

2014-08-08 Thread Jean-Michel Hautbois

2014-08-06 17:37 GMT+02:00 Takashi Iwai :
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/misc/lattice-ecp3-config.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/lattice-ecp3-config.c 
> b/drivers/misc/lattice-ecp3-config.c
> index 7ffdb589841e..643c9eda69dd 100644
> --- a/drivers/misc/lattice-ecp3-config.c
> +++ b/drivers/misc/lattice-ecp3-config.c
> @@ -242,3 +242,4 @@ module_spi_driver(lattice_ecp3_driver);
>  MODULE_AUTHOR("Stefan Roese ");
>  MODULE_DESCRIPTION("Lattice ECP3 FPGA configuration via SPI");
>  MODULE_LICENSE("GPL");
> +MODULE_FIRMWARE(FIRMWARE_NAME);
> --
> 2.0.3
>

It works on my i.MX6 platform.

Tested-by: Jean-Michel Hautbois 

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: lattice-ecp3-config: Add missing MODULE_FIRMWARE()

2014-08-08 Thread Jean-Michel Hautbois

2014-08-06 17:37 GMT+02:00 Takashi Iwai ti...@suse.de:
 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  drivers/misc/lattice-ecp3-config.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/drivers/misc/lattice-ecp3-config.c 
 b/drivers/misc/lattice-ecp3-config.c
 index 7ffdb589841e..643c9eda69dd 100644
 --- a/drivers/misc/lattice-ecp3-config.c
 +++ b/drivers/misc/lattice-ecp3-config.c
 @@ -242,3 +242,4 @@ module_spi_driver(lattice_ecp3_driver);
  MODULE_AUTHOR(Stefan Roese s...@denx.de);
  MODULE_DESCRIPTION(Lattice ECP3 FPGA configuration via SPI);
  MODULE_LICENSE(GPL);
 +MODULE_FIRMWARE(FIRMWARE_NAME);
 --
 2.0.3


It works on my i.MX6 platform.

Tested-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 12:52 GMT+02:00 Takashi Iwai :
> At Wed, 6 Aug 2014 12:50:28 +0200,
> Jean-Michel Hautbois wrote:
>>
>> 2014-08-06 12:21 GMT+02:00 Takashi Iwai :
>> > At Wed, 6 Aug 2014 11:44:14 +0200,
>> > Jean-Michel Hautbois wrote:
>> >>
>> >> 2014-08-06 11:24 GMT+02:00 Takashi Iwai :
>> >> > At Wed, 6 Aug 2014 11:10:27 +0200,
>> >> > Jean-Michel Hautbois wrote:
>> >> >>
>> >> >> 2014-08-05 21:22 GMT+02:00 Shuah Khan :
>> >> >> > On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai  wrote:
>> >> >> >>> Yes, it worked, if the firmware was in the /lib/firmware directory.
>> >> >> >>
>> >> >> >
>> >> >> > ok it works when the firmware is in /lib/firmware. It sounds to me 
>> >> >> > the
>> >> >> > reason load fails when the firmware is under /sys/class/firmware is
>> >> >> > fw_load_from_user_helper() returns -ENOENT when
>> >> >> > CONFIG_FW_LOADER_USER_HELPER is disabled.
>> >> >> >
>> >> >> > It would be nice to see the entire dmesg with debug enabled though.
>> >> >> >
>> >> >> > -- Shuah
>> >> >>
>> >> >> It does not work with the 3.16 kernel even when firmware is in
>> >> >> /lib/firmware, it worked before this patch is applied.
>> >> >
>> >> > Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.
>> >>
>> >> Oh, you are right of course, I am on upstream kernel and I have your
>> >> patch. I don't mean your match is causing the issue though ;-).
>> >
>> > I see.
>> >
>> >> >> Here is what I got in my dmesg :
>> >> >> [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
>> >> >> [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
>> >> >> lattice-ecp3.bit failed with error -2
>> >> >
>> >> > It's -ENOENT.  Are you sure that you really have
>> >> >  /lib/firmware/lattice-ecp3.bit file?
>> >>
>> >> Yes :
>> >> ls -al /lib/firmware/lattice-ecp3.bit
>> >> -rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit
>> >
>> > Then you'd better bisect...
>> > Or, at least, put a debug code to see which file is opened in the loop
>> > in fw_get_filesystem_firmware().
>>
>> Well, when this function is called, my rootfs is not yet mounted (I
>> have a dedicated partition on a SDCard)...
>> So I probably missed a step in order to get /lib/firmware before / is
>> mounted... ?
>
> Yeah, possibly :)  Maybe you did put /lib/firmware/* into initrd in
> the earlier tests?

Nope, it failed and when / was mounted, it was called again and used
the firmware thanks to udev.
This is the CONFIG_FW_LOADER_USER_HELPER config which makes that now, right ?
But how can I have /lib/firmware in my initrd, that is the question I
need to answer now :).

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 12:21 GMT+02:00 Takashi Iwai :
> At Wed, 6 Aug 2014 11:44:14 +0200,
> Jean-Michel Hautbois wrote:
>>
>> 2014-08-06 11:24 GMT+02:00 Takashi Iwai :
>> > At Wed, 6 Aug 2014 11:10:27 +0200,
>> > Jean-Michel Hautbois wrote:
>> >>
>> >> 2014-08-05 21:22 GMT+02:00 Shuah Khan :
>> >> > On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai  wrote:
>> >> >>> Yes, it worked, if the firmware was in the /lib/firmware directory.
>> >> >>
>> >> >
>> >> > ok it works when the firmware is in /lib/firmware. It sounds to me the
>> >> > reason load fails when the firmware is under /sys/class/firmware is
>> >> > fw_load_from_user_helper() returns -ENOENT when
>> >> > CONFIG_FW_LOADER_USER_HELPER is disabled.
>> >> >
>> >> > It would be nice to see the entire dmesg with debug enabled though.
>> >> >
>> >> > -- Shuah
>> >>
>> >> It does not work with the 3.16 kernel even when firmware is in
>> >> /lib/firmware, it worked before this patch is applied.
>> >
>> > Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.
>>
>> Oh, you are right of course, I am on upstream kernel and I have your
>> patch. I don't mean your match is causing the issue though ;-).
>
> I see.
>
>> >> Here is what I got in my dmesg :
>> >> [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
>> >> [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
>> >> lattice-ecp3.bit failed with error -2
>> >
>> > It's -ENOENT.  Are you sure that you really have
>> >  /lib/firmware/lattice-ecp3.bit file?
>>
>> Yes :
>> ls -al /lib/firmware/lattice-ecp3.bit
>> -rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit
>
> Then you'd better bisect...
> Or, at least, put a debug code to see which file is opened in the loop
> in fw_get_filesystem_firmware().

Well, when this function is called, my rootfs is not yet mounted (I
have a dedicated partition on a SDCard)...
So I probably missed a step in order to get /lib/firmware before / is
mounted... ?

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 11:24 GMT+02:00 Takashi Iwai :
> At Wed, 6 Aug 2014 11:10:27 +0200,
> Jean-Michel Hautbois wrote:
>>
>> 2014-08-05 21:22 GMT+02:00 Shuah Khan :
>> > On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai  wrote:
>> >>> Yes, it worked, if the firmware was in the /lib/firmware directory.
>> >>
>> >
>> > ok it works when the firmware is in /lib/firmware. It sounds to me the
>> > reason load fails when the firmware is under /sys/class/firmware is
>> > fw_load_from_user_helper() returns -ENOENT when
>> > CONFIG_FW_LOADER_USER_HELPER is disabled.
>> >
>> > It would be nice to see the entire dmesg with debug enabled though.
>> >
>> > -- Shuah
>>
>> It does not work with the 3.16 kernel even when firmware is in
>> /lib/firmware, it worked before this patch is applied.
>
> Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.

Oh, you are right of course, I am on upstream kernel and I have your
patch. I don't mean your match is causing the issue though ;-).

>> Here is what I got in my dmesg :
>> [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
>> [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
>> lattice-ecp3.bit failed with error -2
>
> It's -ENOENT.  Are you sure that you really have
>  /lib/firmware/lattice-ecp3.bit file?

Yes :
ls -al /lib/firmware/lattice-ecp3.bit
-rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-05 21:22 GMT+02:00 Shuah Khan :
> On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai  wrote:
>>> Yes, it worked, if the firmware was in the /lib/firmware directory.
>>
>
> ok it works when the firmware is in /lib/firmware. It sounds to me the
> reason load fails when the firmware is under /sys/class/firmware is
> fw_load_from_user_helper() returns -ENOENT when
> CONFIG_FW_LOADER_USER_HELPER is disabled.
>
> It would be nice to see the entire dmesg with debug enabled though.
>
> -- Shuah

It does not work with the 3.16 kernel even when firmware is in
/lib/firmware, it worked before this patch is applied.
Here is what I got in my dmesg :
[0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
[0.308029] lattice-ecp3 spi2.3: Direct firmware load for
lattice-ecp3.bit failed with error -2
[0.308078] __fw_free_buf: fw-lattice-ecp3.bit buf=bd81a480 data=
(null) size=0
[0.308094] lattice-ecp3 spi2.3: Cannot load firmware, aborting

If you want specific messages, please tell me.

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-05 21:22 GMT+02:00 Shuah Khan shuahk...@gmail.com:
 On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai ti...@suse.de wrote:
 Yes, it worked, if the firmware was in the /lib/firmware directory.


 ok it works when the firmware is in /lib/firmware. It sounds to me the
 reason load fails when the firmware is under /sys/class/firmware is
 fw_load_from_user_helper() returns -ENOENT when
 CONFIG_FW_LOADER_USER_HELPER is disabled.

 It would be nice to see the entire dmesg with debug enabled though.

 -- Shuah

It does not work with the 3.16 kernel even when firmware is in
/lib/firmware, it worked before this patch is applied.
Here is what I got in my dmesg :
[0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
[0.308029] lattice-ecp3 spi2.3: Direct firmware load for
lattice-ecp3.bit failed with error -2
[0.308078] __fw_free_buf: fw-lattice-ecp3.bit buf=bd81a480 data=
(null) size=0
[0.308094] lattice-ecp3 spi2.3: Cannot load firmware, aborting

If you want specific messages, please tell me.

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 11:24 GMT+02:00 Takashi Iwai ti...@suse.de:
 At Wed, 6 Aug 2014 11:10:27 +0200,
 Jean-Michel Hautbois wrote:

 2014-08-05 21:22 GMT+02:00 Shuah Khan shuahk...@gmail.com:
  On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai ti...@suse.de wrote:
  Yes, it worked, if the firmware was in the /lib/firmware directory.
 
 
  ok it works when the firmware is in /lib/firmware. It sounds to me the
  reason load fails when the firmware is under /sys/class/firmware is
  fw_load_from_user_helper() returns -ENOENT when
  CONFIG_FW_LOADER_USER_HELPER is disabled.
 
  It would be nice to see the entire dmesg with debug enabled though.
 
  -- Shuah

 It does not work with the 3.16 kernel even when firmware is in
 /lib/firmware, it worked before this patch is applied.

 Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.

Oh, you are right of course, I am on upstream kernel and I have your
patch. I don't mean your match is causing the issue though ;-).

 Here is what I got in my dmesg :
 [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
 [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
 lattice-ecp3.bit failed with error -2

 It's -ENOENT.  Are you sure that you really have
  /lib/firmware/lattice-ecp3.bit file?

Yes :
ls -al /lib/firmware/lattice-ecp3.bit
-rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 12:21 GMT+02:00 Takashi Iwai ti...@suse.de:
 At Wed, 6 Aug 2014 11:44:14 +0200,
 Jean-Michel Hautbois wrote:

 2014-08-06 11:24 GMT+02:00 Takashi Iwai ti...@suse.de:
  At Wed, 6 Aug 2014 11:10:27 +0200,
  Jean-Michel Hautbois wrote:
 
  2014-08-05 21:22 GMT+02:00 Shuah Khan shuahk...@gmail.com:
   On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai ti...@suse.de wrote:
   Yes, it worked, if the firmware was in the /lib/firmware directory.
  
  
   ok it works when the firmware is in /lib/firmware. It sounds to me the
   reason load fails when the firmware is under /sys/class/firmware is
   fw_load_from_user_helper() returns -ENOENT when
   CONFIG_FW_LOADER_USER_HELPER is disabled.
  
   It would be nice to see the entire dmesg with debug enabled though.
  
   -- Shuah
 
  It does not work with the 3.16 kernel even when firmware is in
  /lib/firmware, it worked before this patch is applied.
 
  Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.

 Oh, you are right of course, I am on upstream kernel and I have your
 patch. I don't mean your match is causing the issue though ;-).

 I see.

  Here is what I got in my dmesg :
  [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
  [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
  lattice-ecp3.bit failed with error -2
 
  It's -ENOENT.  Are you sure that you really have
   /lib/firmware/lattice-ecp3.bit file?

 Yes :
 ls -al /lib/firmware/lattice-ecp3.bit
 -rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit

 Then you'd better bisect...
 Or, at least, put a debug code to see which file is opened in the loop
 in fw_get_filesystem_firmware().

Well, when this function is called, my rootfs is not yet mounted (I
have a dedicated partition on a SDCard)...
So I probably missed a step in order to get /lib/firmware before / is
mounted... ?

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-06 Thread Jean-Michel Hautbois

2014-08-06 12:52 GMT+02:00 Takashi Iwai ti...@suse.de:
 At Wed, 6 Aug 2014 12:50:28 +0200,
 Jean-Michel Hautbois wrote:

 2014-08-06 12:21 GMT+02:00 Takashi Iwai ti...@suse.de:
  At Wed, 6 Aug 2014 11:44:14 +0200,
  Jean-Michel Hautbois wrote:
 
  2014-08-06 11:24 GMT+02:00 Takashi Iwai ti...@suse.de:
   At Wed, 6 Aug 2014 11:10:27 +0200,
   Jean-Michel Hautbois wrote:
  
   2014-08-05 21:22 GMT+02:00 Shuah Khan shuahk...@gmail.com:
On Tue, Aug 5, 2014 at 10:01 AM, Takashi Iwai ti...@suse.de wrote:
Yes, it worked, if the firmware was in the /lib/firmware directory.
   
   
ok it works when the firmware is in /lib/firmware. It sounds to me 
the
reason load fails when the firmware is under /sys/class/firmware is
fw_load_from_user_helper() returns -ENOENT when
CONFIG_FW_LOADER_USER_HELPER is disabled.
   
It would be nice to see the entire dmesg with debug enabled though.
   
-- Shuah
  
   It does not work with the 3.16 kernel even when firmware is in
   /lib/firmware, it worked before this patch is applied.
  
   Hm?  3.16 doesn't contain my patch yet.  It's merged for 3.17-rc1.
 
  Oh, you are right of course, I am on upstream kernel and I have your
  patch. I don't mean your match is causing the issue though ;-).
 
  I see.
 
   Here is what I got in my dmesg :
   [0.307856] __allocate_fw_buf: fw-lattice-ecp3.bit buf=bd81a480
   [0.308029] lattice-ecp3 spi2.3: Direct firmware load for
   lattice-ecp3.bit failed with error -2
  
   It's -ENOENT.  Are you sure that you really have
/lib/firmware/lattice-ecp3.bit file?
 
  Yes :
  ls -al /lib/firmware/lattice-ecp3.bit
  -rwxr-xr-x 1 root root 897753 Aug  5 15:04 /lib/firmware/lattice-ecp3.bit
 
  Then you'd better bisect...
  Or, at least, put a debug code to see which file is opened in the loop
  in fw_get_filesystem_firmware().

 Well, when this function is called, my rootfs is not yet mounted (I
 have a dedicated partition on a SDCard)...
 So I probably missed a step in order to get /lib/firmware before / is
 mounted... ?

 Yeah, possibly :)  Maybe you did put /lib/firmware/* into initrd in
 the earlier tests?

Nope, it failed and when / was mounted, it was called again and used
the firmware thanks to udev.
This is the CONFIG_FW_LOADER_USER_HELPER config which makes that now, right ?
But how can I have /lib/firmware in my initrd, that is the question I
need to answer now :).

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Lattice ECP3 FPGA: Check firmware pointer

2014-08-05 Thread jean-michel . hautbois

From: Jean-Michel Hautbois 

This patch corrects a lack of testing.
If fw is NULL when calling firmware_load(), it results in a kernel oops.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/misc/lattice-ecp3-config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/misc/lattice-ecp3-config.c 
b/drivers/misc/lattice-ecp3-config.c
index 7ffdb58..7e1efd5 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -79,6 +79,11 @@ static void firmware_load(const struct firmware *fw, void 
*context)
u32 jedec_id;
u32 status;

+   if (fw == NULL) {
+   dev_err(>dev, "Cannot load firmware, aborting\n");
+   return;
+   }
+
if (fw->size == 0) {
dev_err(>dev, "Error: Firmware size is 0!\n");
return;
--
2.0.4

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

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-05 Thread Jean-Michel Hautbois

2014-08-05 17:53 GMT+02:00 Takashi Iwai :
> At Tue, 5 Aug 2014 17:43:17 +0200,
> Jean-Michel Hautbois wrote:
>>
>> 2014-08-01 22:01 GMT+02:00  :
>> > Hi Takashi,
>> >
>> > Sorry for the late response,  I tried with latest stable kernel 3.15.8.  
>> > surprisingly the BIOS update works even without applying the patch in both 
>> > the cases.
>>
>> Hi,I'm sorry for my late answer too, but I didn't try this patch recently...
>>
>> I have a Lattice FPGA on my board, and it seems that your patch breaks
>> the firmware loading.
>> I have the following config :
>> CONFIG_FW_LOADER=y
>> CONFIG_FW_LOADER_USER_HELPER=n
>> FW_LOADER_USER_HELPER_FALLBACK=n
>> LATTICE_ECP3_CONFIG=y
>
> It worked before applying my patch properly...?
>
> The kernel Oops itself is a bug in lattice-ecp3-config driver.
> It blindly assumes that the returned firmware is non-NULL.
> firmware_load() must have a NULL check of fw at the beginning.
>
>
> thanks,
>
> Takashi

Yes, it worked, if the firmware was in the /lib/firmware directory.
You are right, it lacks a NULL check, I will fix that.

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch "firmware loader: allow disabling of udev as firmware loader" added to driver-core tree

2014-08-05 Thread Jean-Michel Hautbois

2014-08-01 22:01 GMT+02:00  :
> Hi Takashi,
>
> Sorry for the late response,  I tried with latest stable kernel 3.15.8.  
> surprisingly the BIOS update works even without applying the patch in both 
> the cases.

Hi,I'm sorry for my late answer too, but I didn't try this patch recently...

I have a Lattice FPGA on my board, and it seems that your patch breaks
the firmware loading.
I have the following config :
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_USER_HELPER=n
FW_LOADER_USER_HELPER_FALLBACK=n
LATTICE_ECP3_CONFIG=y


And my kernel panics :
[1.180677] lattice-ecp3 spi2.3: FPGA bitstream configuration
driver registered
[1.188285] lattice-ecp3 spi2.3: Direct firmware load for
lattice-ecp3.bit failed with error -2
[1.197063] Unable to handle kernel NULL pointer dereference at
virtual address 
[1.203616] spi_imx 201.ecspi: probed
[1.215947] pgd = 80004000
[1.218671] [] *pgd=
[1.84] Internal error: Oops: 5 [#1] SMP ARM
[1.226914] Modules linked in:
[1.230007] CPU: 1 PID: 47 Comm: kworker/1:1 Not tainted
3.16.0+yocto+g403c2fc #1
[1.237516] Workqueue: events request_firmware_work_func
[1.242861] task: be1d2700 ti: be20e000 task.ti: be20e000
[1.248281] PC is at firmware_load+0x10/0x47c
[1.252652] LR is at request_firmware_work_func+0x38/0x58
[1.258064] pc : [<80390490>]lr : [<803834c8>]psr: 2113
[1.258064] sp : be20fda0  ip : be20fe68  fp : be20fe64
[1.269552] r10: be20e008  r9 : 0001  r8 : be7c5a00
[1.274788] r7 : be20fea8  r6 : be7c2500  r5 : be3f95c0  r4 : be3f95c0
[1.281326] r3 : 80390480  r2 : be3f9600  r1 : bd829800  r0 : 
[1.287866] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[1.295185] Control: 10c5387d  Table: 1000404a  DAC: 0015
[1.300941] Process kworker/1:1 (pid: 47, stack limit = 0xbe20e240)
[1.307220] Stack: (0xbe20fda0 to 0xbe21)
[1.311595] fda0: be20fdd4 be20fdb0 803825b4 800e44f8 0001
 80382614 be3f9600
[1.319787] fdc0: 811ccae8 be3f9600 806e3bd4 be3f9600 fffe
fffe 0001 be0eb000
[1.327980] fde0: be20fe04 be20fdf0 803826c8 800e44f8 be1d2700
80870aa8 be20fe64 be20fe08
[1.336172] fe00: 80382d18 80382668 be3fa348 be20e000 be1d2700
be078000 80870aa8 be3f9600
[1.344364] fe20: be3fa348 be20fe6c bd829800 0003 be3fa300
803834b8 0001 be3f95c0
[1.352556] fe40: be3f95c0 be7c2500 be20fea8 be7c5a00 0001
be20e008 be20fe84 be20fe68
[1.360748] fe60: 803834c8 8039048c be0c2800  be7c2500
be0c2800 be20fee4 be20fe88
[1.368939] fe80: 8004245c 8038349c 0001  800423e8
be7c2500 80042e54 
[1.377131] fea0:   811ccb7c 80b0bd70 
8086f89c 806acc48 be7c2500
[1.385322] fec0: be7c2530 be20e028 be20e000 be0c2818 0008
be0c2800 be20ff24 be20fee8
[1.393514] fee0: 80042f30 800422bc 806acd4c be0c5280 
be0c2800 80042de8 be0c5280
[1.401706] ff00:  be0c2800 80042de8  
 be20ffac be20ff28
[1.409898] ff20: 80048ed0 80042df4 800675d0  be20ff54
be0c2800  
[1.418089] ff40: dead4ead   809caae0 
 80825c5c be20ff5c
[1.426280] ff60: be20ff5c   dead4ead 
 809caae0 
[1.434472] ff80:  80825c5c be20ff88 be20ff88 be0c5280
80048df4  
[1.442663] ffa0:  be20ffb0 8000f748 80048e00 
  
[1.450853] ffc0:     
  
[1.459044] ffe0:     0013
 40030210 12290009
[1.467229] Backtrace:
[1.469719] [<80390480>] (firmware_load) from [<803834c8>]
(request_firmware_work_func+0x38/0x58)
[1.478600]  r10:be20e008 r9:0001 r8:be7c5a00 r7:be20fea8
r6:be7c2500 r5:be3f95c0
[1.486548]  r4:be3f95c0
[1.489131] [<80383490>] (request_firmware_work_func) from
[<8004245c>] (process_one_work+0x1ac/0x414)
[1.498446]  r4:be0c2800
[1.501019] [<800422b0>] (process_one_work) from [<80042f30>]
(worker_thread+0x148/0x4e4)
[1.509206]  r10:be0c2800 r9:0008 r8:be0c2818 r7:be20e000
r6:be20e028 r5:be7c2530
[1.517152]  r4:be7c2500
[1.519729] [<80042de8>] (worker_thread) from [<80048ed0>]
(kthread+0xdc/0xf8)
[1.526960]  r10: r9: r8: r7:80042de8
r6:be0c2800 r5:
[1.534906]  r4:be0c5280
[1.537483] [<80048df4>] (kthread) from [<8000f748>]
(ret_from_fork+0x14/0x2c)
[1.544715]  r7: r6: r5:80048df4 r4:be0c5280
[1.550474] Code: e1a0c00d e92ddff0 e24cb004 e24dd09c (e5903000)
[1.556642] ---[ end trace d18e8b19760cc1e3 ]---

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

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-05 Thread Jean-Michel Hautbois

2014-08-01 22:01 GMT+02:00  b_b_si...@dell.com:
 Hi Takashi,

 Sorry for the late response,  I tried with latest stable kernel 3.15.8.  
 surprisingly the BIOS update works even without applying the patch in both 
 the cases.

Hi,I'm sorry for my late answer too, but I didn't try this patch recently...

I have a Lattice FPGA on my board, and it seems that your patch breaks
the firmware loading.
I have the following config :
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_USER_HELPER=n
FW_LOADER_USER_HELPER_FALLBACK=n
LATTICE_ECP3_CONFIG=y


And my kernel panics :
[1.180677] lattice-ecp3 spi2.3: FPGA bitstream configuration
driver registered
[1.188285] lattice-ecp3 spi2.3: Direct firmware load for
lattice-ecp3.bit failed with error -2
[1.197063] Unable to handle kernel NULL pointer dereference at
virtual address 
[1.203616] spi_imx 201.ecspi: probed
[1.215947] pgd = 80004000
[1.218671] [] *pgd=
[1.84] Internal error: Oops: 5 [#1] SMP ARM
[1.226914] Modules linked in:
[1.230007] CPU: 1 PID: 47 Comm: kworker/1:1 Not tainted
3.16.0+yocto+g403c2fc #1
[1.237516] Workqueue: events request_firmware_work_func
[1.242861] task: be1d2700 ti: be20e000 task.ti: be20e000
[1.248281] PC is at firmware_load+0x10/0x47c
[1.252652] LR is at request_firmware_work_func+0x38/0x58
[1.258064] pc : [80390490]lr : [803834c8]psr: 2113
[1.258064] sp : be20fda0  ip : be20fe68  fp : be20fe64
[1.269552] r10: be20e008  r9 : 0001  r8 : be7c5a00
[1.274788] r7 : be20fea8  r6 : be7c2500  r5 : be3f95c0  r4 : be3f95c0
[1.281326] r3 : 80390480  r2 : be3f9600  r1 : bd829800  r0 : 
[1.287866] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[1.295185] Control: 10c5387d  Table: 1000404a  DAC: 0015
[1.300941] Process kworker/1:1 (pid: 47, stack limit = 0xbe20e240)
[1.307220] Stack: (0xbe20fda0 to 0xbe21)
[1.311595] fda0: be20fdd4 be20fdb0 803825b4 800e44f8 0001
 80382614 be3f9600
[1.319787] fdc0: 811ccae8 be3f9600 806e3bd4 be3f9600 fffe
fffe 0001 be0eb000
[1.327980] fde0: be20fe04 be20fdf0 803826c8 800e44f8 be1d2700
80870aa8 be20fe64 be20fe08
[1.336172] fe00: 80382d18 80382668 be3fa348 be20e000 be1d2700
be078000 80870aa8 be3f9600
[1.344364] fe20: be3fa348 be20fe6c bd829800 0003 be3fa300
803834b8 0001 be3f95c0
[1.352556] fe40: be3f95c0 be7c2500 be20fea8 be7c5a00 0001
be20e008 be20fe84 be20fe68
[1.360748] fe60: 803834c8 8039048c be0c2800  be7c2500
be0c2800 be20fee4 be20fe88
[1.368939] fe80: 8004245c 8038349c 0001  800423e8
be7c2500 80042e54 
[1.377131] fea0:   811ccb7c 80b0bd70 
8086f89c 806acc48 be7c2500
[1.385322] fec0: be7c2530 be20e028 be20e000 be0c2818 0008
be0c2800 be20ff24 be20fee8
[1.393514] fee0: 80042f30 800422bc 806acd4c be0c5280 
be0c2800 80042de8 be0c5280
[1.401706] ff00:  be0c2800 80042de8  
 be20ffac be20ff28
[1.409898] ff20: 80048ed0 80042df4 800675d0  be20ff54
be0c2800  
[1.418089] ff40: dead4ead   809caae0 
 80825c5c be20ff5c
[1.426280] ff60: be20ff5c   dead4ead 
 809caae0 
[1.434472] ff80:  80825c5c be20ff88 be20ff88 be0c5280
80048df4  
[1.442663] ffa0:  be20ffb0 8000f748 80048e00 
  
[1.450853] ffc0:     
  
[1.459044] ffe0:     0013
 40030210 12290009
[1.467229] Backtrace:
[1.469719] [80390480] (firmware_load) from [803834c8]
(request_firmware_work_func+0x38/0x58)
[1.478600]  r10:be20e008 r9:0001 r8:be7c5a00 r7:be20fea8
r6:be7c2500 r5:be3f95c0
[1.486548]  r4:be3f95c0
[1.489131] [80383490] (request_firmware_work_func) from
[8004245c] (process_one_work+0x1ac/0x414)
[1.498446]  r4:be0c2800
[1.501019] [800422b0] (process_one_work) from [80042f30]
(worker_thread+0x148/0x4e4)
[1.509206]  r10:be0c2800 r9:0008 r8:be0c2818 r7:be20e000
r6:be20e028 r5:be7c2530
[1.517152]  r4:be7c2500
[1.519729] [80042de8] (worker_thread) from [80048ed0]
(kthread+0xdc/0xf8)
[1.526960]  r10: r9: r8: r7:80042de8
r6:be0c2800 r5:
[1.534906]  r4:be0c5280
[1.537483] [80048df4] (kthread) from [8000f748]
(ret_from_fork+0x14/0x2c)
[1.544715]  r7: r6: r5:80048df4 r4:be0c5280
[1.550474] Code: e1a0c00d e92ddff0 e24cb004 e24dd09c (e5903000)
[1.556642] ---[ end trace d18e8b19760cc1e3 ]---

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: patch firmware loader: allow disabling of udev as firmware loader added to driver-core tree

2014-08-05 Thread Jean-Michel Hautbois

2014-08-05 17:53 GMT+02:00 Takashi Iwai ti...@suse.de:
 At Tue, 5 Aug 2014 17:43:17 +0200,
 Jean-Michel Hautbois wrote:

 2014-08-01 22:01 GMT+02:00  b_b_si...@dell.com:
  Hi Takashi,
 
  Sorry for the late response,  I tried with latest stable kernel 3.15.8.  
  surprisingly the BIOS update works even without applying the patch in both 
  the cases.

 Hi,I'm sorry for my late answer too, but I didn't try this patch recently...

 I have a Lattice FPGA on my board, and it seems that your patch breaks
 the firmware loading.
 I have the following config :
 CONFIG_FW_LOADER=y
 CONFIG_FW_LOADER_USER_HELPER=n
 FW_LOADER_USER_HELPER_FALLBACK=n
 LATTICE_ECP3_CONFIG=y

 It worked before applying my patch properly...?

 The kernel Oops itself is a bug in lattice-ecp3-config driver.
 It blindly assumes that the returned firmware is non-NULL.
 firmware_load() must have a NULL check of fw at the beginning.


 thanks,

 Takashi

Yes, it worked, if the firmware was in the /lib/firmware directory.
You are right, it lacks a NULL check, I will fix that.

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Lattice ECP3 FPGA: Check firmware pointer

2014-08-05 Thread jean-michel . hautbois

From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com

This patch corrects a lack of testing.
If fw is NULL when calling firmware_load(), it results in a kernel oops.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/misc/lattice-ecp3-config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/misc/lattice-ecp3-config.c 
b/drivers/misc/lattice-ecp3-config.c
index 7ffdb58..7e1efd5 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -79,6 +79,11 @@ static void firmware_load(const struct firmware *fw, void 
*context)
u32 jedec_id;
u32 status;

+   if (fw == NULL) {
+   dev_err(spi-dev, Cannot load firmware, aborting\n);
+   return;
+   }
+
if (fw-size == 0) {
dev_err(spi-dev, Error: Firmware size is 0!\n);
return;
--
2.0.4

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

[PATCH v5] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c 
b/drivers/misc/lattice-ecp3-config.c
index 61fbe6a..66b37bc 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define FIRMWARE_NAME  "lattice-ecp3.bit"
 
@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
-   jedec_id = *(u32 *)[4];
+   jedec_id = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", jedec_id);
 
for (i = 0; i < ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
 
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
+   status = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);
 
buffer = kzalloc(fw->size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware *fw, void 
*context)
for (i = 0; i < FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)[4];
+   status = get_unaligned_be32([4]);
if (status == FPGA_STATUS_CLEARED)
break;
 
@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
 
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
-   status = *(u32 *)[4];
+   status = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);
 
/* Check result */
if (status & FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
spi_set_drvdata(spi, data);
 
init_completion(>fw_loaded);
-   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
  FIRMWARE_NAME, >dev,
  GFP_KERNEL, spi, firmware_load);
if (err) {
-- 
2.0.0

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

Re: [PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

2014-07-24 9:37 GMT+02:00 Greg KH :
> On Thu, Jul 24, 2014 at 08:53:30AM +0200, Jean-Michel Hautbois wrote:
>> > Your email client ate all the tabs and spit out spaces and then
>> > line-wrapped the patch, making it impossible to apply :(
>> >
>> > Can you fix it up and resend it in a format we can use?
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>> GMail GUI is a nightmare, I can't find an option to tell it to let me
>> send whatever I want... :(
>> I will use Thunderbird then !
>
> Please see Documentation/email-clients.txt for help with this.

Thanks, as expected, GMail is a crap :).
Do I resend this patch as [PATCH v5] or as a reply to this mail ?

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

> Your email client ate all the tabs and spit out spaces and then
> line-wrapped the patch, making it impossible to apply :(
>
> Can you fix it up and resend it in a format we can use?
>
> thanks,
>
> greg k-h

GMail GUI is a nightmare, I can't find an option to tell it to let me
send whatever I want... :(
I will use Thunderbird then !

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

 Your email client ate all the tabs and spit out spaces and then
 line-wrapped the patch, making it impossible to apply :(

 Can you fix it up and resend it in a format we can use?

 thanks,

 greg k-h

GMail GUI is a nightmare, I can't find an option to tell it to let me
send whatever I want... :(
I will use Thunderbird then !

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

2014-07-24 9:37 GMT+02:00 Greg KH gre...@linuxfoundation.org:
 On Thu, Jul 24, 2014 at 08:53:30AM +0200, Jean-Michel Hautbois wrote:
  Your email client ate all the tabs and spit out spaces and then
  line-wrapped the patch, making it impossible to apply :(
 
  Can you fix it up and resend it in a format we can use?
 
  thanks,
 
  greg k-h

 GMail GUI is a nightmare, I can't find an option to tell it to let me
 send whatever I want... :(
 I will use Thunderbird then !

 Please see Documentation/email-clients.txt for help with this.

Thanks, as expected, GMail is a crap :).
Do I resend this patch as [PATCH v5] or as a reply to this mail ?

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5] Lattice ECP3 FPGA: Correct endianness

2014-07-24 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c 
b/drivers/misc/lattice-ecp3-config.c
index 61fbe6a..66b37bc 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include linux/spi/spi.h
 #include linux/platform_device.h
 #include linux/delay.h
+#include asm/unaligned.h
 
 #define FIRMWARE_NAME  lattice-ecp3.bit
 
@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
-   jedec_id = *(u32 *)rxbuf[4];
+   jedec_id = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, jedec_id);
 
for (i = 0; i  ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
 
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
+   status = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);
 
buffer = kzalloc(fw-size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware *fw, void 
*context)
for (i = 0; i  FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)rxbuf[4];
+   status = get_unaligned_be32(rxbuf[4]);
if (status == FPGA_STATUS_CLEARED)
break;
 
@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware *fw, void 
*context)
 
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
-   status = *(u32 *)rxbuf[4];
+   status = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);
 
/* Check result */
if (status  FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
spi_set_drvdata(spi, data);
 
init_completion(data-fw_loaded);
-   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
  FIRMWARE_NAME, spi-dev,
  GFP_KERNEL, spi, firmware_load);
if (err) {
-- 
2.0.0

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

[PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-23 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..2c86319 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 #define FIRMWARE_NAME"lattice-ecp3.bit"

@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
 /* Trying to speak with the FPGA via SPI... */
 txbuf[0] = FPGA_CMD_READ_ID;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
-jedec_id = *(u32 *)[4];
+jedec_id = get_unaligned_be32([4]);
+dev_dbg(>dev, "FPGA JTAG ID=%08x\n", jedec_id);

 for (i = 0; i < ARRAY_SIZE(ecp3_dev); i++) {
 if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
+status = get_unaligned_be32([4]);
+dev_dbg(>dev, "FPGA Status=%08x\n", status);

 buffer = kzalloc(fw->size + 8, GFP_KERNEL);
 if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
 for (i = 0; i < FPGA_CLEAR_LOOP_COUNT; i++) {
 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-status = *(u32 *)[4];
+status = get_unaligned_be32([4]);
 if (status == FPGA_STATUS_CLEARED)
 break;

@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
-status = *(u32 *)[4];
+status = get_unaligned_be32([4]);
+dev_dbg(>dev, "FPGA Status=%08x\n", status);

 /* Check result */
 if (status & FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
 spi_set_drvdata(spi, data);

 init_completion(>fw_loaded);
-err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
   FIRMWARE_NAME, >dev,
   GFP_KERNEL, spi, firmware_load);
 if (err) {
-- 
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] Lattice ECP3 FPGA: Correct endianness

2014-07-23 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..2c86319 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include linux/spi/spi.h
 #include linux/platform_device.h
 #include linux/delay.h
+#include asm/unaligned.h

 #define FIRMWARE_NAMElattice-ecp3.bit

@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
 /* Trying to speak with the FPGA via SPI... */
 txbuf[0] = FPGA_CMD_READ_ID;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
-jedec_id = *(u32 *)rxbuf[4];
+jedec_id = get_unaligned_be32(rxbuf[4]);
+dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, jedec_id);

 for (i = 0; i  ARRAY_SIZE(ecp3_dev); i++) {
 if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
+status = get_unaligned_be32(rxbuf[4]);
+dev_dbg(spi-dev, FPGA Status=%08x\n, status);

 buffer = kzalloc(fw-size + 8, GFP_KERNEL);
 if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
 for (i = 0; i  FPGA_CLEAR_LOOP_COUNT; i++) {
 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-status = *(u32 *)rxbuf[4];
+status = get_unaligned_be32(rxbuf[4]);
 if (status == FPGA_STATUS_CLEARED)
 break;

@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
-status = *(u32 *)rxbuf[4];
+status = get_unaligned_be32(rxbuf[4]);
+dev_dbg(spi-dev, FPGA Status=%08x\n, status);

 /* Check result */
 if (status  FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
 spi_set_drvdata(spi, data);

 init_completion(data-fw_loaded);
-err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
   FIRMWARE_NAME, spi-dev,
   GFP_KERNEL, spi, firmware_load);
 if (err) {
-- 
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] Lattice ECP3 FPGA: Correct endianness

2014-07-21 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois 
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..f77ff4b 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 

 #define FIRMWARE_NAME  "lattice-ecp3.bit"

@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
-   jedec_id = *(u32 *)[4];
+   jedec_id = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", jedec_id);

for (i = 0; i < ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
+status = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);

buffer = kzalloc(fw->size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
for (i = 0; i < FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)[4];
+   status = get_unaligned_be32([4]);
if (status == FPGA_STATUS_CLEARED)
break;

@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
-   status = *(u32 *)[4];
+   status = get_unaligned_be32([4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);

/* Check result */
if (status & FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
spi_set_drvdata(spi, data);

init_completion(>fw_loaded);
-   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
  FIRMWARE_NAME, >dev,
  GFP_KERNEL, spi, firmware_load);
if (err) {
-- 
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] Lattice ECP3 FPGA: Correct endianness

2014-07-21 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.
It also sends uevent in order to load it.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
 drivers/misc/lattice-ecp3-config.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..f77ff4b 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -16,6 +16,7 @@
 #include linux/spi/spi.h
 #include linux/platform_device.h
 #include linux/delay.h
+#include asm/unaligned.h

 #define FIRMWARE_NAME  lattice-ecp3.bit

@@ -92,8 +93,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
-   jedec_id = *(u32 *)rxbuf[4];
+   jedec_id = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, jedec_id);

for (i = 0; i  ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +111,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
+status = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);

buffer = kzalloc(fw-size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +144,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
for (i = 0; i  FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)rxbuf[4];
+   status = get_unaligned_be32(rxbuf[4]);
if (status == FPGA_STATUS_CLEARED)
break;

@@ -165,8 +167,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
-   status = *(u32 *)rxbuf[4];
+   status = get_unaligned_be32(rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);

/* Check result */
if (status  FPGA_STATUS_DONE)
@@ -197,7 +199,7 @@ static int lattice_ecp3_probe(struct spi_device *spi)
spi_set_drvdata(spi, data);

init_completion(data-fw_loaded);
-   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_NOHOTPLUG,
+   err = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
  FIRMWARE_NAME, spi-dev,
  GFP_KERNEL, spi, firmware_load);
if (err) {
-- 
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

2014-07-04 16:58 GMT+02:00 Geert Uytterhoeven :
> On Thu, Jul 3, 2014 at 5:54 PM, Jean-Michel Hautbois
>  wrote:
>> --- a/drivers/misc/lattice-ecp3-config.c
>> +++ b/drivers/misc/lattice-ecp3-config.c
>> @@ -93,7 +93,7 @@ static void firmware_load(const struct firmware *fw,
>> void *context)
>>  txbuf[0] = FPGA_CMD_READ_ID;
>>  ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
>>  dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
>> -jedec_id = *(u32 *)[4];
>> +jedec_id = be32_to_cpu(*(u32 *)[4]);
>
> What about "jedec_id = get_unaligned_be32([4]);" instead?

Eh I didn't know such a function existed ! :)

JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.

Signed-off-by: Jean-Michel Hautbois 
Acked-by: Stefan Roese 
---
 drivers/misc/lattice-ecp3-config.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..957a66c 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -92,8 +92,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
-   jedec_id = *(u32 *)[4];
+   jedec_id = be32_to_cpu(*(__be32 *)[4]);
+   dev_dbg(>dev, "FPGA JTAG ID=%08x\n", jedec_id);

for (i = 0; i < ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +110,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
+   status = be32_to_cpu(*(__be32 *)[4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);

buffer = kzalloc(fw->size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +143,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
for (i = 0; i < FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)[4];
+   status = be32_to_cpu(*(u32 *)[4]);
if (status == FPGA_STATUS_CLEARED)
break;

@@ -165,8 +166,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
-   status = *(u32 *)[4];
+   status = be32_to_cpu(*(__be32 *)[4]);
+   dev_dbg(>dev, "FPGA Status=%08x\n", status);

/* Check result */
if (status & FPGA_STATUS_DONE)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

2014-07-03 18:12 GMT+02:00 Joe Perches :
>
> On Thu, 2014-07-03 at 17:54 +0200, Jean-Michel Hautbois wrote:
> > This patch corrects three big/little endian issues. Tested on i.MX6.
>
> trivial:
>
> > diff --git a/drivers/misc/lattice-ecp3-config.c
> []
> > @@ -165,8 +165,8 @@ static void firmware_load(const struct firmware
> > *fw, void *context)
> >
> >  txbuf[0] = FPGA_CMD_READ_STATUS;
> >  ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
> > -dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
> > -status = *(u32 *)[4];
> > +dev_dbg(>dev, "FPGA Status=%08x\n", be32_to_cpu(*(u32 
> > *)[4]));
> > +status = be32_to_cpu(*(u32 *)[4]);
>
> This should emit a sparse error.
> It'd be simpler as:
>
> status = be32_to_cpu(*(__be32 *)[4]);
> dev_dbg(>dev, "FPGA Status=%08x\n", status);
>
>

OK, do you want me to send a new patch including this modification ?


JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lattice ECP3 load firmware

2014-07-04 Thread Jean-Michel Hautbois

Hi !

I noticed you (Stefan) are using request_firmware_nowait() call. This
means user needs to explicitly call it using

$ echo 1 > /sys/class/firmware/lattice-ecp3.0/loading
$ cat lattice-ecp3.bit > /sys/class/firmware/lattice-ecp3.0/data
$ echo 0 > /sys/class/firmware/lattice-ecp3.0/loading

Or did I miss something ?
I would like to have it load the firmware bitstream when booting if
there is a specific .bit file in /lib/firmware. Maybe don't you want
to have this behaviour, though... ?

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lattice ECP3 load firmware

2014-07-04 Thread Jean-Michel Hautbois

Hi !

I noticed you (Stefan) are using request_firmware_nowait() call. This
means user needs to explicitly call it using

$ echo 1  /sys/class/firmware/lattice-ecp3.0/loading
$ cat lattice-ecp3.bit  /sys/class/firmware/lattice-ecp3.0/data
$ echo 0  /sys/class/firmware/lattice-ecp3.0/loading

Or did I miss something ?
I would like to have it load the firmware bitstream when booting if
there is a specific .bit file in /lib/firmware. Maybe don't you want
to have this behaviour, though... ?

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

2014-07-03 18:12 GMT+02:00 Joe Perches j...@perches.com:

 On Thu, 2014-07-03 at 17:54 +0200, Jean-Michel Hautbois wrote:
  This patch corrects three big/little endian issues. Tested on i.MX6.

 trivial:

  diff --git a/drivers/misc/lattice-ecp3-config.c
 []
  @@ -165,8 +165,8 @@ static void firmware_load(const struct firmware
  *fw, void *context)
 
   txbuf[0] = FPGA_CMD_READ_STATUS;
   ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
  -dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
  -status = *(u32 *)rxbuf[4];
  +dev_dbg(spi-dev, FPGA Status=%08x\n, be32_to_cpu(*(u32 
  *)rxbuf[4]));
  +status = be32_to_cpu(*(u32 *)rxbuf[4]);

 This should emit a sparse error.
 It'd be simpler as:

 status = be32_to_cpu(*(__be32 *)rxbuf[4]);
 dev_dbg(spi-dev, FPGA Status=%08x\n, status);



OK, do you want me to send a new patch including this modification ?


JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

This code corrects endianness and avoids a sparse error.
Tested with Lattice ECP3-35 with Freescale i.MX6.

Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
Acked-by: Stefan Roese s...@denx.de
---
 drivers/misc/lattice-ecp3-config.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..957a66c 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -92,8 +92,8 @@ static void firmware_load(const struct firmware *fw,
void *context)
/* Trying to speak with the FPGA via SPI... */
txbuf[0] = FPGA_CMD_READ_ID;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
-   jedec_id = *(u32 *)rxbuf[4];
+   jedec_id = be32_to_cpu(*(__be32 *)rxbuf[4]);
+   dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, jedec_id);

for (i = 0; i  ARRAY_SIZE(ecp3_dev); i++) {
if (jedec_id == ecp3_dev[i].jedec_id)
@@ -110,7 +110,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
+   status = be32_to_cpu(*(__be32 *)rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);

buffer = kzalloc(fw-size + 8, GFP_KERNEL);
if (!buffer) {
@@ -142,7 +143,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
for (i = 0; i  FPGA_CLEAR_LOOP_COUNT; i++) {
txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   status = *(u32 *)rxbuf[4];
+   status = be32_to_cpu(*(u32 *)rxbuf[4]);
if (status == FPGA_STATUS_CLEARED)
break;

@@ -165,8 +166,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

txbuf[0] = FPGA_CMD_READ_STATUS;
ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-   dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
-   status = *(u32 *)rxbuf[4];
+   status = be32_to_cpu(*(__be32 *)rxbuf[4]);
+   dev_dbg(spi-dev, FPGA Status=%08x\n, status);

/* Check result */
if (status  FPGA_STATUS_DONE)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-04 Thread Jean-Michel Hautbois

2014-07-04 16:58 GMT+02:00 Geert Uytterhoeven ge...@linux-m68k.org:
 On Thu, Jul 3, 2014 at 5:54 PM, Jean-Michel Hautbois
 jean-michel.hautb...@vodalys.com wrote:
 --- a/drivers/misc/lattice-ecp3-config.c
 +++ b/drivers/misc/lattice-ecp3-config.c
 @@ -93,7 +93,7 @@ static void firmware_load(const struct firmware *fw,
 void *context)
  txbuf[0] = FPGA_CMD_READ_ID;
  ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
  dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
 -jedec_id = *(u32 *)rxbuf[4];
 +jedec_id = be32_to_cpu(*(u32 *)rxbuf[4]);

 What about jedec_id = get_unaligned_be32(rxbuf[4]); instead?

Eh I didn't know such a function existed ! :)

JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-03 Thread Jean-Michel Hautbois

This patch corrects three big/little endian issues. Tested on i.MX6.

From: Jean-Michel Hautbois 
Date: Thu, 3 Jul 2014 17:49:47 +0200
Subject: [PATCH] Endianness corrections

---
 drivers/misc/lattice-ecp3-config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..23d5c01 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -93,7 +93,7 @@ static void firmware_load(const struct firmware *fw,
void *context)
 txbuf[0] = FPGA_CMD_READ_ID;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
 dev_dbg(>dev, "FPGA JTAG ID=%08x\n", *(u32 *)[4]);
-jedec_id = *(u32 *)[4];
+jedec_id = be32_to_cpu(*(u32 *)[4]);

 for (i = 0; i < ARRAY_SIZE(ecp3_dev); i++) {
 if (jedec_id == ecp3_dev[i].jedec_id)
@@ -142,7 +142,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
 for (i = 0; i < FPGA_CLEAR_LOOP_COUNT; i++) {
 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-status = *(u32 *)[4];
+status = be32_to_cpu(*(u32 *)[4]);
 if (status == FPGA_STATUS_CLEARED)
 break;

@@ -165,8 +165,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(>dev, "FPGA Status=%08x\n", *(u32 *)[4]);
-status = *(u32 *)[4];
+dev_dbg(>dev, "FPGA Status=%08x\n", be32_to_cpu(*(u32 *)[4]));
+status = be32_to_cpu(*(u32 *)[4]);

 /* Check result */
 if (status & FPGA_STATUS_DONE)
-- 
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lattice ECP3 FPGA with i.MX6

2014-07-03 Thread Jean-Michel Hautbois

> No. This driver was implemented and tested in a MPC5200 system. Most likely
> I missed some endian issues as you already noticed. I suggest you start with
> looking at this line:
>
> jedec_id = *(u32 *)[4];
>
> And add some endian functions here, e.g. be32_to_cpu(). This might help with
> the detection. But other endian related issues might still be present in
> other parts of the driver as well.

Replacing this line with the following works better :
jedec_id = be32_to_cpu(*(u32 *)[4]);

At least, on detecting the FPGA...
I will send a patch, but there is only three places where there is a
be32_to_cpu() to add.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lattice ECP3 FPGA with i.MX6

2014-07-03 Thread Jean-Michel Hautbois

Hi,

I have a board, with a Freescale i.MX6 chip and a ECP3-35 FPGA on SPI.
I tried to load the firmware using the lattice-ecp3-config driver, but
it fails with this error :

lattice-ecp3 spi32766.3: FPGA bitstream configuration driver registered
lattice-ecp3 spi32766.3: Error: No supported FPGA detected (JEDEC_ID=808004c2)!

In the driver, the id is :

#define ID_ECP3_35 0xc2048080

Obviously, there is a big/little endian issue... Do I need to instruct
the device-tree in a specific way in order to get the bus in the
correct order ? Or is this a known issue maybe ?

Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lattice ECP3 FPGA with i.MX6

2014-07-03 Thread Jean-Michel Hautbois

Hi,

I have a board, with a Freescale i.MX6 chip and a ECP3-35 FPGA on SPI.
I tried to load the firmware using the lattice-ecp3-config driver, but
it fails with this error :

lattice-ecp3 spi32766.3: FPGA bitstream configuration driver registered
lattice-ecp3 spi32766.3: Error: No supported FPGA detected (JEDEC_ID=808004c2)!

In the driver, the id is :

#define ID_ECP3_35 0xc2048080

Obviously, there is a big/little endian issue... Do I need to instruct
the device-tree in a specific way in order to get the bus in the
correct order ? Or is this a known issue maybe ?

Thanks,
JM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lattice ECP3 FPGA with i.MX6

2014-07-03 Thread Jean-Michel Hautbois

 No. This driver was implemented and tested in a MPC5200 system. Most likely
 I missed some endian issues as you already noticed. I suggest you start with
 looking at this line:

 jedec_id = *(u32 *)rxbuf[4];

 And add some endian functions here, e.g. be32_to_cpu(). This might help with
 the detection. But other endian related issues might still be present in
 other parts of the driver as well.

Replacing this line with the following works better :
jedec_id = be32_to_cpu(*(u32 *)rxbuf[4]);

At least, on detecting the FPGA...
I will send a patch, but there is only three places where there is a
be32_to_cpu() to add.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Lattice ECP3 FPGA: Correct endianness

2014-07-03 Thread Jean-Michel Hautbois

This patch corrects three big/little endian issues. Tested on i.MX6.

From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
Date: Thu, 3 Jul 2014 17:49:47 +0200
Subject: [PATCH] Endianness corrections

---
 drivers/misc/lattice-ecp3-config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/lattice-ecp3-config.c
b/drivers/misc/lattice-ecp3-config.c
index bb26f08..23d5c01 100644
--- a/drivers/misc/lattice-ecp3-config.c
+++ b/drivers/misc/lattice-ecp3-config.c
@@ -93,7 +93,7 @@ static void firmware_load(const struct firmware *fw,
void *context)
 txbuf[0] = FPGA_CMD_READ_ID;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
 dev_dbg(spi-dev, FPGA JTAG ID=%08x\n, *(u32 *)rxbuf[4]);
-jedec_id = *(u32 *)rxbuf[4];
+jedec_id = be32_to_cpu(*(u32 *)rxbuf[4]);

 for (i = 0; i  ARRAY_SIZE(ecp3_dev); i++) {
 if (jedec_id == ecp3_dev[i].jedec_id)
@@ -142,7 +142,7 @@ static void firmware_load(const struct firmware
*fw, void *context)
 for (i = 0; i  FPGA_CLEAR_LOOP_COUNT; i++) {
 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-status = *(u32 *)rxbuf[4];
+status = be32_to_cpu(*(u32 *)rxbuf[4]);
 if (status == FPGA_STATUS_CLEARED)
 break;

@@ -165,8 +165,8 @@ static void firmware_load(const struct firmware
*fw, void *context)

 txbuf[0] = FPGA_CMD_READ_STATUS;
 ret = spi_write_then_read(spi, txbuf, 8, rxbuf, rx_len);
-dev_dbg(spi-dev, FPGA Status=%08x\n, *(u32 *)rxbuf[4]);
-status = *(u32 *)rxbuf[4];
+dev_dbg(spi-dev, FPGA Status=%08x\n, be32_to_cpu(*(u32 *)rxbuf[4]));
+status = be32_to_cpu(*(u32 *)rxbuf[4]);

 /* Check result */
 if (status  FPGA_STATUS_DONE)
-- 
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

< 1 2

101 - 165 of 165 matches

Mail list logo