Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

[Liviu Dudau]

On Thu, Nov 12, 2015 at 09:30:31PM -0600, Rob Herring wrote:
> On Thu, Nov 12, 2015 at 4:42 AM, Liviu Dudau  wrote:
> > On Wed, Nov 11, 2015 at 12:48:50PM -0600, Rob Herring wrote:
> >> On Wed, Nov 11, 2015 at 04:06:47PM +, Liviu Dudau wrote:
> >> > Cc: Rob Herring 
> >> > Cc: Pawel Moll 
> >> > Cc: Mark Rutland 
> >> > Cc: Ian Campbell 
> >> > Cc: Kumar Gala 
> >> >
> >> > Signed-off-by: Liviu Dudau 
> >>
> >> Looks pretty good, but a few comments.
> >>
> >> > ---
> >> >  .../devicetree/bindings/drm/arm/arm,hdlcd.txt  | 74 
> >> > ++
> >> >  1 file changed, 74 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt 
> >> > b/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt
> >> > new file mode 100644
> >> > index 000..b57f1b9
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/drm/arm/arm,hdlcd.txt
> >> > @@ -0,0 +1,74 @@
> >> > +ARM HDLCD
> >> > +
> >> > +This is a display controller found on several development platforms 
> >> > produced
> >> > +by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
> >> > +streamer that reads the data from a framebuffer and sends it to a single
> >> > +digital encoder (DVI or HDMI).
> >> > +
> >> > +Required properties:
> >> > +  - compatible: "arm,hdlcd"
> >>
> >> Kind of generic. Something more specific please.
> >
> > "There can be only one!" (hdlcd) :) This is going to be a "one version 
> > only" HW part.
> > ARM has now switched to a new display hardware that has more features and a 
> > new name,
> > and work on mainlining support for that will start once I get the HDLCD 
> > driver accepted.
> 
> So there is never going to be a single difference across platforms.

Correct, there is only one implementation available. AFAIK there are no plans 
to make changes to it.

> Variations in max clock for different FPGAs?

The clock is external to the part and there is a check in the driver if we can 
set the frequency
to match the requested dotclock by the video_mode. It does not affect the 
hardware or how it presents
itself to the driver.

> 
> 
> >> > +  - reg: Physical base address and length of the controller's registers.
> >> > +If a second pair of address and length values is present this 
> >> > specifies
> >> > +the presence of a DMA coherent memory area that the HDLCD can use as
> >> > +framebuffer instead of normal CMA memory.
> >>
> >> This is on-chip RAM or nornal system RAM? We already have bindings for
> >> both.
> >
> > Juno has a set of TLX (ThinLinks) connectors on the board where an FPGA can 
> > be attached. On r1
> > the code running on FPGA can even participate as an AXI master with full 
> > coherency. The FPGA
> > has local memory that we want to share with the HDLCD to be used as a 
> > framebuffer.
> 
> So describe the memory region and then use a memory-region phandle to
> the memory here.

OK, I will.

> 
> >> > +  - interrupts: One interrupt used by the display controller to notify 
> >> > the
> >> > +interrupt controller when any of the interrupt sources programmed in
> >> > +the interrupt mask register have activated.
> >> > +  - clocks: A list of phandle + clock-specifier pairs, one for each
> >> > +entry in 'clock-names'.
> >> > +  - clock-names: A list of clock names. For HDLD it should contain:
> 
> typo: HDLD

oops, thanks, will fix.

> 
> >> > +  - "pxlclk" for the clock feeding the output PLL of the controller.
> >> > +  - port: The HDLCD connection to an encoder chip. The connection is 
> >> > modelled
> 
> s/modelled/modeled/

ditto.

Thanks for reviewing it,
Liviu

> 
> Rob
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Enric Balletbo i Serra]

Analogix Semiconductor develops analog and mixed-signal devices for digital
media and communications interconnect applications.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..8987ee8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -22,6 +22,7 @@ ampireAmpire Co., Ltd.
 amsAMS AG
 amstaosAMS-Taos Inc.
 apmApplied Micro Circuits Corporation (APM)
+analogix   Analogix Semiconductor, Inc.
 aptina Aptina Imaging
 arasan Arasan Chip Systems
 armARM Ltd.
-- 
2.1.0

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

[PATCHv5 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[Enric Balletbo i Serra]

At the moment it only supports ANX7814.

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.

This driver adds initial support and supports HDMI to DP pass-through mode.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/gpu/drm/bridge/Kconfig   |2 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig   |5 +
 drivers/gpu/drm/bridge/anx78xx/Makefile  |4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h |   45 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c|  347 +++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c | 3226 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h |  149 +
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h |  754 +
 9 files changed, 4533 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..aa6fe12 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.
 
+source "drivers/gpu/drm/bridge/anx78xx/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..e5bd38b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANX78XX) += anx78xx/
diff --git a/drivers/gpu/drm/bridge/anx78xx/Kconfig 
b/drivers/gpu/drm/bridge/anx78xx/Kconfig
new file mode 100644
index 000..7537673
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Kconfig
@@ -0,0 +1,5 @@
+config DRM_ANX78XX
+   tristate "Analogix ANX78XX bridge"
+   help
+   ANX78XX is a HD video transmitter chip over micro-USB
+   connector for smartphone device.
diff --git a/drivers/gpu/drm/bridge/anx78xx/Makefile 
b/drivers/gpu/drm/bridge/anx78xx/Makefile
new file mode 100644
index 000..a843733
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Makefile
@@ -0,0 +1,4 @@
+obj-${CONFIG_DRM_ANX78XX} :=  anx78xx.o
+
+anx78xx-y += anx78xx_main.o
+anx78xx-y += slimport_tx_drv.o
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx.h 
b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
new file mode 100644
index 000..ff8bbe8
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ANX78xx_H
+#define __ANX78xx_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct anx78xx_platform_data {
+   struct gpio_desc *gpiod_cable_det;
+   struct gpio_desc *gpiod_pd;
+   struct gpio_desc *gpiod_reset;
+   struct gpio_desc *gpiod_v10;
+};
+
+struct anx78xx {
+   struct drm_bridge bridge;
+   struct i2c_client *client;
+   struct anx78xx_platform_data *pdata;
+   struct delayed_work work;
+   struct workqueue_struct *workqueue;
+};
+
+void anx78xx_poweron(struct anx78xx *data);
+void anx78xx_poweroff(struct anx78xx *data);
+bool anx78xx_cable_is_detected(struct anx78xx *anx78xx);
+
+#endif
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c 
b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
new file mode 100644
index 000..4ea1274
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
@@ -0,0 +1,347 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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 

[PATCHv5 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Enric Balletbo i Serra]

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.

You can add support to your board with current binding.

Example:

anx7814: anx7814@38 {
compatible = "analogix,anx7814";
reg = <0x38>;
pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
};

Signed-off-by: Enric Balletbo i Serra 
---
 .../devicetree/bindings/video/bridge/anx7814.txt   | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..f7bdca9
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,36 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible  : "analogix,anx7814"
+ - reg : I2C address of the device
+ - cable-det-gpios : Which GPIO to use for cable detection
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Optional properties:
+
+ - v10-gpios   : Which GPIO to use for V10 control.
+ - video interfaces: Device node can contain video interface port nodes.
+
+Example:
+
+   anx7814: anx7814@38 {
+   compatible = "analogix,anx7814";
+   reg = <0x38>;
+   cable-det-gpios = < 1 GPIO_ACTIVE_HIGH>;
+   pd-gpios = < 2 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   v10-gpios = < 4 GPIO_ACTIVE_HIGH>;
+   ports {
+   port@0 {
+   anx7814_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
-- 
2.1.0

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

[PATCHv5 0/3] Add initial support for slimport anx78xx

[Enric Balletbo i Serra]

Hi all,

This is the fifth version of patch set. Any comments are welcome.

See the changelog below for details.

The following series add initial support for the Slimport ANX7814 transmitter, a
ultra-low power Full-HD (1080p60) transmitter designed for portable device.

The driver was originally created and based from the work of Junhua Xia from
Analogix. This driver is a refactor of the original driver and fixes different
coding style lines, and different errors/warnings reported by checkpatch. Also
there were things that I noticed that we need to change like:

 - Convert the numbered GPIO API to the new descriptor based GPIO API.
 - Review the DT binding
 - Add missing MODULE_DEVICE_TABLE(of, ...);
 - Fix Makefiles and Kconfig to build conditionally.
 - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and
  .resume callbacks.
 - Move to use managed device resources.
 - Remove dead/unused code.
 - And others ...

Changes since v4:
Rob Herring and Laurent Pinchart:
 - Add ports binding for describing data connections.
Nicolas Boichat:
 - He did a big effort refactoring the driver and in order to simplify the 
different
   state machines involved and the code in general.
Enric Balletbo:
 - Remove some magic numbers.
 - Use some DRM helpers.
 - Document better the driver in general

Changes since v3:

Nicolas Boichat: 
 - Integrate sp_edid_header_result with sp_check_edid_data
 - Fix loop forever.
 - Use meaningful messages and variable names
 - Replace some 'while' loops and use a for loop.
 - Might be clearer to say >= LINK_6P75G
 - Convert a function to void function because always return 0
 - Remove some magic numbers and refactor sp_tx_pclk_calc
 - Replace sp_read_reg(SP_TX_LINK_BW_SET_REG) for sp_tx_get_link_bw.
 - Mask bits 4:0. Bit 5 has another purpose, and 7:6 are reserved.
 - Use ARRAY_SIZE.
 - Use memset for initialization.
 - Simply condition if (!(c1 & POLLING_EN) || (c & POLLING_ERR))
 - Don not use a temporal variable write the value directly.
 - Fix various typos
 - Return directly PTR_ERR.

Dan Carpenter: 
 - Refactor while loop removing the earlier condition and do while (--c) instead
 - Simplify double negative and fix alignment
 - Remove the superflous casts to u16 and parens
 - Remove debug printks and use ftrace instead.
 - Flip this condition around and pull the code in one indent level.
 - Fix return value 'ret' that should be an int. It causes a signedness bug 
later.
 - Use better style for devm_kzalloc
 - Get rid of AUX_*.  They aren't used much and we could easily use normal 
error codes instead.

Enric Balletbo
 - Fix errors reported by scripts/checkpatch.pl --strict --subjective
 - Remove XTAL_CLK_M10 XTAL_CLK definitions
 - replace ulong for unsigned long
 - remove some magic numbers and refactor sp_tx_enable_audio_output
 - remove some magic numbers and refactor sp_tx_phy_auto_test

Changes since v2 (requested by Daniel Kurtz):
 - clean up the typos, and little nits requested by Dan.
 - move to the drm/bridge directory
 - rename the files, variables, types, etc. to anx78xx
 - plumb through the context struct to all functions that act on the device
 - use proper messaging (dev_ rather than pr_, _dbg/_err rather than _info)

Changes since v1:
 - As requested by Greg, move from staging to a subsystem.

Best regards,

Enric Balletbo i Serra (3):
  of: Add vendor prefix for Analogix Semiconductor, Inc.
  devicetree: Add new ANX7814 SlimPort transmitter binding.
  drm: bridge: anx78xx: Add anx78xx driver support by analogix.

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 .../devicetree/bindings/video/bridge/anx7814.txt   |   36 +
 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig |5 +
 drivers/gpu/drm/bridge/anx78xx/Makefile|4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h   |   45 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c  |  347 +++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c   | 3226 
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h   |  149 +
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h   |  754 +
 11 files changed, 4570 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

-- 
2.1.0

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

[PATCH] drivers: ata: Move vendor specific sata port phy oob settings to device-tree

[Anurag Kumar Vulisha]

In SATA, speed negotiation happens with  OOB(Out of Band) signals. These OOB
signal timing values are configured through vendor specific registers in the
SATA controller. These OOB timings depends on the generator and detector clock
frequency, which varies from board to board (ex: ep108, zcu102 and zc1751 has
different clock frequencies).
Since to make ahci_ceva driver generic, it would be better to move these
settings to the device-tree node and read them from driver.

This patch does the same.

Signed-off-by: Anurag Kumar Vulisha 
---
 .../devicetree/bindings/ata/ahci-ceva.txt  |   38 +
 drivers/ata/ahci_ceva.c|   84 ++--
 2 files changed, 99 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt 
b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
index 7ca8b97..66fcd10 100644
--- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
@@ -5,6 +5,36 @@ Required properties:
   - compatible: Compatibility string. Must be 'ceva,ahci-1v84'.
   - clocks: Input clock specifier. Refer to common clock bindings.
   - interrupts: Interrupt specifier. Refer to interrupt binding.
+- ceva,p0-cominit-params: OOB timing value for COMINIT parameter for port 
0.
+- ceva,p1-cominit-params: OOB timing value for COMINIT parameter for port 
1.
+   The fields for the above parameter must be as shown 
below:
+   ceva,phy-cominit-params = /bits/ 8 ;
+   CINMP : COMINIT Negate Minimum Period.
+   CIBGN : COMINIT Burst Gap Nominal.
+   CIBGMX: COMINIT Burst Gap Maximum.
+   CIBGMN: COMINIT Burst Gap Minimum.
+- ceva,p0-comwake-params: OOB timing value for COMWAKE parameter for port 
0.
+- ceva,p1-comwake-params: OOB timing value for COMWAKE parameter for port 
1.
+   The fields for the above parameter must be as shown 
below:
+   ceva,phy-comwake-params = /bits/ 8 ;
+   CWBGMN: COMWAKE Burst Gap Minimum.
+   CWBGMX: COMWAKE Burst Gap Maximum.
+   CWBGN: COMWAKE Burst Gap Nominal.
+   CWNMP: COMWAKE Negate Minimum Period.
+- ceva,p0-burst-params: Burst timing value for COM parameter for port 0.
+- ceva,p1-burst-params: Burst timing value for COM parameter for port 1.
+   The fields for the above parameter must be as shown 
below:
+   ceva,phy-burst-params = /bits/ 8 ;
+   BMX: COM Burst Maximum.
+   BNM: COM Burst Nominal.
+   SFD: Signal Failure Detection value.
+   PTST: Partial to Slumber timer value.
+- ceva,p0-retry-params: Retry interval timing value for port 0.
+- ceva,p1-retry-params: Retry interval timing value for port 1.
+   The fields for the above parameter must be as shown 
below:
+   ceva,phy-retry-params = /bits/ 16 ;
+   RIT:  Retry Interval Timer.
+   RCT:  Rate Change Timer.
 
 Optional properties:
   - ceva,broken-gen2: limit to gen1 speed instead of gen2.
@@ -17,4 +47,12 @@ Examples:
interrupts = <0 133 4>;
clocks = < SATA_CLK_ID>;
ceva,broken-gen2;
+   ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
+   ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
+   ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
+   ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>;
+   ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
+   ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
+   ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
+   ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>;
};
diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
index 207649d..59de2ca 100644
--- a/drivers/ata/ahci_ceva.c
+++ b/drivers/ata/ahci_ceva.c
@@ -50,21 +50,6 @@
 #define PPCFG_PSS_EN   (1 << 29)
 #define PPCFG_ESDF_EN  (1 << 31)
 
-#define PP2C_CIBGMN0x0F
-#define PP2C_CIBGMX(0x25 << 8)
-#define PP2C_CIBGN (0x18 << 16)
-#define PP2C_CINMP (0x29 << 24)
-
-#define PP3C_CWBGMN0x04
-#define PP3C_CWBGMX(0x0B << 8)
-#define PP3C_CWBGN (0x08 << 16)
-#define PP3C_CWNMP (0x0F << 24)
-
-#define PP4C_BMX   0x0a
-#define PP4C_BNM   (0x08 << 8)
-#define PP4C_SFD   (0x4a << 16)
-#define PP4C_PTST  (0x06 << 24)
-
 #define PP5C_RIT   0x60216
 #define PP5C_RCT   (0x7f0 << 20)
 
@@ -87,6 +72,11 @@
 
 struct ceva_ahci_priv {
struct platform_device *ahci_pdev;
+   /* Port Phy2Cfg Register */
+   u32 pp2c[NR_PORTS];
+   u32 pp3c[NR_PORTS];
+ 

[PATCH] backlight: tps65217_bl: Add MODULE_DEVICE_TABLE.

[Enric Balletbo i Serra]

The device table is required to load modules based on modaliases.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/video/backlight/tps65217_bl.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index 61d72bf..37a9731 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -320,10 +320,21 @@ static int tps65217_bl_probe(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id tps65217_bl_of_match[] = {
+   { .compatible = "ti,tps65217-bl", },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65217_bl_of_match);
+#endif
+
 static struct platform_driver tps65217_bl_driver = {
.probe  = tps65217_bl_probe,
.driver = {
.name   = "tps65217-bl",
+#ifdef CONFIG_OF
+   .of_match_table = tps65217_bl_of_match,
+#endif
},
 };
 
-- 
2.1.0

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

Re: [PATCH] dmaengine: rcar-dmac: Document SoC specific bindings

[Geert Uytterhoeven]

Hi Rob,

On Fri, Nov 13, 2015 at 12:28 AM, Rob Herring  wrote:
>> diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt 
>> b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
>> index 09daeef1ff22..5b902ac8d97e 100644
>> --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
>> +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
>> @@ -14,7 +14,14 @@ not described in these device tree bindings.
>>
>>  Required Properties:
>>
>> -- compatible: must contain "renesas,rcar-dmac"
>> +- compatible: "renesas,dmac-", "renesas,rcar-dmac" as fallback.
>
> Somehow Renesas has ended up being backwards from everyone else that
> does ,-. Oh well...

I know. Renesas has a mix of both :-(

As in this case the generic one does follow the ",-"
pattern ("renesas,rcar-dmac"), it may make sense to use
"renesas,-dmac", to avoid having a mix in the bindings for the same
block.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/19] clk: sunxi: add DRAM gates

[Chen-Yu Tsai]

On Mon, Nov 9, 2015 at 12:18 PM, Chen-Yu Tsai  wrote:
> On Fri, Oct 30, 2015 at 10:20 PM, Maxime Ripard
>  wrote:
>> The Allwinner SoCs have a gate controller to gate the access to the DRAM
>> clock to the some devices that need to access the DRAM directly (mostly
>> display / image related IPs).
>>
>> Use a simple gates driver to support it.
>>
>> Signed-off-by: Maxime Ripard 
>
> Acked-by: Chen-Yu Tsai 
>
>> ---
>>  drivers/clk/sunxi/clk-simple-gates.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi/clk-simple-gates.c 
>> b/drivers/clk/sunxi/clk-simple-gates.c
>> index 0214c6548afd..5666c767fa14 100644
>> --- a/drivers/clk/sunxi/clk-simple-gates.c
>> +++ b/drivers/clk/sunxi/clk-simple-gates.c
>> @@ -112,6 +112,8 @@ CLK_OF_DECLARE(sun5i_a13_apb0, 
>> "allwinner,sun5i-a13-apb0-gates-clk",
>>sunxi_simple_gates_init);
>>  CLK_OF_DECLARE(sun5i_a13_apb1, "allwinner,sun5i-a13-apb1-gates-clk",
>>sunxi_simple_gates_init);
>> +CLK_OF_DECLARE(sun5i_a13_dram, "allwinner,sun5i-a13-dram-gates-clk",
>> +  sunxi_simple_gates_init);

Nit: Since the compatible added is sun5i, could you mention it in the
commit message,
to avoid confusion when we do this for the other families?

Thanks

>>  CLK_OF_DECLARE(sun6i_a31_ahb1, "allwinner,sun6i-a31-ahb1-gates-clk",
>>sunxi_simple_gates_init);
>>  CLK_OF_DECLARE(sun6i_a31_apb1, "allwinner,sun6i-a31-apb1-gates-clk",
>> --
>> 2.6.2
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] driver-core: platform: probe of-devices only using list of compatibles

[Uwe Kleine-König]

There are several indications that make a platform device match a
platform driver. For devices that are instantiated by a device tree
matching by name, id table or acpi mechanisms doesn't make sense and
might result in surprising effects. So limit matching to use the
driver's of_match_table for these.

Acked-by: Thierry Reding 
Signed-off-by: Uwe Kleine-König 
---
Hello,

this issue popped up when it was discussed if of_match_device could
return NULL for several different drivers:

http://mid.gmane.org/20151112082617.ge24...@pengutronix.de
http://mid.gmane.org/20151112074447.ga24...@pengutronix.de
http://mid.gmane.org/20151112134519.gj24...@pengutronix.de

(and probably more that I'm not aware of). IMHO this doesn't make these
fixes obsolete, but YMMV.

Thierry: You gave your ack before I wrote a commit log. I added it
nevertheless and hope that's ok for you. If not please say so.

Best regards
Uwe

 drivers/base/platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 1dd6d3bf1098..09b2972e60d7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -900,8 +900,8 @@ static int platform_match(struct device *dev, struct 
device_driver *drv)
return !strcmp(pdev->driver_override, drv->name);
 
/* Attempt an OF style match first */
-   if (of_driver_match_device(dev, drv))
-   return 1;
+   if (pdev->dev.of_node)
+   return of_driver_match_device(dev, drv);
 
/* Then try ACPI style match */
if (acpi_driver_match_device(dev, drv))
-- 
2.6.1

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

Conditionals in dtsi files

[Mason]

Hello,

I'm wondering how much C preprocessor syntax one can use in DT files.

Suppose I have 2 board DTS (both including common.dtsi)

board_A.dts (1-core), board_B.dts (2-core)

Can I have in common.dtsi something along these lines:

cpus {
enable-method = "foo,bar";
#address-cells = <1>;
#size-cells = <0>;

cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
};

#if CORE_COUNT > 1
cpu1: cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
};
#endif
};


board_A.dts would have
#define CORE_COUNT 1
#include "common.dtsi"

board_B.dts would have
#define CORE_COUNT 2
#include "common.dtsi"

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

Re: [PATCH v2 1/4] iio: adc: add IMX7D ADC driver support

[Haibo Chen]

On Tue, Nov 10, 2015 at 03:58:14PM +0100, Lars-Peter Clausen wrote:
> On 11/09/2015 02:28 PM, Haibo Chen wrote:
> > Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> > driver support, and the driver only support ADC software trigger.
> > 
> > Signed-off-by: Haibo Chen 
> 
> Looks pretty good, a few comments inline.
> 
> [...]
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> I don't think you need all of these.
> 
> [...]

Yes, I will remove delay.h slab.h of_irq.h and of_platform.h

> > +static void imx7d_adc_feature_config(struct imx7d_adc *info)
> > +{
> > +   info->adc_feature.clk_pre_div = IMX7D_ADC_ANALOG_CLK_PRE_DIV_4;
> > +   info->adc_feature.avg_num = IMX7D_ADC_AVERAGE_NUM_32;
> > +   info->adc_feature.core_time_unit = 1;
> > +   info->adc_feature.average_en = true;
> 
> What's the plan for these? Right now they are always initialized to the same
> static value.
> 

In future, we can get these values from dts file, currently we just use the 
static value.

> 
> > +}
> [...]
> > +static int imx7d_adc_read_raw(struct iio_dev *indio_dev,
> > +   struct iio_chan_spec const *chan,
> > +   int *val,
> > +   int *val2,
> > +   long mask)
> > +{
> > +   struct imx7d_adc *info = iio_priv(indio_dev);
> > +
> > +   u32 channel;
> > +   long ret;
> > +
> > +   switch (mask) {
> > +   case IIO_CHAN_INFO_RAW:
> > +   mutex_lock(_dev->mlock);
> > +   reinit_completion(>completion);
> > +
> > +   channel = (chan->channel) & 0x0f;
> > +   info->channel = channel;
> > +   imx7d_adc_channel_set(info);
> 
> How about just passing channel directy adc_channel_set() instead of doing it
> implicitly through the info struct?
> 

I think there is no difference, besides, using this parameter info struct can 
keep align with other functions.
eg.  imx7d_adc_sample_set(), imx7d_adc_hw_init(), imx7d_adc_get_sample_rate(), 
all these functions have the same parameter.

> [...]
> > +static irqreturn_t imx7d_adc_isr(int irq, void *dev_id)
> > +{
> > +   struct imx7d_adc *info = (struct imx7d_adc *)dev_id;
> > +   int status;
> > +
> > +   status = readl(info->regs + IMX7D_REG_ADC_INT_STATUS);
> > +   if (status & IMX7D_REG_ADC_INT_STATUS_CHANNEL_INT_STATUS) {
> > +   info->value = imx7d_adc_read_data(info);
> > +   complete(>completion);
> > +   }
> > +   writel(0, info->regs + IMX7D_REG_ADC_INT_STATUS);
> 
> Is the hardware really this broken? If the interrupt happens between reading
> the status register and clearing it here it will be missed.
> 

I think interrupt can't happen between reading the status register and clearing 
it.
Because in function imx7d_adc_read_raw(), we call the function 
imx7d_adc_channel_set(info), in this function, we config the register
REG_ADC_CH_A\B\C\D_CFG1 and REG_ADC_CH_A\B\C\D_CFG2, only when these registers
is configed, ADC start a conversion. Once the conversion complete, ADC trigger 
an 
interrupt, and call the imx7d_adc_isr().

> > +
> > +   return IRQ_HANDLED;
> 
> You should only return IRQ_HANDLED if you actually handled are interrupt.
> 

Here in the interrupt, we just handle the channel conversion finished flag, for
other flag, ignore them this time, Will add other flag in future.

> > +}
> [...]
> > +
> > +static int imx7d_adc_probe(struct platform_device *pdev)
> > +{
> > +   struct imx7d_adc *info;
> > +   struct iio_dev *indio_dev;
> > +   struct resource *mem;
> > +   int irq;
> > +   int ret;
> > +   u32 channels;
> > +
> > +   indio_dev = devm_iio_device_alloc(>dev, sizeof(struct imx7d_adc));
> > +   if (!indio_dev) {
> > +   dev_err(>dev, "Failed allocating iio device\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +   info = iio_priv(indio_dev);
> > +   info->dev = >dev;
> > +
> > +   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   info->regs = devm_ioremap_resource(>dev, mem);
> > +   if (IS_ERR(info->regs)) {
> > +   ret = PTR_ERR(info->regs);
> > +   dev_err(>dev, "failed to remap adc memory: %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   irq = platform_get_irq(pdev, 0);
> > +   if (irq < 0) {
> > +   dev_err(>dev, "no irq resource?\n");
> > +   return irq;
> > +   }
> > +
> > +   ret = devm_request_irq(info->dev, irq,
> > +   imx7d_adc_isr, 0,
> > +   dev_name(>dev), info);
> 
> This is too early. Completion is not initialized, clocks are not enabled, 
> etc...
> 

You are right, I will move the request irq function down.
> > +   if (ret < 0) {
> > +   dev_err(>dev, "failed requesting irq, irq = %d\n", irq);
> > +   return ret;
> > +   }
> > +
> [...]
> > +   ret  = of_property_read_u32(pdev->dev.of_node,
> 

Re: [PATCH v2 1/4] iio: adc: add IMX7D ADC driver support

[Lars-Peter Clausen]

On 11/13/2015 10:39 AM, Haibo Chen wrote:
[...]
>>> +static void imx7d_adc_feature_config(struct imx7d_adc *info)
>>> +{
>>> +   info->adc_feature.clk_pre_div = IMX7D_ADC_ANALOG_CLK_PRE_DIV_4;
>>> +   info->adc_feature.avg_num = IMX7D_ADC_AVERAGE_NUM_32;
>>> +   info->adc_feature.core_time_unit = 1;
>>> +   info->adc_feature.average_en = true;
>>
>> What's the plan for these? Right now they are always initialized to the same
>> static value.
>>
> 
> In future, we can get these values from dts file, currently we just use the 
> static value.

Those seem to be software configuration values though, not part of hardware
description.

> 
>>
>>> +}
>> [...]
>>> +static int imx7d_adc_read_raw(struct iio_dev *indio_dev,
>>> +   struct iio_chan_spec const *chan,
>>> +   int *val,
>>> +   int *val2,
>>> +   long mask)
>>> +{
>>> +   struct imx7d_adc *info = iio_priv(indio_dev);
>>> +
>>> +   u32 channel;
>>> +   long ret;
>>> +
>>> +   switch (mask) {
>>> +   case IIO_CHAN_INFO_RAW:
>>> +   mutex_lock(_dev->mlock);
>>> +   reinit_completion(>completion);
>>> +
>>> +   channel = (chan->channel) & 0x0f;
>>> +   info->channel = channel;
>>> +   imx7d_adc_channel_set(info);
>>
>> How about just passing channel directy adc_channel_set() instead of doing it
>> implicitly through the info struct?
>>
> 
> I think there is no difference, besides, using this parameter info struct can 
> keep align with other functions.
> eg.  imx7d_adc_sample_set(), imx7d_adc_hw_init(), 
> imx7d_adc_get_sample_rate(), all these functions have the same parameter.
> 
>> [...]
>>> +static irqreturn_t imx7d_adc_isr(int irq, void *dev_id)
>>> +{
>>> +   struct imx7d_adc *info = (struct imx7d_adc *)dev_id;
>>> +   int status;
>>> +
>>> +   status = readl(info->regs + IMX7D_REG_ADC_INT_STATUS);
>>> +   if (status & IMX7D_REG_ADC_INT_STATUS_CHANNEL_INT_STATUS) {
>>> +   info->value = imx7d_adc_read_data(info);
>>> +   complete(>completion);
>>> +   }
>>> +   writel(0, info->regs + IMX7D_REG_ADC_INT_STATUS);
>>
>> Is the hardware really this broken? If the interrupt happens between reading
>> the status register and clearing it here it will be missed.
>>
> 
> I think interrupt can't happen between reading the status register and 
> clearing it.
> Because in function imx7d_adc_read_raw(), we call the function 
> imx7d_adc_channel_set(info), in this function, we config the register
> REG_ADC_CH_A\B\C\D_CFG1 and REG_ADC_CH_A\B\C\D_CFG2, only when these registers
> is configed, ADC start a conversion. Once the conversion complete, ADC 
> trigger an 
> interrupt, and call the imx7d_adc_isr().

Well an interrupt can always happen, its running fully asynchronous to the
CPU. If you have multiple interrupt sources enabled and the first one fires
and you run then start the irq handler, read the status register, now the
second irq sources fires, and then you clear the status interrupt register.
This means the driver will not see the irq from the second source.

> 
>>> +
>>> +   return IRQ_HANDLED;
>>
>> You should only return IRQ_HANDLED if you actually handled are interrupt.
>>
> 
> Here in the interrupt, we just handle the channel conversion finished flag, 
> for
> other flag, ignore them this time, Will add other flag in future.

Yeah, but if you don't handle any interrupt you should return IRQ_NONE. This
will make sure that the system can recover in case the hardware (or the
driver) is broken and generates unexpected interrupts. If there are a 1000
or so IRQ_NONEs in a row in a short time frame the kernel will disable the IRQ.

>> [...]
>>> +   ret  = of_property_read_u32(pdev->dev.of_node,
>>
>> Extra space.
>>
>>> +   "num-channels", );
>>
>> What decides how many channels are in use?
>>
> 
> The board decides the channel number.
> In dts file, there is a line: num-channels = <4>;

Yes, but what decides how this property should be configured?

> 
> 
>>> +   if (ret)
>>> +   channels = ARRAY_SIZE(imx7d_adc_iio_channels);
>>> +
>>> +   indio_dev->name = dev_name(>dev);
>>> +   indio_dev->dev.parent = >dev;
>>> +   indio_dev->dev.of_node = pdev->dev.of_node;
>>> +   indio_dev->info = _adc_iio_info;
>>> +   indio_dev->modes = INDIO_DIRECT_MODE;
>>> +   indio_dev->channels = imx7d_adc_iio_channels;
>>> +   indio_dev->num_channels = (int)channels;
>>
>> I don't think you need the case here.
>>
> 
> Sorry, can't get your point, you mean I should not indio_dev-> ?

Sorry, I meant the (int) cast.

> 
>>> [...]
> 

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

Re: [PATCH v2 0/5] arm: dts: complete dm816x device tree

[Neil Armstrong]

On 11/12/2015 06:47 PM, Tony Lindgren wrote:
> * Neil Armstrong  [151112 06:08]:
>> In order to fix support for the dm816x platform, add missing bits in
>> the dm816x dtsi and cleanup OCP.
> 
> Which ones are needed as fixes for the v4.4-rc kernel?
> 
> Regards,
> 
> Tony
> 
>> The last patch adds support for the omap4-hwspinlock.
>>
>> v2: add ocp hwmod cleanup
>>
>> Neil Armstrong (5):
>>   arm: dts: add dm816x missing #mbox-cells
>>   arm: dts: add dm816x missing spi DT dma handles
Tony,

The two first are fixes for v4.4-rc.

>>   arm: dts: add dm816x pwm property to timers
>>   arm: dts: remove dm816x invalid DT l3_main hwmod
>>   arm: dts: Add omap4-hwspinlock support in dm816x

the 3 following can wait.

>>
>>  arch/arm/boot/dts/dm816x.dtsi | 20 +---
>>  1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> -- 
>> 1.9.1

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

Re: Conditionals in dtsi files

[Arnd Bergmann]

On Friday 13 November 2015 10:33:50 Mason wrote:
> Hello,
> 
> I'm wondering how much C preprocessor syntax one can use in DT files.
> 
> Suppose I have 2 board DTS (both including common.dtsi)
> 
> board_A.dts (1-core), board_B.dts (2-core)
> 
> Can I have in common.dtsi something along these lines:
> 
>   cpus {
>   enable-method = "foo,bar";
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   cpu0: cpu@0 {
>   compatible = "arm,cortex-a9";
>   device_type = "cpu";
>   reg = <0>;
>   };
> 
> #if CORE_COUNT > 1
>   cpu1: cpu@1 {
>   compatible = "arm,cortex-a9";
>   device_type = "cpu";
>   reg = <1>;
>   };
> #endif
>   };
> 
> 
> board_A.dts would have
> #define CORE_COUNT 1
> #include "common.dtsi"
> 
> board_B.dts would have
> #define CORE_COUNT 2
> #include "common.dtsi"

I would prefer not using any preprocessor statements other than
#include in .dts files. It's easy enough to have a per-soc
.dtsi file that defines the CPU nodes and goes on to include another
.dtsi file with the common parts that are present on all SoCs.

Have a look at how the armada-*.dtsi files handle this.

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

Re: [PATCH v8 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Rob Herring]

On Thu, Nov 12, 2015 at 7:12 AM, Pavel Fedin  wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.
>
> Also, fix size of SROMc mapping in the example.
>
> Signed-off-by: Pavel Fedin 
> Reviewed-by: Krzysztof Kozlowski 

Acked-by: Rob Herring 

One nit below.

> compatible = "samsung,exynos-srom";
> -   reg = <0x1257 0x10>;
> +   reg = <0x1257 0x14>;
> +
> +   ethernet@3 {

This should actually be "ethernet@3,0"

Fields (not cells) in the unit address should be separated by commas.

> +   compatible = "smsc,lan9115";
> +   reg = <3 0 0x1>;   // Bank 3, offset = 0
> +   phy-mode = "mii";
> +   interrupt-parent = <>;
> +   interrupts = <5 8>;
> +   reg-io-width = <2>;
> +   smsc,irq-push-pull;
> +   smsc,force-internal-phy;
> +
> +   samsung,srom-page-mode = <1>;
> +   samsung,srom-timing = <9 12 1 9 1 1>;
> +   };
> };
> --
> 2.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Thierry Reding]

On Wed, Nov 04, 2015 at 01:54:15PM -0700, Stephen Warren wrote:
> On 11/04/2015 10:11 AM, Thierry Reding wrote:
> >From: Thierry Reding 
> >
> >The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> >set of lanes that are used for PCIe, SATA and USB.
> 
> >  .../bindings/phy/nvidia,tegra-xusb-padctl.txt  | 359 
> > +
> 
> For Tegra bindings, we usually use the full compatible value as the
> filename, so I'd expect the chip number in the filename too.

I specifically didn't do that to avoid confusion. The XUSB pad
controller was introduced on Tegra114, but patches weren't posted until
Tegra124. So nvidia,tegra114-xusb-padctl.txt would be the proper name
for this binding if we were following the conventions, but then we have
never specified that binding (though I think it would look mostly the
same as for Tegra124).

I can of course still go for nvidia,tegra114-xusb-padctl.txt, the
content would explicitly list valid compatible strings. It's just that
none of them would match the filename.

> I'd expect to see a patch in this series that edits the existing
> Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
> and mentions that the binding is deprecated.

How about this:

--- >8 ---
diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
index 30676ded85bb..77dfba05ccfd 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
@@ -1,6 +1,11 @@
 Device tree binding for NVIDIA Tegra XUSB pad controller
 
 
+NOTE: It turns out that this binding isn't an accurate description of the XUSB
+pad controller. While the description is good enough for the functional subset
+required for PCIe and SATA, it lacks the flexibility to represent the features
+needed for USB. For the new binding, see ../phy/nvidia,tegra-xusb-padctl.txt.
+
 The Tegra XUSB pad controller manages a set of lanes, each of which can be
 assigned to one out of a set of different pads. Some of these pads have an
 associated PHY that must be powered up before the pad can be used.
--- >8 ---

> >diff --git 
> >a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt 
> >b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt
> >+- reg: Physical base address and length of the controller's registers.
> >+- resets: Must contain an entry for each entry in reset-names.
> >+- reset-names: Must include the following entries:
> >+  - "padctl"
> 
> Are there no clocks or power domains that affect XUSB padctl? I suppose we
> can start off without any, and add them later if we need.

I don't think there are any. The TRM specifies that it's in the ungated
Vaux_soc power partition, and doesn't mention any clocks.

> >+- mboxes: Must contain an entry for each entry in mbox-names.
> >+- mbox-names: Must include the following entries:
> >+  - "xusb"
> 
> I thought we'd decided not to use any mbox binding or drivers in XUSB now?
> See for example my proposed XUSB controller binding at:
> 
> http://www.spinics.net/lists/linux-tegra/msg23922.html
> [PATCH V9] dt: add NVIDIA Tegra XUSB controller binding
> 
> The idea is that the mailbox should be entirely internal to the XUSB
> controller driver, and if the receipt of a mailbox message requires any
> change in the XUSB pad controller programming, the XUSB controller driver
> should simply call the XUSB pad controller driver to perform that operation.

Okay, I think that should work, but it'll require a rather large rewrite
of... well, everything. I think Martyn was going to look into that, so I
guess I'll just drop this for now.

Instead I think we'll need a phandle to the XUSB pad controller, so that
we can resolve it to the proper context. Something like this perhaps?

- nvidia,padctl: phandle to the XUSB pad controller that is used
  to configure the USB pads used by the XHCI controller.

That should of course go into the XHCI controller binding. The nice
thing about this would be that we get rid of the circular dependency
XHCI -> padctl -> mailbox -> XHCI.

> >+Pad nodes:
> >+==
> 
> >+For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie
> >+and sata. No extra resources are required for operation of these pads.
> 
> Judging by the diagram in the TRM (e.g. figure 41 in the Tegra124 TRM,
> figure 36 in the Tegra210 TRM), there is not a single "utmi" pad, but rather
> a separate pad per USB2 lane. However, the other types of pads are indeed
> multi-lane. The TRM also refers to "USB2" pads rather than "UTMI" pads. I
> don't see a ULPI pad in the diagram either. Assuming the diagram in the TRM
> is consistent with the register layout, I think we should have the following
> set of pad nodes:
> 
> 

[PATCH v3] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro

[Andrew F. Davis]

Using constants for pinctrl allows better readability and removes
redundancy with comments. AM33XX_IOPAD allows us to use part of the
pinctrl physical address as in the TRM instead of an offset.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index eadbba3..55c0e95 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -36,32 +36,32 @@
 _pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
-   0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
AM33XX_PIN_OUTPUT */
-   0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc8 0x08   /* lcd_data10.lcd_data10, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xcc 0x08   /* lcd_data11.lcd_data11, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd0 0x08   /* lcd_data12.lcd_data12, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd4 0x08   /* lcd_data13.lcd_data13, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd8 0x08   /* lcd_data14.lcd_data14, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xdc 0x08   /* lcd_data15.lcd_data15, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
AM33XX_PIN_OUTPUT */
-   0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
+   AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr0 */
+   AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data0.lcd_data0 */
+   AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data1.lcd_data1 */
+   AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data2.lcd_data2 */
+   AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data3.lcd_data3 */
+   AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data4.lcd_data4 */
+   AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data5.lcd_data5 */
+   AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data6.lcd_data6 */
+   AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data7.lcd_data7 */
+   AM33XX_IOPAD(0x8c0, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data8.lcd_data8 */
+   AM33XX_IOPAD(0x8c4, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data9.lcd_data9 */
+   AM33XX_IOPAD(0x8c8, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data10.lcd_data10 */
+   AM33XX_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data11.lcd_data11 */
+   AM33XX_IOPAD(0x8d0, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data12.lcd_data12 */
+   AM33XX_IOPAD(0x8d4, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data13.lcd_data13 */
+   AM33XX_IOPAD(0x8d8, PIN_OUTPUT | MUX_MODE0) 
/* lcd_data14.lcd_data14 */
+ 

Re: [PATCH] net: hisilicon: fix binding document of mdio

[Arnd Bergmann]

On Friday 13 November 2015 08:44:57 Rob Herring wrote:
> 
> Please reformat like this:
> 
> - compatible: can be one of:
> "hisilicon,hns-mdio"
> "hisilicon,mdio"
>   For hip04 board, must be "hisilicon,mdio".
>   Otherwise, must be "hisilicon,hns-mdio".

should we recommend the use of "hisilicon,hns-mdio" unconditionally
and only list "hisilicon,mdio" for backwards compatibility?

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

Re: [PATCH 1/2] ARM: ux500: remove regulator-compatible usage

[Javier Martinez Canillas]

Hello,

On 09/25/2015 09:51 AM, Javier Martinez Canillas wrote:
> The regulator-compatible property from the regulator DT binding was
> deprecated and the correct approach is to use the node's name.
> 
> This patch has no functional changes since the values of the node's
> name and the regulator-compatible match for all the regulators.
> 
> Signed-off-by: Javier Martinez Canillas 
> 

Any comments about this patch?

Same question about patch 2/2: https://lkml.org/lkml/2015/9/25/288

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MAINTAINERS: update DT binding doc locations

[Philipp Zabel]

Am Donnerstag, den 05.11.2015, 13:41 -0600 schrieb Rob Herring:
> After the recent moving of DT binding documents, some maintainers entries
> are stale. Update them to the new locations.
> 
> In bindings/fb/, there were only 2 files and I'm assuming the FB
> maintainers don't want to be copied on all of bindings/display/. So I've
> dropped them.
> 
> Reported-by: Thierry Reding 
> Cc: Thierry Reding 
> Cc: Jianwei Wang 
> Cc: Alison Wang 
> Cc: Philipp Zabel 

Acked-by: Philipp Zabel 

regards
Philipp

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

Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

[Tony Lindgren]

* Vinod Koul  [151104 08:38]:
> On Wed, Nov 04, 2015 at 10:33:27AM -0600, Felipe Balbi wrote:
> > Peter Ujfalusi  writes:
> > 
> > > The eDMA3 TPTC does not need any software configuration, but it is a
> > > separate IP block in the SoC. In order the omap hwmod core to be able to
> > > handle the TPTC resources correctly in regards of PM we need to have a
> > > driver loaded for it.
> > > This patch will add a dummy driver skeleton without probe or remove
> > > callbacks provided.
> > >
> > > Signed-off-by: Peter Ujfalusi 
> > > Reported-by: Olof Johansson 
> > 
> > This fixes the problem I also reported on linux-omap [1]
> > 
> > Tested-by: Felipe Balbi 
> > 
> > [1] http://marc.info/?l=linux-omap=144665429032014=2
> 
> Great, I was about to point you to this series, I will push this in -next
> now

Soungd good to me, thanks for fixing it up Peter.

Tony


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

Re: [PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Enric Balletbo Serra]

Hi Rob,

2015-11-13 15:38 GMT+01:00 Rob Herring :
> On Fri, Nov 13, 2015 at 01:01:02PM +0100, Enric Balletbo i Serra wrote:
>> Analogix Semiconductor develops analog and mixed-signal devices for digital
>> media and communications interconnect applications.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> Acked-by: Rob Herring 
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
>> b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 82d2ac9..8987ee8 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -22,6 +22,7 @@ ampire  Ampire Co., Ltd.
>>  ams  AMS AG
>>  amstaos  AMS-Taos Inc.
>>  apm  Applied Micro Circuits Corporation (APM)
>> +analogix Analogix Semiconductor, Inc.
>
> Not quite alphabetical order.
>

Yep, sorry, I think I introduced this mistake rebasing my patches  ...
I will fix in next version, thanks.

>>  aptina   Aptina Imaging
>>  arasan   Arasan Chip Systems
>>  arm  ARM Ltd.
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Thierry Reding]

On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote:
> On 11/04/2015 10:11 AM, Thierry Reding wrote:
> >From: Thierry Reding 
> >
> >Extend the binding to cover the set of feature found in Tegra210.
> 
> >diff --git 
> >a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt 
> >b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt
> 
> >+PCIe pad:
> >+-
> >+
> >+Required properties:
> >+- clocks: Must contain an entry for each entry in clock-names.
> >+- clock-names: Must contain the following entries:
> >+  - "pll": phandle and specifier referring to the PLLE
> >+- resets: Must contain an entry for each entry in reset-names.
> >+- reset-names: Must contain the following entries:
> >+  - "phy": reset for the PCIe UPHY block
> 
> I don't recall any clocks or resets properties in the pads for Tegra124. Do
> we really not need any?

Tegra124 had two instances of what used to be called IOPHY, one for PCIe
and one for SATA. On Tegra210 these have been replaced by two instances
of what's called UPHY. The resets listed in the PCIe and SATA pad nodes
are wired to those UPHY instances, hence why they are new on Tegra210.

For Tegra124 no resets exist for the IOPHY instances.

> >+SATA pad:
> >+-
> >+
> >+Required properties:
> >+- resets: Must contain an entry for each entry in reset-names.
> >+- reset-names: Must contain the following entries:
> >+  - "phy": reset for the SATA UPHY block
> >+
> >
> >  PHY nodes:
> 
> Nit: 2 blank lines there.

Those were intentional for additional spacing between sections.

> >+For Tegra210, the list of valid PHY nodes is given below:
> >+- utmi: utmi-0, utmi-1, utmi-2, utmi-3
> >+  - functions: "snps", "xusb", "uart"
> >+- hsic: hsic-0, hsic-1
> >+  - functions: "snps", "xusb"
> >+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
> >+  - functions: "pcie-x1", "usb3-ss", "pcie-x4"
> >+- sata: sata-0
> >+  - functions: "usb3-ss", "sata"
> 
> usb2-bias also needs to be present.

I'm not sure about this. All of the driver code that I've looked deals
with the usb2-bias pad internally. As far as I can tell, this pad needs
to be configured to whatever any of the other pads is configured for. I
think that means if any of the UTMI pads is configured for XUSB then the
usb2-bias pad must also be configured for XUSB. Which would also imply
that if one of the UTMI pads is configured for XUSB, all of them must be
configured for XUSB.

It's also not a pad in the sense that the others are pads. It doesn't
directly connect anywhere. It's also shared by all the UTMI pads. That
said, there are two registers that allow some of the parameters of the
pad to be set, so perhaps adding the node exclusively for
configurability might make sense.

It wouldn't really be a PHY node, though, so wouldn't fit into the above
group. Perhaps something like the following could be added:

  There is an additional pad that is used to support the bias voltages
  to the USB2/UTMI pads. This is not a PHY that can be consumed by any
  I/O controller, but the device tree node can be used to specify
  parameters needed for the programming of the pad.

I think the function shouldn't necessarily be exposed as a parameter,
because all that would do is add the possibility for a conflicting set
of mux options with the USB2/UTMI pads.

> >+
> >+
> >  Port nodes:
> >  ===
> 
> Nit: 2 blank lines there.
> 
> >+For Tegra210, the XUSB pad controller exposes the following ports:
> >+- 4x UTMI: utmi-0, utmi-1, utmi-2, utmi-3
> >+- 2x HSIC: hsic-0, hsic-1
> >+- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
> >+
> >
> >  Examples:
> >  =
> 
> Nit: 2 blank lines there.

Again, those were intentional for readability. I can remove them if you
don't think they fulfil that purpose.

Thierry


signature.asc
Description: PGP signature

Question about usdpaa device tree (arch/powerpc/boot/dts/t4240rdb-usdpaa.dts)

[Huimin She]

Hi all,


In the device tree t4240rdb-usdpaa.dts 
(http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tree/arch/powerpc/boot/dts/t4240rdb-usdpaa.dts)
All the ethernet interfaces are dedicated for use by usdpaa. So that they are 
NOT visible to Linux kernel network stack. This brings inconvenience
for development.

On p4080ds board, I noticed that ethernet@1 is used as a normal Linux ethernet 
for kernel network stack.
(http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tree/arch/powerpc/boot/dts/p4080ds-usdpaa.dts)
This seems to be more convenient for development (such as booting board through 
nfs, ssh login, and so on) 

Can we reserve one or more 1G interfaces for Linux kernel network on t4240rdb 
(applicable to several other targets as well)?

Thanks a lot.

Best regards,
Huimin She

Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

[Cyrille Pitchen]

Hi Brian,

Le 11/11/2015 08:20, Brian Norris a écrit :
> Hi,
> 
> On Wed, Nov 11, 2015 at 12:20:46PM +0530, R, Vignesh wrote:
>> On 11/11/2015 4:53 AM, Brian Norris wrote:
>>> On Tue, Nov 10, 2015 at 10:59:55AM +0530, Vignesh R wrote:
 diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
 index cce80e6dc7d1..2f2c431b8917 100644Hi
 --- a/include/linux/spi/spi.h
 +++ b/include/linux/spi/spi.h
 @@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct 
 spi_driver *sdrv)
   * @handle_err: the subsystem calls the driver to handle an error that 
 occurs
   *in the generic implementation of transfer_one_message().
   * @unprepare_message: undo any work done by prepare_message().
 + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory.
 + * Flash drivers (like m25p80) can request memory
 + * mapped read via this method. This interface
 + * should only be used by mtd flashes and cannot be
 + * used by other spi devices.
   * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
   *number. Any individual value may be -ENOENT for CS lines that
   *are not GPIOs (driven by the SPI controller itself).
 @@ -507,6 +512,11 @@ struct spi_master {
   struct spi_message *message);
int (*unprepare_message)(struct spi_master *master,
 struct spi_message *message);
 +  int (*spi_mtd_mmap_read)(struct  spi_device *spi,
 +   loff_t from, size_t len,
 +   size_t *retlen, u_char *buf,
 +   u8 read_opcode, u8 addr_width,
 +   u8 dummy_bytes);
>>>
>>> Is this API really sufficient? There are actually quite a few other
>>> flash-related parameters that might be relevant to a controller. I
>>> presume you happen not hit them because of the particular cases you're
>>> using this for right now, but:
>>>
>>>  * How many I/O lines are being used? These can vary depending on the
>>>type of flash and the number of I/O lines supported by the controller
>>>and connected on the board.
>>>
>>
>> This API communicates whatever data is currently communicated via
>> spi_message through spi_sync/transfer_one interfaces.
> 
> No it doesn't. A spi_message consists of a list of spi_transfer's, and
> each spi_transfer has tx_nbits and rx_nbits fields.
> 
>>>  * The previous point can vary across parts of the message. There are
>>>various combinations of 1/2/4 lines used for opcode/address/data. We
>>>only support a few of those combinations in m25p80 right now, but
>>>you're not specifying any of that in this API. I guess you're just
>>>making assumptions? (BTW, I think there are others having problems
>>>with the difference between different "quad" modes on Micron flash; I
>>>haven't sorted through all the discussion there.)
>>>
>>
>> How is the spi controller currently being made aware of this via
>> m25p80_read / spi_sync() interface? AFAIK, mode field of spi_device
>> struct tell whether to do normal/dual/quad read but there is no info
>> communicated wrt 1/2/4 opcode/address/data combinations.
> 
> Yes there is. m25p80 fills out spi_transfer::rx_nbits. Currently, we
> only use this for the data portion, but it's possible to support more
> lines for the address and opcode portions too, using the rx_nbits for
> the opcode and address spi_transfer struct(s) (currently, m25p80_read()
> uses 2 spi_transfers per message, where the first one contains opcode +
> address + dummy on a single line, and the second transfer receives the
> data on 1, 2, or 4 lines).
> 

In September I've sent a series of patches to enhance the support of QSPI flash
memories. Patch 4 was dedicated to the m25p80 driver and set the
rx_nbits / tx_nbits fields of spi_transfer struct(s) in order to configure the
number of I/O lines independently for the opcode, address and data parts.
The work was done for m25p80_read() but also for _read_reg(), _write_reg() and
_write().
The patched m25p80 driver was then tested with an at25 memory to check non-
regression.

This series of patches also added 4 enum spi_protocol fields inside struct
spi_nor so the spi-nor framework can tell the (Q)SPI controller driver what SPI
protocol should be use for erase, read, write and register read/write
operations, depending on the memory manufacturer and the command opcode.
This was done to better support Micron, Spansion and Macronix QSPI memories.

I have tested the series with Micron QSPI memories and Atmel QSPI controller
and I guess Marek also tested it on his side with Spansion QSPI memories and
another QSPI controller.

So if it can help other developers to develop QSPI controller drivers, the
series is still available there:

for the whole series:

Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Andrew Bresticker]

On Fri, Nov 13, 2015 at 8:32 AM, Thierry Reding
 wrote:
> On Wed, Nov 04, 2015 at 01:59:51PM -0700, Stephen Warren wrote:
>> On 11/04/2015 10:11 AM, Thierry Reding wrote:
>> >From: Thierry Reding 
>> >
>> >Extend the binding to cover the set of feature found in Tegra210.
>>
>> >diff --git 
>> >a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt 
>> >b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt
>>
>> >+For Tegra210, the list of valid PHY nodes is given below:
>> >+- utmi: utmi-0, utmi-1, utmi-2, utmi-3
>> >+  - functions: "snps", "xusb", "uart"
>> >+- hsic: hsic-0, hsic-1
>> >+  - functions: "snps", "xusb"
>> >+- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
>> >+  - functions: "pcie-x1", "usb3-ss", "pcie-x4"
>> >+- sata: sata-0
>> >+  - functions: "usb3-ss", "sata"
>>
>> usb2-bias also needs to be present.
>
> I'm not sure about this. All of the driver code that I've looked deals
> with the usb2-bias pad internally. As far as I can tell, this pad needs
> to be configured to whatever any of the other pads is configured for. I
> think that means if any of the UTMI pads is configured for XUSB then the
> usb2-bias pad must also be configured for XUSB. Which would also imply
> that if one of the UTMI pads is configured for XUSB, all of them must be
> configured for XUSB.

I was told by hardware engineers at NVIDIA that (at least on
Tegra124/Tegra132) the usb2-bias pad must be configured in the
XUSB_PADCTL register space if UTMI pad 0 is muxed to XUSB.  If UTMI
pad 0 is muxed to SNPS, then the usb2-bias pad is configured in the
USB register space (base 0x7d00).  You may want to follow up
internally to confirm this.  If it's true, that could make things here
a bit nastier, especially if we want to support configurations where
some pads are muxed to XUSB while others are muxed to SNPS.

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

Re: [PATCH v6 1/3] doc: dt: add documentation for Mediatek spi-nor controller

[Brian Norris]

On Fri, Nov 13, 2015 at 03:20:45PM +0800, Bayi Cheng wrote:
> On Wed, 2015-11-11 at 12:38 -0800, Brian Norris wrote:
> > Applied to l2-mtd.git/next (for 4.5). This will show up in
> > linux-next.git after the merge window.
> > 
> > Also squashed in a small diff (below), to fix up some language issues
> > and to refer the reader to the jedec,spi-nor.txt document.
> > 
> 
> OK, I will fix it in next patch!

No, you don't need to send another patch. I already merged just this one
(the DT documentation) with my own small fixes, with a plan to go into
4.5. You only need to send another version of patch 2 (the driver).

During the merge window, I'm stashing changes in l2-mtd.git's 'next'
branch, so we can keep stuff that's going to 4.5 separate from stuff
thats getting merged to 4.4 right now. You can see it here for now:

http://git.infradead.org/l2-mtd.git/shortlog/refs/heads/next

After the merge window closes (probably on Sunday), I'll bring this into
+master.

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

Re: [PATCH v2 0/8] arm: dts: lpc32xx: updates to LPC32xx SoC and boards

[Arnd Bergmann]

On Friday 13 November 2015 22:20:26 Vladimir Zapolskiy wrote:
> On 08.11.2015 17:39, Vladimir Zapolskiy wrote:
> > On 21.10.2015 17:45, Arnd Bergmann wrote:
> >> On Sunday 18 October 2015 00:35:49 Vladimir Zapolskiy wrote:
> >>> The change improves description of NXP LPC32xx hardware, among
> >>> important changes it adds standard timers and external memory
> >>> controller nodes, splits PWM device node into two,
> >>>
> >>> Changes from v1 to v2:
> >>> - removed v1 2/5 "arm: dts: lpc32xx: fix improper usage of ranges 
> >>> property"
> >>> - v1 4/5 "arm: dts: lpc32xx: remove unneeded cell settings from cpus"
> >>>   is replaced by v2 3/8 "arm: dts: lpc32xx: add reg property to cpu 
> >>> device node"
> >>> - new change, sets physical memory offset for EA3250 and PHY3250 v5/8
> >>> - new change, added EMC device node v2 6/8
> >>> - new change, added standard timer nodes v2 7/8
> >>> - new change, grouped USB subdevices together v2 8/8
> >>
> >> Looks ok to me. Who should pick them up? I haven't seen pull requests from
> >> Roland in a while. If he's still interested in the port, I think it would 
> >> be
> >> best if he could create a branch here.
> >>
> >> If not, we can pick them up directly this time into arm-soc, but then we
> >> should find a new maintainer.
> >>
> > 
> > please pick this series up for v4.3, if it is still possible.

Hi Vladimir,

Sorry for missing this for the merge window. We sometimes don't
see stuff for inclusion when it doesn't get sent to a...@kernel.org.

That alias is for all arm-soc maintainers combined, and this time
I happened to hand over to Olof who did the merges at the end of
the cycle.

Please rebase your patches on top of v4.4-rc1 next week and send
them again.

> in connection to previous discussion started here [1] I want to ask your
> opinion, does it make sense to support non-DT LPC32xx platforms (by the
> way there is no such platforms in vanilla)?

No, we have made it rather clear in the past that we would not do that.

lpc32xx was one of the earliest platforms to move to devicetree a few
years ago, but a lot of the details were not worked out at the time,
and the cleanups stagnated at some point, so lpc32xx is in a rather
unique intermediate state now.

> In particular I'd like to remove legacy platform data support and
> clean-up mach-lpc32xx, e.g. remove duplicated timer driver etc.

That would be great.

> At the moment I've completed development and tested:
> * common clock framework driver (no review comments from maintainers so
> far),
> * irqchip driver (SPARSE_IRQ is supported),
> * as a dependency to IRQ changes I developed a wakeup controller driver,
> * as a dependency to IRQ changes GPIO driver is rewritten -- at the
> moment it strictly depends on hwirq plus its current version breaks
> board boot in v4.4, see [2].
> 
> In general the platform is broken since commit 76ba59f8366 ("genirq: Add
> irq_domain-aware core IRQ handler"), dated Aug 26 2014 (!), because the
> platform is based on legacy irq domain and hwirq 0 is actively exploited
> -- this is a cascaded irq to one of the sub-irq controllers.

Ok, thanks for letting us know. We should of course fix this and perhaps
backport the fix to stable kernels, but more importantly it means that
nobody has noticed the breakage for a while and that gives us some more
freedom to change things now.

> All done work allows to remove thousands of LoCs and make LPC32xx boot
> and work again at the price of discontinued legacy DTB to new kernel
> compatibility (for example due to missed clocks properties etc.) and
> removed platform_data hooks.

sounds good.

> I can continue to improve LPC32xx platform, but I believe I need some
> kind of approval from ARM maintainers to convince clk/irqchip/gpio
> maintainers to accept my work. What would be your opinion on this subject?
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg452447.html
> [2] https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg11028.html

I don't see any problem here whatsoever. Please go on cleaning up the
platform and send patches for review. We'll try to get them merged soon.

Obviously the new DT bindings need to be reviewed properly and for the
subsystems we also need to make sure the drivers are sane, but that is
the same as for any other platform.

I have in the past tried to do some cleanup towards multiplatform
support, see my patch below for anything that you might find useful.
It's rather hackish and most of the changes I did there are probably
obsoleted by a better change that you have already done, but there
might be one or two things that you missed.

Arnd

>From 1b46ec69e0f94e1d49cbfa3816f7fe8854d0a304 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Wed, 14 Oct 2015 15:52:53 +0200
Subject: [PATCH] experimental lpc32xx multiplatform cleanup

Signed-off-by: Arnd Bergmann 

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 20c48e6e0799..241fe1437c3d 100644
--- 

[PATCH 2/2] iio: st_sensors: support open drain mode

[Linus Walleij]

Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.

If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).

Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba 
Cc: Denis Ciocca 
Signed-off-by: Linus Walleij 
---
 Documentation/devicetree/bindings/iio/st-sensors.txt |  3 +++
 drivers/iio/accel/st_accel_core.c|  8 
 drivers/iio/common/st_sensors/st_sensors_core.c  | 20 
 drivers/iio/common/st_sensors/st_sensors_trigger.c   |  9 +
 drivers/iio/gyro/st_gyro_core.c  | 12 
 drivers/iio/pressure/st_pressure_core.c  |  8 
 include/linux/iio/common/st_sensors.h|  6 ++
 include/linux/platform_data/st_sensors_pdata.h   |  2 ++
 8 files changed, 68 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt 
b/Documentation/devicetree/bindings/iio/st-sensors.txt
index d3ccdb190c53..4ac20cb2ae8d 100644
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -16,6 +16,9 @@ Optional properties:
 - st,drdy-int-pin: the pin on the package that will be used to signal
   "data ready" (valid values: 1 or 2). This property is not configurable
   on all sensors.
+- st,int-pin-open-drain: the interrupt/data ready line will be configured
+  as open drain, which is useful if several sensors share the same
+  interrupt line.
 
 Sensors may also have applicable pin control settings, those use the
 standard bindings from pinctrl/pinctrl-bindings.txt.
diff --git a/drivers/iio/accel/st_accel_core.c 
b/drivers/iio/accel/st_accel_core.c
index 1132224cbc10..888682b95693 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -96,6 +96,8 @@
 #define ST_ACCEL_2_DRDY_IRQ_INT2_MASK  0x10
 #define ST_ACCEL_2_IHL_IRQ_ADDR0x22
 #define ST_ACCEL_2_IHL_IRQ_MASK0x80
+#define ST_ACCEL_2_OD_IRQ_ADDR 0x22
+#define ST_ACCEL_2_OD_IRQ_MASK 0x40
 #define ST_ACCEL_2_MULTIREAD_BIT   true
 
 /* CUSTOM VALUES FOR SENSOR 3 */
@@ -177,6 +179,8 @@
 #define ST_ACCEL_5_DRDY_IRQ_INT2_MASK  0x20
 #define ST_ACCEL_5_IHL_IRQ_ADDR0x22
 #define ST_ACCEL_5_IHL_IRQ_MASK0x80
+#define ST_ACCEL_5_OD_IRQ_ADDR 0x22
+#define ST_ACCEL_5_OD_IRQ_MASK 0x40
 #define ST_ACCEL_5_IG1_EN_ADDR 0x21
 #define ST_ACCEL_5_IG1_EN_MASK 0x08
 #define ST_ACCEL_5_MULTIREAD_BIT   false
@@ -366,6 +370,8 @@ static const struct st_sensor_settings 
st_accel_sensors_settings[] = {
.mask_int2 = ST_ACCEL_2_DRDY_IRQ_INT2_MASK,
.addr_ihl = ST_ACCEL_2_IHL_IRQ_ADDR,
.mask_ihl = ST_ACCEL_2_IHL_IRQ_MASK,
+   .addr_od = ST_ACCEL_2_OD_IRQ_ADDR,
+   .mask_od = ST_ACCEL_2_OD_IRQ_MASK,
},
.multi_read_bit = ST_ACCEL_2_MULTIREAD_BIT,
.bootime = 2,
@@ -552,6 +558,8 @@ static const struct st_sensor_settings 
st_accel_sensors_settings[] = {
.mask_int2 = ST_ACCEL_5_DRDY_IRQ_INT2_MASK,
.addr_ihl = ST_ACCEL_5_IHL_IRQ_ADDR,
.mask_ihl = ST_ACCEL_5_IHL_IRQ_MASK,
+   .addr_od = ST_ACCEL_5_OD_IRQ_ADDR,
+   .mask_od = ST_ACCEL_5_OD_IRQ_MASK,
},
.multi_read_bit = ST_ACCEL_5_MULTIREAD_BIT,
.bootime = 2, /* guess */
diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c 
b/drivers/iio/common/st_sensors/st_sensors_core.c
index ed6f54d5c932..bff469dd9583 100644
--- a/drivers/iio/common/st_sensors/st_sensors_core.c
+++ b/drivers/iio/common/st_sensors/st_sensors_core.c
@@ -302,6 +302,14 @@ static int st_sensors_set_drdy_int_pin(struct iio_dev 
*indio_dev,
return -EINVAL;
}
 
+   if (pdata->open_drain) {
+   if (!sdata->sensor_settings->drdy_irq.addr_od)
+   dev_err(_dev->dev,
+   "open drain requested but unsupported.\n");
+   else
+   sdata->int_pin_open_drain = true;
+   }
+
return 0;
 }
 
@@ -322,6 +330,8 @@ static struct st_sensors_platform_data 
*st_sensors_of_probe(struct device *dev,
else
pdata->drdy_int_pin = defdata ? defdata->drdy_int_pin : 0;

[PATCH v2 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e0c7173..1a8a79d 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -251,7 +252,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
dev_dbg(>client->dev,
"shaped point(%4d,%4d), pressure 
(%4u)\n",
tc.x, tc.y, rt);
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
input_report_abs(input, ABS_X, tc.x);
input_report_abs(input, ABS_Y, tc.y);
input_report_abs(input, ABS_PRESSURE, rt);
@@ -272,9 +276,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.5.1

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

[PATCH v2 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  2 +-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index d0dd036..01dae66 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
linux,wakeup;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index f672a04..9497cc6 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -696,10 +696,19 @@
pendown-gpio = < 30 0>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index f4b1a61..c772b76 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -65,7 +65,7 @@
ti,y-max = /bits/ 16 <4800>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
linux,wakeup;
};
 };
-- 
2.5.1

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

[PATCH v2 4/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

Tested on: GTA04A4 (Letux2804), Letux3704, Letux7004

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 7166d88..95fed8e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -357,10 +357,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <2>;
+   touchscreen-fuzz-y = <2>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 };
 
-- 
2.5.1

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

[PATCH v2 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/ads7846.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index b9896fd..6bedbfa 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1563,6 +1563,17 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
-- 
2.5.1

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

[PATCH v2 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

calculate_pressure has been renamed to calculate_resistance because
that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 +--
 drivers/input/touchscreen/tsc2007.c| 135 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 135 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..e0c7173 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+   boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 
+   dev_dbg(>client->dev, "soft irq %d\n", irq);
while (!ts->stopped && 

[PATCH v2 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property 
(suggested by Rob Herring)

2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by commit b98abe52fa8e:

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: add iio interface to read external ADC input,
temperature and raw conversion values
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): recognise old binding for coordinate
flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   8 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  18 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   2 +-
 drivers/input/touchscreen/Kconfig  |   1 +
 drivers/input/touchscreen/ads7846.c|  85 +-
 drivers/input/touchscreen/tsc2007.c| 286 +++--
 include/linux/i2c/tsc2007.h|   8 +
 10 files changed, 401 insertions(+), 46 deletions(-)

-- 
2.5.1

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

[PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

This has been integrated and interpretation of the inversion (flipping)
properties for the x and y axis has been added to accommodate any
orientation of the touch in relation to the LCD.

By scaling the min/max ADC values to the screen size it is now possible to
pre-calibrate the touch so that is (almost) exactly matches the LCD it is
glued onto. This allows to well enough operate the touch before a user
space calibration can improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../devicetree/bindings/input/ads7846.txt  |  8 ++-
 drivers/input/touchscreen/ads7846.c| 72 --
 2 files changed, 74 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index df8b127..ae56355 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,12 +26,17 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -79,6 +84,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 04edc8f..4525f00 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,14 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
 
boolswap_xy;
+   boolinvert_x;
+   boolinvert_y;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -828,9 +835,48 @@ static void ads7846_report_state(struct ads7846 *ts)
if (Rt) {
struct input_dev *input = ts->input;
 
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+   /* clamp to expected ADC range */
+   if (x < ts->x_min)
+   x = ts->x_min;
+   if (x > ts->x_max)
+   x = ts->x_max;
+   if (y < ts->y_min)
+   y = ts->y_min;
+   if (y > ts->y_max)
+   y = ts->y_max;
+
+   dev_dbg(>spi->dev,
+   "Clamped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* flip */
+   if (ts->invert_x)
+   x = (ts->x_max - x) + ts->x_min;
+   if (ts->invert_y)
+   y = (ts->y_max - y) + ts->y_min;
+
+   dev_dbg(>spi->dev,
+   "Flipped point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale to desired output range */
+   x = (input->absinfo[ABS_X].maximum * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   y = (input->absinfo[ABS_Y].maximum * (y - ts->y_min))
+   / (ts->y_max - ts->y_min);
+
+   dev_dbg(>spi->dev,
+   "Scaled point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   

Re: [v4 00/10] add support SATA for BMIPS_GENERIC

[Florian Fainelli]

On 30/10/15 07:01, Jaedon Shin wrote:
> Hi all,
> 
> This patch series add support SATA for BMIPS_GENERIC.

Sorry for the lag.

Tested on 7425b2, there is a small mistake in the interrupt number for
the AHCI controller in the 7425.dtsi file (40 -> 41, see below), after
fixing that, I get both drives (external and internal ports) to be
identified successfully:

# dmesg | grep scsi
<6>[0.964097] scsi host0: brcm-ahci
<6>[0.967982] scsi host1: brcm-ahci
<5>[1.122386] scsi 0:0:0:0: Direct-Access ATA  WDC
WD2500AAKX-7 1H19 PQ: 0 ANSI: 5
<5>[1.124512] sd 0:0:0:0: Attached scsi generic sg0 type 0
<5>[1.411546] scsi 1:0:0:0: Direct-Access ATA  WDC
WD2500AAKX-7 1H19 PQ: 0 ANSI: 5
<5>[1.428870] sd 1:0:0:0: Attached scsi generic sg1 type 0
#

And performance looks good:

# hdparm -tT /dev/sda

/dev/sda:
[   48.557068] random: nonblocking pool is initialized
Timing buffer-cache reads:   524 MB in 0.50 seconds = 1052111 kB/s
Timing buffered disk reads:  358 MB in 3.00 seconds = 122132 kB/s
# hdparm -tT /dev/sdb

/dev/sdb:
Timing buffer-cache reads:   528 MB in 0.50 seconds = 1060559 kB/s
Timing buffered disk reads:  374 MB in 3.00 seconds = 127496 kB/s


Tested-by: Florian Fainelli 

For interrupt numbers, computing them from the HIF_CPU_INTR1 register
works like this this:

HW IRQ# = N * 32 + M

where N ranges from 0->2 and M is the bit within the 32-bits word.

Thanks!

> 
> Changes in v4:
> - remove unused properties from bcm{7425,7342,7362}.dtsi
> 
> Changes in v3:
> - fix typo quirk instead of quick
> - disable NCQ before initialzing SATA controller endianness
> - fix misnomer controlling phy interface
> - remove brcm,broken-ncq and brcm,broken-phy properties from devicetree
> - use compatible string for quirks
> - use list for compatible strings
> - add "Acked-by:" tags
> 
> Changes in v2:
> - adds quirk for ncq
> - adds quirk for phy interface control
> - remove unused definitions in ahci_brcmstb
> - combines compatible string
> 
> Jaedon Shin (10):
>   ata: ahci_brcmstb: add support MIPS-based platforms
>   ata: ahci_brcmstb: add quirk for broken ncq
>   ata: ahci_brcmstb: add quirk for different phy
>   ata: ahci_brcmstb: remove unused definitions
>   phy: phy_brcmstb_sata: remove duplicate definitions
>   phy: phy_brcmstb_sata: add data for phy version
>   phy: phy_brcmstb_sata: add support MIPS-based platforms
>   MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7425
>   MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7346
>   MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7362
> 
>  .../devicetree/bindings/ata/brcm,sata-brcmstb.txt  |  4 +-
>  .../bindings/phy/brcm,brcmstb-sata-phy.txt |  1 +
>  arch/mips/boot/dts/brcm/bcm7346.dtsi   | 40 +++
>  arch/mips/boot/dts/brcm/bcm7362.dtsi   | 40 +++
>  arch/mips/boot/dts/brcm/bcm7425.dtsi   | 40 +++
>  arch/mips/boot/dts/brcm/bcm97346dbsmb.dts  |  8 +++
>  arch/mips/boot/dts/brcm/bcm97362svmb.dts   |  8 +++
>  drivers/ata/Kconfig|  2 +-
>  drivers/ata/ahci_brcmstb.c | 58 
> +-
>  drivers/phy/Kconfig|  4 +-
>  drivers/phy/phy-brcmstb-sata.c | 47 ++
>  11 files changed, 236 insertions(+), 16 deletions(-)
> 


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

Re: [PATCH 1/3] mtd: create a partition type device tree binding

[Brian Norris]

On Fri, Nov 06, 2015 at 08:13:13AM -0600, Rob Herring wrote:
> Since we now have partitions contained in a sub node, how about using
> compatible for that sub node instead.

I see that Linus and I spoke up in agreement on this one.

I took a little look at adding of_match_table support to the core MTD
partitioning code (not sure if that's duplicating anything Linus was
attempting on his own?), and I'm observing that there's potential for
conflict with the new binding [1]. If we're going to start overloading
the 'partitions' node to support other partitioning types via
'compatible' property, then we either need to:

 (1) go back to specifying that full ofpart specifications must have
 *no* compatible property or

 (2) we should define a comptible property for the hard-coded
 partitioning case (e.g., compatible = "partitions")

IOW, I could imagine a new partition parser that needs a DT like this:

flash@xxx {
compatible = "vendor,flash-type";
...
partitions {
compatible = "some-new-partition-parser";
...
subnode {
// "some-new-partition-parser" might
// need to put something here
};
};
};

But currently, the binding would say that 'subnode' must be a partition,
even if it's really something else auxiliary to
"some-new-partition-parser" [2].

If we went with option (1), then we'd just have ofpart.c see that
'partitions' has a compatible property and bail out. That seems kinda
hacky.

If we went with option (2), then ofpart.c could just check only for
'compatible = "partitions"' (or similar), and if not found bail out.

I think option (2) makes more sense. But it would require an update to
the binding and code for 4.4, since [1] was only introduced during this
release cycle.

Brian

[1] fe2585e9c29a ("doc: dt: mtd: support partitions in a special 'partitions' 
subnode")

[2] Possibilities: something relevant to partition splitting. See some
previous work, which I haven't gotten around to fully addressing yet,
but can hopefully be rolled into this work:

http://patchwork.ozlabs.org/patch/476373/
http://patchwork.ozlabs.org/patch/473364/
http://patchwork.ozlabs.org/patch/475988/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[Sebastian Reichel]

Hi,

On Fri, Nov 13, 2015 at 09:35:56PM +0100, H. Nikolaus Schaller wrote:
> commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
> introduced common DT bindings for touchscreens [1] and a helper function to
> parse the DT.
> 
> This has been integrated and interpretation of the inversion (flipping)
> properties for the x and y axis has been added to accommodate any
> orientation of the touch in relation to the LCD.
> 
> By scaling the min/max ADC values to the screen size it is now possible to
> pre-calibrate the touch so that is (almost) exactly matches the LCD it is
> glued onto. This allows to well enough operate the touch before a user
> space calibration can improve the precision.
> 
> [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  .../devicetree/bindings/input/ads7846.txt  |  8 ++-
>  drivers/input/touchscreen/ads7846.c| 72 
> --
>  2 files changed, 74 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
> b/Documentation/devicetree/bindings/input/ads7846.txt
> index df8b127..ae56355 100644
> --- a/Documentation/devicetree/bindings/input/ads7846.txt
> +++ b/Documentation/devicetree/bindings/input/ads7846.txt
> @@ -26,12 +26,17 @@ Additional required properties:
>  
>  Optional properties:
>  
> +You can optionally specify any of the touchscreen parameters described in
> +
> + Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> +
> +This allows to scale, invert or swap coordinates and define the fuzz factors.
> +
>   ti,vref-delay-usecs vref supply delay in usecs, 0 for
>   external vref (u16).
>   ti,vref-mv  The VREF voltage, in millivolts (u16).
>   ti,keep-vref-on set to keep vref on for differential
>   measurements as well
> - ti,swap-xy  swap x and y axis

I guess this should be:

ti,swap-xy: deprecated name for touchscreen-swapped-x-y

-- Sebastian


signature.asc
Description: PGP signature

[PATCH v2 3/8] drivers:input:tsc2007: add iio interface to read external ADC input, temperature and raw conversion values

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This driver provides an iio interface for these adc channels
in addition to the raw x, y, z values and the estimated touch
screen resistance. This can be used for debugging or special
applications.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/Kconfig   |   1 +
 drivers/input/touchscreen/tsc2007.c | 137 +++-
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index deb14c1..b437ead 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -941,6 +941,7 @@ config TOUCHSCREEN_TSC2005
 config TOUCHSCREEN_TSC2007
tristate "TSC2007 based touchscreens"
depends on I2C
+   select IIO
help
  Say Y here if you have a TSC2007 based touchscreen.
 
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 1a8a79d..4d3c995 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -61,6 +64,16 @@
 #define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
 #define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
 
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
 struct ts_event {
u16 x;
u16 y;
@@ -69,9 +82,11 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+   struct iio_dev  *indio;
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +207,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -340,6 +358,86 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   case 1:
+   *val = tsc2007_xfer(tsc, READ_Y);
+   break;
+   case 2:
+   *val = tsc2007_xfer(tsc, READ_Z1);
+   break;
+   case 3:
+   *val = tsc2007_xfer(tsc, READ_Z2);
+   break;
+   case 4:
+   *val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+   break;
+   case 5: {
+   struct ts_event tc;
+
+   tc.x = tsc2007_xfer(tsc, READ_X);
+   tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+   tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+   *val = tsc2007_calculate_resistance(tsc, );
+   break;
+   }
+   case 6:
+   *val = tsc2007_is_pen_down(tsc);
+   break;
+   case 7:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | 

[PATCH v2 6/8] drivers:input:ads7846(+tsc2046): recognise old binding for coordinate flipping

[H. Nikolaus Schaller]

By this patch we still recognise the old binding ti,swap-xy in parallel to
the common binding touchscreen-swapped-x-y. This keeps compatibility
to older (out-of-tree) device tree binaries.

We do this in a separate patch so that it can be easily reverted in the
future to retire the old API. A notice is printed to remind developers
of using old API.

We also fix the bindings name for all in-tree device tree sources in
a separate patch.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/ads7846.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 4525f00..b9896fd 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1259,7 +1259,11 @@ static const struct ads7846_platform_data 
*ads7846_probe_dt(struct device *dev)
of_property_read_u16(node, "ti,vref-mv", >vref_mv);
pdata->keep_vref_on = of_property_read_bool(node, "ti,keep-vref-on");
 
-   pdata->swap_xy = of_property_read_bool(node, "touchscreen-swapped-x-y");
+   pdata->swap_xy = of_property_read_bool(node, "ti,swap-xy");
+   if (pdata->swap_xy)
+   dev_notice(dev, "please update device tree to use 
touchscreen-swapped-x-y");
+   pdata->swap_xy |= of_property_read_bool(node,
+   "touchscreen-swapped-x-y");
 
of_property_read_u16(node, "ti,settle-delay-usec",
 >settle_delay_usecs);
-- 
2.5.1

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

Test. Please ignore

[team]

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

Re: [PATCH v2 0/8] arm: dts: lpc32xx: updates to LPC32xx SoC and boards

[Vladimir Zapolskiy]

Hello Arnd,

On 08.11.2015 17:39, Vladimir Zapolskiy wrote:
> Hi Arnd,
> 
> On 21.10.2015 17:45, Arnd Bergmann wrote:
>> On Sunday 18 October 2015 00:35:49 Vladimir Zapolskiy wrote:
>>> The change improves description of NXP LPC32xx hardware, among
>>> important changes it adds standard timers and external memory
>>> controller nodes, splits PWM device node into two,
>>>
>>> Changes from v1 to v2:
>>> - removed v1 2/5 "arm: dts: lpc32xx: fix improper usage of ranges property"
>>> - v1 4/5 "arm: dts: lpc32xx: remove unneeded cell settings from cpus"
>>>   is replaced by v2 3/8 "arm: dts: lpc32xx: add reg property to cpu device 
>>> node"
>>> - new change, sets physical memory offset for EA3250 and PHY3250 v5/8
>>> - new change, added EMC device node v2 6/8
>>> - new change, added standard timer nodes v2 7/8
>>> - new change, grouped USB subdevices together v2 8/8
>>
>> Looks ok to me. Who should pick them up? I haven't seen pull requests from
>> Roland in a while. If he's still interested in the port, I think it would be
>> best if he could create a branch here.
>>
>> If not, we can pick them up directly this time into arm-soc, but then we
>> should find a new maintainer.
>>
>>  Arnd 
> 
> please pick this series up for v4.3, if it is still possible.
> 
> Thank you.
> 

in connection to previous discussion started here [1] I want to ask your
opinion, does it make sense to support non-DT LPC32xx platforms (by the
way there is no such platforms in vanilla)?

In particular I'd like to remove legacy platform data support and
clean-up mach-lpc32xx, e.g. remove duplicated timer driver etc.

At the moment I've completed development and tested:
* common clock framework driver (no review comments from maintainers so
far),
* irqchip driver (SPARSE_IRQ is supported),
* as a dependency to IRQ changes I developed a wakeup controller driver,
* as a dependency to IRQ changes GPIO driver is rewritten -- at the
moment it strictly depends on hwirq plus its current version breaks
board boot in v4.4, see [2].

In general the platform is broken since commit 76ba59f8366 ("genirq: Add
irq_domain-aware core IRQ handler"), dated Aug 26 2014 (!), because the
platform is based on legacy irq domain and hwirq 0 is actively exploited
-- this is a cascaded irq to one of the sub-irq controllers.

All done work allows to remove thousands of LoCs and make LPC32xx boot
and work again at the price of discontinued legacy DTB to new kernel
compatibility (for example due to missed clocks properties etc.) and
removed platform_data hooks.

I can continue to improve LPC32xx platform, but I believe I need some
kind of approval from ARM maintainers to convince clk/irqchip/gpio
maintainers to accept my work. What would be your opinion on this subject?

[1] http://www.spinics.net/lists/arm-kernel/msg452447.html
[2] https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg11028.html

--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

[Gabriel L. Somlo]

From: Gabriel Somlo 

Remove redundant details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the more comprehensive
fw_cfg documentation privided by
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg,
leaving the specific ARM DTB node description in place.

Signed-off-by: Gabriel Somlo 
Cc: Laszlo Ersek 
---
 Documentation/devicetree/bindings/arm/fw-cfg.txt | 37 ++--
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt 
b/Documentation/devicetree/bindings/arm/fw-cfg.txt
index 953fb64..7aeb48a 100644
--- a/Documentation/devicetree/bindings/arm/fw-cfg.txt
+++ b/Documentation/devicetree/bindings/arm/fw-cfg.txt
@@ -11,43 +11,10 @@ QEMU exposes the control and data register to ARM guests as 
memory mapped
 registers; their location is communicated to the guest's UEFI firmware in the
 DTB that QEMU places at the bottom of the guest's DRAM.
 
-The guest writes a selector value (a key) to the selector register, and then
-can read the corresponding data (produced by QEMU) via the data register. If
-the selected entry is writable, the guest can rewrite it through the data
-register.
 
-The selector register takes keys in big endian byte order.
+For a comprehensive description of the behavior of fw_cfg, please see
+Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg.
 
-The data register allows accesses with 8, 16, 32 and 64-bit width (only at
-offset 0 of the register). Accesses larger than a byte are interpreted as
-arrays, bundled together only for better performance. The bytes constituting
-such a word, in increasing address order, correspond to the bytes that would
-have been transferred by byte-wide accesses in chronological order.
-
-The interface allows guest firmware to download various parameters and blobs
-that affect how the firmware works and what tables it installs for the guest
-OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
-initrd images for direct kernel booting, virtual machine UUID, SMP information,
-virtual NUMA topology, and so on.
-
-The authoritative registry of the valid selector values and their meanings is
-the QEMU source code; the structure of the data blobs corresponding to the
-individual key values is also defined in the QEMU source code.
-
-The presence of the registers can be verified by selecting the "signature" blob
-with key 0x, and reading four bytes from the data register. The returned
-signature is "QEMU".
-
-The outermost protocol (involving the write / read sequences of the control and
-data registers) is expected to be versioned, and/or described by feature bits.
-The interface revision / feature bitmap can be retrieved with key 0x0001. The
-blob to be read from the data register has size 4, and it is to be interpreted
-as a uint32_t value in little endian byte order. The current value
-(corresponding to the above outer protocol) is zero.
-
-The guest kernel is not expected to use these registers (although it is
-certainly allowed to); the device tree bindings are documented here because
-this is where device tree bindings reside in general.
 
 Required properties:
 
-- 
2.4.3

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

[PATCH v4 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries

[Gabriel L. Somlo]

From: Gabriel Somlo 

Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") to descriptively name the
various fw_cfg "blobs" passed into the guest.

This patch attempts, on a best effort basis, to create a
directory hierarchy representing the content of fw_cfg file
names, under /sys/firmware/qemu_fw_cfg/by_name.

Upon successful creation of all directories representing the
"dirname" portion of a fw_cfg file, a symlink will be created
to represent the "basename", pointing at the appropriate
/sys/firmware/qemu_fw_cfg/by_key entry. If a file name is not
suitable for this procedure (e.g., if its basename or dirname
components collide with an already existing dirname component
or basename, respectively) the corresponding fw_cfg blob is
skipped and will remain available in sysfs only by its selector
key value.

Signed-off-by: Gabriel Somlo 
Cc: Andy Lutomirski 
---
 .../ABI/testing/sysfs-firmware-qemu_fw_cfg |  42 
 drivers/firmware/qemu_fw_cfg.c | 109 -
 2 files changed, 148 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg 
b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
index b908b6d..a346ee0 100644
--- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
+++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
@@ -196,3 +196,45 @@ Description:
  entry via the control register, and reading a number
  of bytes equal to the blob size from the data
  register.
+
+   --- Listing fw_cfg blobs by file name ---
+
+   While the fw_cfg device does not impose any specific naming
+   convention on the blobs registered in the file directory,
+   QEMU developers have traditionally used path name semantics
+   to give each blob a descriptive name. For example:
+
+   "bootorder"
+   "genroms/kvmvapic.bin"
+   "etc/e820"
+   "etc/boot-fail-wait"
+   "etc/system-states"
+   "etc/table-loader"
+   "etc/acpi/rsdp"
+   "etc/acpi/tables"
+   "etc/smbios/smbios-tables"
+   "etc/smbios/smbios-anchor"
+   ...
+
+   In addition to the listing by unique selector key described
+   above, the fw_cfg sysfs driver also attempts to build a tree
+   of directories matching the path name components of fw_cfg
+   blob names, ending in symlinks to the by_key entry for each
+   "basename", as illustrated below (assume current directory is
+   /sys/firmware):
+
+   qemu_fw_cfg/by_name/bootorder -> ../by_key/38
+   qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
+   qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
+   ...
+
+   Construction of the directory tree and symlinks is done on a
+   "best-effort" basis, as there is no guarantee that components
+   of fw_cfg blob names are always "well behaved". I.e., there is
+   the possibility that a symlink (basename) will conflict with
+   a dirname component of another fw_cfg blob, in which case the
+   creation of the offending /sys/firmware/qemu_fw_cfg/by_name
+   entry will be skipped.
+
+   The authoritative list of entries will continue to be found
+   under the /sys/firmware/qemu_fw_cfg/by_key directory.
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 618304a..9ac1ca7 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -318,9 +318,103 @@ static struct bin_attribute fw_cfg_sysfs_attr_raw = {
.read = fw_cfg_sysfs_read_raw,
 };
 
-/* kobjects representing top-level and by_key folders */
+/*
+ * Create a kset subdirectory matching each '/' delimited dirname token
+ * in 'name', starting with sysfs kset/folder 'dir'; At the end, create
+ * a symlink directed at the given 'target'.
+ * NOTE: We do this on a best-effort basis, since 'name' is not guaranteed
+ * to be a well-behaved path name. Whenever a symlink vs. kset directory
+ * name collision occurs, the kernel will issue big scary warnings while
+ * refusing to add the offending link or directory. We follow up with our
+ * own, slightly less scary error messages explaining the situation :)
+ */
+static int fw_cfg_build_symlink(struct kset *dir,
+   struct kobject 

[PATCH v4 0/4] SysFS driver for QEMU fw_cfg device

[Gabriel L. Somlo]

From: "Gabriel Somlo" 

Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.

The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on overall similarity to the type of information
exposed under /sys/firmware/dmi/entries/...

New (since v3):

Patch 1/4: Device probing now works with either ACPI, DT, or
   optionally by manually specifying a base, size, and
   register offsets on the command line. This way, all
   architectures offering fw_cfg can be supported, although
   x86 and ARM get *automatic* support via ACPI and/or DT.

   HUGE thanks to Laszlo Ersek  for
   pointing out drivers/virtio/virtio_mmio.c, as an example
   on how to pull this off !!!

   Stefan: I saw Marc's DMA patches to fw_cfg. Since only
   x86 and ARM will support it starting with QEMU 2.5, and
   since I expect to get lots of otherwise interesting (but
   otherwise orthogonal) feedback on this series, I'd like
   to stick with ioread8() across the board for now. We can
   always patch in DMA support in a backward compatible way
   later, once this series gets (hopefully) accepted :)

Patch 2/4: (was 3/4 in v3): unchanged. Exports kset_find_obj() so
   modules can call it.

Patch 3/4: (was 4/4 in v3): rebased, but otherwise the same.
   Essentially, creates a "human readable" directory
   hierarchy from "path-like" tokens making up fw_cfg
   blob names. I'm not really sure there's a way to make
   this happen via udev rules, but I have at least one
   potential use case for doing it *before* udev becomes
   available (cc: Andy Lutomirski ),
   so I'd be happy to leave this functionality in the
   kernel module. See further below for an illustration
   of this.

Patch 4/4: Updates the existing ARM DT documentation for fw_cfg,
   mainly by pointing at the more comprehensive document
   introduced with Patch 1/4 for details on the fw_cfg
   device interface, leaving only the specific ARM/DT
   address/size node information in place.

Thanks much,
  --Gabriel

>  In addition to the "by_key" blob listing, e.g.:
>  
>  $ tree /sys/firmware/qemu_fw_cfg/
>  /sys/firmware/qemu_fw_cfg/
>  |-- by_key
>  |   |-- 32
>  |   |   |-- key
>  |   |   |-- name("etc/boot-fail-wait")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 33
>  |   |   |-- key
>  |   |   |-- name("etc/smbios/smbios-tables")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 34
>  |   |   |-- key
>  |   |   |-- name("etc/smbios/smbios-anchor")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 35
>  |   |   |-- key
>  |   |   |-- name("etc/e820")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 36
>  |   |   |-- key
>  |   |   |-- name("genroms/kvmvapic.bin")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 37
>  |   |   |-- key
>  |   |   |-- name("etc/system-states")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 38
>  |   |   |-- key
>  |   |   |-- name("etc/acpi/tables")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 39
>  |   |   |-- key
>  |   |   |-- name("etc/table-loader")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 40
>  |   |   |-- key
>  |   |   |-- name("etc/tpm/log")
>  |   |   |-- raw
>  |   |   `-- size
>  |   |-- 41
>  |   |   |-- key
>  |   |   |-- name("etc/acpi/rsdp")
>  |   |   |-- raw
>  |   |   `-- size
>  |   `-- 42
>  |   |-- key
>  |   |-- name("bootorder")
>  |   |-- raw
>  |   `-- size
>  |
>  ...
>  
>  Patch 3/4 also gets us a "human readable" "by_name" listing, like so:
>  
>  ...
>  |-- by_name
>  |   |-- bootorder -> ../by_key/42
>  |   |-- etc
>  |   |   |-- acpi
>  |   |   |   |-- rsdp -> ../../../by_key/41
>  |   |   |   `-- tables -> ../../../by_key/38
>  |   |   |-- boot-fail-wait -> ../../by_key/32
>  |   |   |-- e820 -> ../../by_key/35
>  |   |   |-- smbios
>  |   |   |   |-- smbios-anchor -> ../../../by_key/34
>  |   |   |   `-- smbios-tables -> ../../../by_key/33
>  |   |   |-- system-states -> ../../by_key/37
>  |   |   |-- table-loader -> ../../by_key/39
>  |   |   `-- tpm
>  |   |   `-- log -> ../../../by_key/40
>  |   `-- genroms
>  

Re: [v4 00/10] add support SATA for BMIPS_GENERIC

[Jaedon Shin]

Hi Florian,

> On Nov 14, 2015, at 5:27 AM, Florian Fainelli  wrote:
> 
> On 30/10/15 07:01, Jaedon Shin wrote:
>> Hi all,
>> 
>> This patch series add support SATA for BMIPS_GENERIC.
> 
> Sorry for the lag.
> 
> Tested on 7425b2, there is a small mistake in the interrupt number for
> the AHCI controller in the 7425.dtsi file (40 -> 41, see below), after
> fixing that, I get both drives (external and internal ports) to be
> identified successfully:
> 

It's a mistake, and your explanation is correct.

The patches of device node are already applied by Ralf. So I'll add a patch
to fix the details for applied patches.

Thanks.

Jaedon

> # dmesg | grep scsi
> <6>[0.964097] scsi host0: brcm-ahci
> <6>[0.967982] scsi host1: brcm-ahci
> <5>[1.122386] scsi 0:0:0:0: Direct-Access ATA  WDC
> WD2500AAKX-7 1H19 PQ: 0 ANSI: 5
> <5>[1.124512] sd 0:0:0:0: Attached scsi generic sg0 type 0
> <5>[1.411546] scsi 1:0:0:0: Direct-Access ATA  WDC
> WD2500AAKX-7 1H19 PQ: 0 ANSI: 5
> <5>[1.428870] sd 1:0:0:0: Attached scsi generic sg1 type 0
> #
> 
> And performance looks good:
> 
> # hdparm -tT /dev/sda
> 
> /dev/sda:
> [   48.557068] random: nonblocking pool is initialized
> Timing buffer-cache reads:   524 MB in 0.50 seconds = 1052111 kB/s
> Timing buffered disk reads:  358 MB in 3.00 seconds = 122132 kB/s
> # hdparm -tT /dev/sdb
> 
> /dev/sdb:
> Timing buffer-cache reads:   528 MB in 0.50 seconds = 1060559 kB/s
> Timing buffered disk reads:  374 MB in 3.00 seconds = 127496 kB/s
> 
> 
> Tested-by: Florian Fainelli 
> 
> For interrupt numbers, computing them from the HIF_CPU_INTR1 register
> works like this this:
> 
> HW IRQ# = N * 32 + M
> 
> where N ranges from 0->2 and M is the bit within the 32-bits word.
> 
> Thanks!
> 
>> 
>> Changes in v4:
>> - remove unused properties from bcm{7425,7342,7362}.dtsi
>> 
>> Changes in v3:
>> - fix typo quirk instead of quick
>> - disable NCQ before initialzing SATA controller endianness
>> - fix misnomer controlling phy interface
>> - remove brcm,broken-ncq and brcm,broken-phy properties from devicetree
>> - use compatible string for quirks
>> - use list for compatible strings
>> - add "Acked-by:" tags
>> 
>> Changes in v2:
>> - adds quirk for ncq
>> - adds quirk for phy interface control
>> - remove unused definitions in ahci_brcmstb
>> - combines compatible string
>> 
>> Jaedon Shin (10):
>>  ata: ahci_brcmstb: add support MIPS-based platforms
>>  ata: ahci_brcmstb: add quirk for broken ncq
>>  ata: ahci_brcmstb: add quirk for different phy
>>  ata: ahci_brcmstb: remove unused definitions
>>  phy: phy_brcmstb_sata: remove duplicate definitions
>>  phy: phy_brcmstb_sata: add data for phy version
>>  phy: phy_brcmstb_sata: add support MIPS-based platforms
>>  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7425
>>  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7346
>>  MIPS: BMIPS: brcmstb: add SATA/PHY nodes for bcm7362
>> 
>> .../devicetree/bindings/ata/brcm,sata-brcmstb.txt  |  4 +-
>> .../bindings/phy/brcm,brcmstb-sata-phy.txt |  1 +
>> arch/mips/boot/dts/brcm/bcm7346.dtsi   | 40 +++
>> arch/mips/boot/dts/brcm/bcm7362.dtsi   | 40 +++
>> arch/mips/boot/dts/brcm/bcm7425.dtsi   | 40 +++
>> arch/mips/boot/dts/brcm/bcm97346dbsmb.dts  |  8 +++
>> arch/mips/boot/dts/brcm/bcm97362svmb.dts   |  8 +++
>> drivers/ata/Kconfig|  2 +-
>> drivers/ata/ahci_brcmstb.c | 58 
>> +-
>> drivers/phy/Kconfig|  4 +-
>> drivers/phy/phy-brcmstb-sata.c | 47 ++
>> 11 files changed, 236 insertions(+), 16 deletions(-)
>> 
> 
> 
> -- 
> Florian

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

[PATCH v4 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device

[Gabriel L. Somlo]

From: Gabriel Somlo 

Make fw_cfg entries of type "file" available via sysfs. Entries
are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders
named after each entry's selector key. Filename, selector value,
and size read-only attributes are included for each entry. Also,
a "raw" attribute allows retrieval of the full binary content of
each entry.

This patch also provides a documentation file outlining the
guest-side "hardware" interface exposed by the QEMU fw_cfg device.

The fw_cfg device can be instantiated automatically from ACPI or
the Device Tree, or manually by using a kernel module (or command
line) parameter, with a syntax outlined in the documentation file.

Signed-off-by: Gabriel Somlo 
---
 .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 198 +++
 drivers/firmware/Kconfig   |  19 +
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/qemu_fw_cfg.c | 611 +
 4 files changed, 829 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
 create mode 100644 drivers/firmware/qemu_fw_cfg.c

diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg 
b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
new file mode 100644
index 000..b908b6d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
@@ -0,0 +1,198 @@
+What:  /sys/firmware/qemu_fw_cfg/
+Date:  August 2015
+Contact:   Gabriel Somlo 
+Description:
+   Several different architectures supported by QEMU (x86, arm,
+   sun4*, ppc/mac) are provisioned with a firmware configuration
+   (fw_cfg) device, originally intended as a way for the host to
+   provide configuration data to the guest firmware. Starting
+   with QEMU v2.4, arbitrary fw_cfg file entries may be specified
+   by the user on the command line, which makes fw_cfg additionally
+   useful as an out-of-band, asynchronous mechanism for providing
+   configuration data to the guest userspace.
+
+   === Guest-side Hardware Interface ===
+
+   The fw_cfg device is available to guest VMs as a register pair
+   (control and data), accessible as either a IO ports or as MMIO
+   addresses, depending on the architecture.
+
+   --- Control Register ---
+
+   Width: 16-bit
+   Access: Write-Only
+   Endianness: LE (if IOport) or BE (if MMIO)
+
+   A write to the control register selects the index for one of
+   the firmware configuration items (or "blobs") available on the
+   fw_cfg device, which can subsequently be read from the data
+   register.
+
+   Each time the control register is written, an data offset
+   internal to the fw_cfg device will be set to zero. This data
+   offset impacts which portion of the selected fw_cfg blob is
+   accessed by reading the data register, as explained below.
+
+   --- Data Register ---
+
+   Width: 8-bit (if IOport), or 8/16/32/64-bit (if MMIO)
+   Access: Read-Only
+   Endianness: string preserving
+
+   The data register allows access to an array of bytes which
+   represent the fw_cfg blob last selected by a write to the
+   control register.
+
+   Immediately following a write to the control register, the data
+   offset will be set to zero. Each successful read access to the
+   data register will increment the data offset by the appropriate
+   access width.
+
+   Each fw_cfg blob has a maximum associated data length. Once the
+   data offset exceeds this maximum length, any subsequent reads
+   via the data register will return 0x00.
+
+   An N-byte wide read of the data register will return the next
+   available N bytes of the selected fw_cfg blob, as a substring,
+   in increasing address order, similar to memcpy(), zero-padded
+   if necessary should the maximum data length of the selected
+   item be reached, as described above.
+
+   --- Per-arch Register Details ---
+
+   -
+   archaccess base ctrlctrldatamax.
+   modeaddress offset  endian  offset  data
+   (bytes) (bytes)
+   -
+   x86 IOport0x510 0   LE  1   1
+   arm MMIO  0x902 8   BE  0   8
+ 

[PATCH v4 2/4] kobject: export kset_find_obj() for module use

[Gabriel L. Somlo]

From: Gabriel Somlo 

Signed-off-by: Gabriel Somlo 
---
 lib/kobject.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const char 
*name)
spin_unlock(>list_lock);
return ret;
 }
+EXPORT_SYMBOL(kset_find_obj);
 
 static void kset_release(struct kobject *kobj)
 {
-- 
2.4.3

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

Re: [PATCH v4 00/10] Better compatible for the rockchip thermal and support RK3368 SoCs

[Caesar Wang]

在 2015年11月13日 06:14, Heiko Stuebner 写道:

Hi Eduardo,

Am Donnerstag, 12. November 2015, 10:29:52 schrieb Eduardo Valentin:

On Mon, Nov 09, 2015 at 12:48:52PM +0800, Caesar Wang wrote:

Thank you all for providing inputs and comments on previous versions of
this patchset.
Especially thanks to the (Eduardo, Dmitry, Heiko,).

This series patchs are working for RK3368 on Rockchip platform.

Do you have any results on existing support? Is the driver still in one
piece for rk3288?

I've tested this series on a rk3288-veyron-jerry and everything still
runs just fine, so

Tested-by: Heiko Stuebner 


Thanks Heiko for testing.:-)



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com


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

Re: [PATCH v4 00/10] Better compatible for the rockchip thermal and support RK3368 SoCs

[Caesar Wang]

Eduardo,

在 2015年11月13日 02:29, Eduardo Valentin 写道:

On Mon, Nov 09, 2015 at 12:48:52PM +0800, Caesar Wang wrote:

Thank you all for providing inputs and comments on previous versions of
this patchset.
Especially thanks to the (Eduardo, Dmitry, Heiko,).

This series patchs are working for RK3368 on Rockchip platform.

Do you have any results on existing support? Is the driver still in one
piece for rk3288?


Yep. that's still happy work for rk3288 SoCs.

$while true; do grep "" /sys/class/thermal/thermal_zone[1-2]/temp; sleep 
.5; done

...
/sys/class/thermal/thermal_zone1/temp:70833
/sys/class/thermal/thermal_zone2/temp:69615
/sys/class/thermal/thermal_zone1/temp:70416
/sys/class/thermal/thermal_zone2/temp:68846
/sys/class/thermal/thermal_zone1/temp:70416
/sys/class/thermal/thermal_zone2/temp:70833
/sys/class/thermal/thermal_zone1/temp:70833
/sys/class/thermal/thermal_zone2/temp:69615
/sys/class/thermal/thermal_zone1/temp:71666
/sys/class/thermal/thermal_zone2/temp:69615
/sys/class/thermal/thermal_zone1/temp:70416
/sys/class/thermal/thermal_zone2/temp:69615
/sys/class/thermal/thermal_zone1/temp:70833


I am planing to send your series in next rc cycles. It won't appear in
linux-next until merge window finishes.


Thanks!


BR,

Eduardo Valentin

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com


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

Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support

[Sascha Hauer]

On Wed, Nov 11, 2015 at 08:27:47AM +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2015 at 10:26:30AM -0800, Eduardo Valentin wrote:
> > On Tue, Nov 10, 2015 at 12:05:54PM +, Javi Merino wrote:
> > > On Mon, Nov 09, 2015 at 11:13:32AM +0100, Sascha Hauer wrote:
> > 
> > 
> > 
> > > > +
> > > > +/*
> > > > + * The MT8173 thermal controller has four banks. Each bank can read up 
> > > > to
> > > > + * four temperature sensors simultaneously. The MT8173 has a total of 5
> > > > + * temperature sensors. We use each bank to measure a certain area of 
> > > > the
> > > > + * SoC. Since TS2 is located centrally in the SoC it is influenced by 
> > > > multiple
> > > > + * areas, hence is used in different banks.
> > > > + */
> > > > +static const struct mtk_thermal_bank_cfg bank_data[] = {
> > > > +   {
> > > > +   .num_sensors = 2,
> > > > +   .sensors = { MT8173_TS2, MT8173_TS3 },
> > > > +   }, {
> > > > +   .num_sensors = 2,
> > > > +   .sensors = { MT8173_TS2, MT8173_TS4 },
> > > > +   }, {
> > > > +   .num_sensors = 3,
> > > > +   .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> > > > +   }, {
> > > > +   .num_sensors = 1,
> > > > +   .sensors = { MT8173_TS2 },
> > > > +   },
> > > > +};
> > 
> > Would it make sense to simply expose all sensors and let the
> > configuration of their aggregation be done by DT?
> 
> This particular layout has been chosen because there's also the Smart
> Voltage Scaler (SVS) in the SoC. The SVS uses the same banks for
> measuring temperatures. I don't know the details yet, I just asked the
> Mediatek guys.

Ok, the job of the SVS is to always pick the best voltage for a given
CPU frequency based on the temperature of the CPU cluster. How I
understand it the SVS engine automatically reads temperatures from bank0
for the first CPU cluster and from bank1 for the second CPU cluster. For
this to work we are not free to assign the sensors to the banks
arbitrarily.

I was told that controlling the CPU frequency the performance is better
if we use the maximum temperature of the whole die rather than the
temperature of individual clusters.

I would prefer to keep the sensor/bank association like it currently is
as it allows for easy SVS engine integration. Also I would prefer to
expose a single thermal zone for now, it will be easier to add
additional zones later than it is to remove them later once we have
exposed them to the device tree.

Is that ok with you?

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

[Igor Grinberg]

Hi Uri,

On 10/27/15 14:14, Uri Mashiach wrote:
> From: Ilya Ledvich 
> 
> Add basic support for CompuLab cm-t335 module based on AM335X SoC.
> 
> CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
> The module is built around the Texas Instruments Sitara AM3352/4
> system-on-chip.
> 
> The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
> NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
> Ethernet, CAN bus.
> 
> Current patch adds support:
> UART0 and GPIO LED
> 
> Detailed description can be found at the module site:
> http://www.compulab.co.il/products/computer-on-modules/cm-t335/

[...]

> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts 
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> new file mode 100644
> index 000..197d5ce
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -0,0 +1,62 @@

[...]

> +_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + gpio_led_pins: pinmux_gpio_led_pins {
> + pinctrl-single,pins = <
> + 0x88 (PIN_OUTPUT | MUX_MODE7)   /* gpmc_csn3.gpio2_0 */
> + >;
> + };
> +
> + uart0_pins: pinmux_uart0_pins {
> + pinctrl-single,pins = <
> + /* uart0_rxd.uart0_rxd */
> + 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)
> + /* uart0_txd.uart0_txd */
> + 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)

Can we use AM33XX_IOPAD macro here?
and may be other patches too?

[...]

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

Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

[Eddie Huang]

On Thu, 2015-11-12 at 15:56 -0800, Kevin Hilman wrote:
> Eddie Huang  writes:
> 
> > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote:
> >> Hi Eddie,
> >> 
> >> Kevin Hilman  writes:
> >> 
> >> > Eddie Huang  writes:
> >> >
> >> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote:
> >> >>> Hi Eddie,
> >> >>> 
> >> >>> [...]
> >> >>> 
> >> >>> > I check the log [0],
> >> >>> 
> >> >>> Thanks for checking into this boot failure.
> >> >>> 
> >> >>> > it seems first time mt8135-evbp1 boot to kernel
> >> >>> > shell successfully, then boot again. In the second time, mt8135 stay 
> >> >>> > in
> >> >>> > fastboot mode, waiting host send boot image, then timeout.
> >> >>> 
> >> >>> Actually, it never gets to a shell the first time.  If you look 
> >> >>> closely,
> >> >>> the target reboots as soon as userspace starts.   Look for the PYBOOT
> >> >>> line which says "finished booting, starting userspace"
> >> >>> 
> >> >>> Later on, pyboot thinks it finds a root shell due to finding '#'
> >> >>> characters, but clearly it never got to a shell.
> >> >>> 
> >> >>> > I download zImage and dtb in [1], and kernel run to shell 
> >> >>> > successfully
> >> >>> > on my platform.
> >> >>> 
> >> >>> Are you can you try using a ramdisk as well?  You can use the pre-built
> >> >>> one here:
> >> >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz
> >> >>> 
> >> >>
> >> >> Yes, I tried this ramdisk, and I can reproduce fail issue.
> >> >>
> >> >
> >> > OK, good.   Thanks for looking into it.
> >> >
> >> >>> Please check my boot logs to see how I'm generating the boot.img file
> >> >>> (search for mkbootimg) with a kernel/dtb/ramdisk.  It may be possible
> >> >>> that the kernel image size with a ramdisk is breaking some of the
> >> >>> assumptions in the fastboot mode.  I've seen problems like this on 
> >> >>> other
> >> >>> platforms due to hard-coded sizes/addresses in the boot firmware.
> >> >>> 
> >> >>
> >> >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB,
> >> >> thus cause user space fail.
> >> >
> >> > Aha, I was right!  ;)
> >> 
> >> Also notice in kernelci.org that the mt8173 board has also been failing
> >> to boot in mainline[1].  I wonder if this same limitation exists in the
> >> mt8173 boot firmware?
> >> 
> >
> > MT8173 is another case, the failure is due to following commit:
> > 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes
> >
> > It is because this commit register MM subsystem clock, but kernel don't
> > use MM clock yet, then CCF disable it. (My internal platform kernel
> > command include clk_ignore_unused parameter, so don't have this
> > problem).I will do further checking and release solution later. Thanks
> > your testing.
> 
> OK, thanks for looking into it.
> 
> However, since the merge window is very close to closing, unless you can
> git a fix out soon (and one that doesn't introduce other bugs),
> probablly the right solution is to just revert the above patch so things
> are fixed for mainline ASAP.
> 

I send one patch to fix this problem. Hope this patch can apply to 4.4.

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384800.html

Eddie
Thanks


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

Re: Conditionals in dtsi files

[Mark Rutland]

On Fri, Nov 13, 2015 at 10:43:11AM +0100, Arnd Bergmann wrote:
> On Friday 13 November 2015 10:33:50 Mason wrote:
> > Hello,
> > 
> > I'm wondering how much C preprocessor syntax one can use in DT files.
> > 
> > Suppose I have 2 board DTS (both including common.dtsi)
> > 
> > board_A.dts (1-core), board_B.dts (2-core)
> > 
> > Can I have in common.dtsi something along these lines:
> > 
> > cpus {
> > enable-method = "foo,bar";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > 
> > cpu0: cpu@0 {
> > compatible = "arm,cortex-a9";
> > device_type = "cpu";
> > reg = <0>;
> > };
> > 
> > #if CORE_COUNT > 1
> > cpu1: cpu@1 {
> > compatible = "arm,cortex-a9";
> > device_type = "cpu";
> > reg = <1>;
> > };
> > #endif
> > };
> > 
> > 
> > board_A.dts would have
> > #define CORE_COUNT 1
> > #include "common.dtsi"
> > 
> > board_B.dts would have
> > #define CORE_COUNT 2
> > #include "common.dtsi"
> 
> I would prefer not using any preprocessor statements other than
> #include in .dts files.

I very much agree with this.

We should only have (simple) macros for symbolic names, and #includes
required for those to work.

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

Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

[Mike Looijmans]

On 11-11-15 07:50, R, Vignesh wrote:

Hi Brain,

On 11/11/2015 4:53 AM, Brian Norris wrote:

Hi Vignesh,

...


Also, this API doesn't actually have anything to do with memory mapping.
It has to do with the de facto standard flash protocol. So I don't think
mmap belongs in the name; it should be something about flash. (I know of
at least one other controller that could probably use this API, excpet
it doesn't use memory mapping to accomplish the accelerated flash read.)


The Zynq has a similar way of accessing QSPI flash through a memory map. The 
memory window is only 16MB, so some form of paging would be needed.


It's why I have been following this thread with great interest, since the QSPI 
performance on the Zynq is way below what it could potentially be.



As far as TI QSPI controller is concerned, the accelerated read happens
via mmap port whereby a predefined memory address space of SoC is
exposed as QSPI mmap region. This region can be accessed like normal
RAM(via memcpy()) and the QSPI controller interface takes care of
fetching data from flash on SPI bus automatically hence, I named it as
above. But, I have no hard feelings if it needs to be generalized to
spi_mtd_read() or something else.


I know that on the Zynq, you can even let the DMA controller access the QSPI 
flash via this memory mapping. The QSPI controller itself doesn't support any 
DMA at all.


If something similar applies to the TI platform (most of the TI procs have 
nice DMA controllers) one could go one step further and implement a generic 
DMA-through-mmap access to QSPI flash.


Mike.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 
17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand 
number C65
http://www.aesexpo.eu


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

Re: [PATCH] drivers: ata: Move vendor specific sata port phy oob settings to device-tree

[Rob Herring]

On Fri, Nov 13, 2015 at 04:02:23PM +0530, Anurag Kumar Vulisha wrote:
> In SATA, speed negotiation happens with  OOB(Out of Band) signals. These OOB
> signal timing values are configured through vendor specific registers in the
> SATA controller. These OOB timings depends on the generator and detector clock
> frequency, which varies from board to board (ex: ep108, zcu102 and zc1751 has
> different clock frequencies).

Could you calculate the timings based on the frequency instead? 

> Since to make ahci_ceva driver generic, it would be better to move these
> settings to the device-tree node and read them from driver.
> 
> This patch does the same.
> 
> Signed-off-by: Anurag Kumar Vulisha 
> ---
>  .../devicetree/bindings/ata/ahci-ceva.txt  |   38 +
>  drivers/ata/ahci_ceva.c|   84 
> ++--
>  2 files changed, 99 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-ceva.txt 
> b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> index 7ca8b97..66fcd10 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> @@ -5,6 +5,36 @@ Required properties:
>- compatible: Compatibility string. Must be 'ceva,ahci-1v84'.
>- clocks: Input clock specifier. Refer to common clock bindings.
>- interrupts: Interrupt specifier. Refer to interrupt binding.
> +- ceva,p0-cominit-params: OOB timing value for COMINIT parameter for 
> port 0.
> +- ceva,p1-cominit-params: OOB timing value for COMINIT parameter for 
> port 1.

This doesn't really scale when you have more than 2 ports. Given that 
you know the length for each port, just make it a single property (i.e. 
an array of ports).

> + The fields for the above parameter must be as shown 
> below:
> + ceva,phy-cominit-params = /bits/ 8  CINMP>;
> + CINMP : COMINIT Negate Minimum Period.
> + CIBGN : COMINIT Burst Gap Nominal.
> + CIBGMX: COMINIT Burst Gap Maximum.
> + CIBGMN: COMINIT Burst Gap Minimum.
> +- ceva,p0-comwake-params: OOB timing value for COMWAKE parameter for 
> port 0.
> +- ceva,p1-comwake-params: OOB timing value for COMWAKE parameter for 
> port 1.
> + The fields for the above parameter must be as shown 
> below:
> + ceva,phy-comwake-params = /bits/ 8  CWNMP>;
> + CWBGMN: COMWAKE Burst Gap Minimum.
> + CWBGMX: COMWAKE Burst Gap Maximum.
> + CWBGN: COMWAKE Burst Gap Nominal.
> + CWNMP: COMWAKE Negate Minimum Period.
> +- ceva,p0-burst-params: Burst timing value for COM parameter for port 0.
> +- ceva,p1-burst-params: Burst timing value for COM parameter for port 1.
> + The fields for the above parameter must be as shown 
> below:
> + ceva,phy-burst-params = /bits/ 8 ;
> + BMX: COM Burst Maximum.
> + BNM: COM Burst Nominal.
> + SFD: Signal Failure Detection value.
> + PTST: Partial to Slumber timer value.
> +- ceva,p0-retry-params: Retry interval timing value for port 0.
> +- ceva,p1-retry-params: Retry interval timing value for port 1.
> + The fields for the above parameter must be as shown 
> below:
> + ceva,phy-retry-params = /bits/ 16 ;
> + RIT:  Retry Interval Timer.
> + RCT:  Rate Change Timer.
>  
>  Optional properties:
>- ceva,broken-gen2: limit to gen1 speed instead of gen2.
> @@ -17,4 +47,12 @@ Examples:
>   interrupts = <0 133 4>;
>   clocks = < SATA_CLK_ID>;
>   ceva,broken-gen2;
> + ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
> + ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
> + ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
> + ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>;
> + ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
> + ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
> + ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
> + ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>;
>   };
> diff --git a/drivers/ata/ahci_ceva.c b/drivers/ata/ahci_ceva.c
> index 207649d..59de2ca 100644
> --- a/drivers/ata/ahci_ceva.c
> +++ b/drivers/ata/ahci_ceva.c
> @@ -50,21 +50,6 @@
>  #define PPCFG_PSS_EN (1 << 29)
>  #define PPCFG_ESDF_EN(1 << 31)
>  
> -#define PP2C_CIBGMN  0x0F
> -#define PP2C_CIBGMX  (0x25 << 8)
> -#define PP2C_CIBGN   (0x18 << 16)
> -#define PP2C_CINMP   (0x29 << 24)
> -
> -#define PP3C_CWBGMN  0x04
> -#define PP3C_CWBGMX  (0x0B << 8)
> -#define PP3C_CWBGN   (0x08 << 16)
> 

Re: [PATCHv5 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Rob Herring]

On Fri, Nov 13, 2015 at 01:01:03PM +0100, Enric Balletbo i Serra wrote:
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
> 
> You can add support to your board with current binding.
> 
> Example:
> 
>   anx7814: anx7814@38 {
>   compatible = "analogix,anx7814";
>   reg = <0x38>;
>   pd-gpios = < 1 GPIO_ACTIVE_HIGH>;
>   reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
>   };
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  .../devicetree/bindings/video/bridge/anx7814.txt   | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
> b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
> new file mode 100644
> index 000..f7bdca9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
> @@ -0,0 +1,36 @@
> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +---
> +
> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> +designed for portable devices.
> +
> +Required properties:
> +
> + - compatible: "analogix,anx7814"
> + - reg   : I2C address of the device
> + - cable-det-gpios   : Which GPIO to use for cable detection

Shouldn't this be an interrupt instead (to a gpio controller still)?

> + - pd-gpios  : Which GPIO to use for power down
> + - reset-gpios   : Which GPIO to use for reset
> +
> +Optional properties:
> +
> + - v10-gpios : Which GPIO to use for V10 control.
> + - video interfaces: Device node can contain video interface port nodes.

Please specify how many ports and how many endpoints for each port.

> +
> +Example:
> +
> + anx7814: anx7814@38 {
> + compatible = "analogix,anx7814";
> + reg = <0x38>;
> + cable-det-gpios = < 1 GPIO_ACTIVE_HIGH>;
> + pd-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 3 GPIO_ACTIVE_HIGH>;
> + v10-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + ports {
> + port@0 {

Either simplify to just port (dropping ports) or add a reg property 
here.

> + anx7814_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Rob Herring]

On Fri, Nov 13, 2015 at 01:01:02PM +0100, Enric Balletbo i Serra wrote:
> Analogix Semiconductor develops analog and mixed-signal devices for digital
> media and communications interconnect applications.
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..8987ee8 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -22,6 +22,7 @@ ampire  Ampire Co., Ltd.
>  ams  AMS AG
>  amstaos  AMS-Taos Inc.
>  apm  Applied Micro Circuits Corporation (APM)
> +analogix Analogix Semiconductor, Inc.

Not quite alphabetical order.

>  aptina   Aptina Imaging
>  arasan   Arasan Chip Systems
>  arm  ARM Ltd.
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/9] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings

[Rob Herring]

On Fri, Nov 13, 2015 at 12:04:06PM +0800, Chen-Yu Tsai wrote:
> The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
> It is functionally identical to AXP221; only the regulator default
> voltage/status and the external host interface are different.
> 
> Signed-off-by: Chen-Yu Tsai 
> Acked-by: Maxime Ripard 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index a474359dd206..fd39fa54571b 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -5,11 +5,12 @@ axp152 (X-Powers)
>  axp202 (X-Powers)
>  axp209 (X-Powers)
>  axp221 (X-Powers)
> +axp223 (X-Powers)
>  
>  Required properties:
>  - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> -   "x-powers,axp221"
> -- reg: The I2C slave address for the AXP chip
> +   "x-powers,axp221", "x-powers,axp223"
> +- reg: The I2C slave address or RSB hardware address for the AXP chip
>  - interrupt-parent: The parent interrupt controller
>  - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
> @@ -51,7 +52,7 @@ LDO3: LDO   : ldo3in-supply
>  LDO4 : LDO   : ldo24in-supply: shared supply
>  LDO5 : LDO   : ldo5in-supply
>  
> -AXP221 regulators, type, and corresponding input supply names:
> +AXP221/AXP223 regulators, type, and corresponding input supply names:
>  
>  Regulator  TypeSupply Name Notes
>  -  --- -
> -- 
> 2.6.2
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: hisilicon: fix binding document of mdio

[Rob Herring]

On Fri, Nov 13, 2015 at 10:23:44AM +0800, huangdaode wrote:
> This patch fixes explain the occasion of "hisilcon,mdio" according to
> Arnd's comments. specify it is only used for hip04.
> 
> First, please give your commnents.
> 
> Signed-off-by: huangdaode 
> ---
>  Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt 
> b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> index 9c23fdf..f650e78 100644
> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
> @@ -1,7 +1,9 @@
>  Hisilicon MDIO bus controller
>  
>  Properties:
> -- compatible: "hisilicon,mdio","hisilicon,hns-mdio".
> +- compatible: can be one of "hisilicon,hns-mdio","hisilicon,mdio",
> +  for hip04 board, please use "hisilicon,mdio",
> +  other boards, "hisilicon,hns-mdio" is OK.

Please reformat like this:

- compatible: can be one of:
"hisilicon,hns-mdio"
"hisilicon,mdio"
  For hip04 board, must be "hisilicon,mdio".
  Otherwise, must be "hisilicon,hns-mdio".

>  - reg: The base address of the MDIO bus controller register bank.
>  - #address-cells: Must be <1>.
>  - #size-cells: Must be <0>.  MDIO addresses have no size component.
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV

[Rob Herring]

On Mon, Oct 26, 2015 at 12:59:56PM +0100, Andrzej Hajda wrote:
> DECON-TV(Display and Enhancement Controller for TV) is a variation
> of DECON IP. Its main purpose is to produce video stream for HDMI IP.
> 
> Signed-off-by: Andrzej Hajda 

Acked-by: Rob Herring 

> ---
> Hi Krzysztof,
> 
> I have decided to skip cleanup part as it would require more work,
> not related to this patchset.
> 
> Regards
> Andrzej
> 
>  Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt 
> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> index 3dff78b..c9fd7b3 100644
> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt
> @@ -5,7 +5,8 @@ Exynos series of SoCs which transfers the image data from a 
> video memory
>  buffer to an external LCD interface.
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5433-decon";
> +- compatible: value should be one of:
> + "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
>  - reg: physical base address and length of the DECON registers set.
>  - interrupts: should contain a list of all DECON IP block interrupts in the
> order: VSYNC, LCD_SYSTEM. The interrupt specifier format
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH_V3 1/4] dt-bindings: MIPS: Document xilfpga bindings and boot style

[Rob Herring]

On Mon, Oct 26, 2015 at 11:30:54AM +, Zubair Lutfullah Kakakhel wrote:
> Xilfpga boots only with device-tree. Document the required properties
> and the unique boot style
> 
> Signed-off-by: Zubair Lutfullah Kakakhel 

Acked-by: Rob Herring 

> 
> ---
> V2->V3
> minor nitpicks. mips->MIPS. typo. reorder compatible strings in priority
> 
> V1->V2
> 
> Reformatted to 80 char column
> Correct clock phandle description
> Added digilent,nexys4ddr to get more specific about platform
> Added compatible string in example.
> ---
>  .../devicetree/bindings/mips/img/xilfpga.txt   | 83 
> ++
>  1 file changed, 83 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mips/img/xilfpga.txt
> 
> diff --git a/Documentation/devicetree/bindings/mips/img/xilfpga.txt 
> b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
> new file mode 100644
> index 000..57e7ee9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/img/xilfpga.txt
> @@ -0,0 +1,83 @@
> +Imagination University Program MIPSfpga
> +===
> +
> +Under the Imagination University Program, a microAptiv UP core has been
> +released for academic usage.
> +
> +As we are dealing with a MIPS core instantiated on an FPGA, specifications
> +are fluid and can be varied in RTL.
> +
> +This binding document is provided as baseline guidance for the example
> +project provided by IMG.
> +
> +The example project runs on the Nexys4DDR board by Digilent powered by
> +the ARTIX-7 FPGA by Xilinx.
> +
> +Relevant details about the example project and the Nexys4DDR board:
> +
> +- microAptiv UP core m14Kc
> +- 50MHz clock speed
> +- 128Mbyte DDR RAM   at 0x_
> +- 8Kbyte RAM at 0x1000_
> +- axi_intc   at 0x1020_
> +- axi_uart16550  at 0x1040_
> +- axi_gpio   at 0x1060_
> +- axi_i2cat 0x10A0_
> +- custom_gpioat 0x10C0_
> +- axi_ethernetlite   at 0x10E0_
> +- 8Kbyte BootRAM at 0x1FC0_
> +
> +Required properties:
> +
> + - compatible: Must include "digilent,nexys4ddr","img,xilfpga".
> +
> +CPU nodes:
> +--
> +A "cpus" node is required.  Required properties:
> + - #address-cells: Must be 1.
> + - #size-cells: Must be 0.
> +A CPU sub-node is also required for at least CPU 0. Required properties:
> + - device_type: Must be "cpu".
> + - compatible: Must be "mips,m14Kc".
> + - reg: Must be <0>.
> + - clocks: phandle to ext clock for fixed-clock received by MIPS core.
> +
> +Example:
> +
> + compatible = "img,xilfpga","digilent,nexys4ddr";
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "mips,m14Kc";
> + reg = <0>;
> + clocks  = <>;
> + };
> + };
> +
> + ext: ext {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <5000>;
> + };
> +
> +Boot protocol:
> +--
> +
> +The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_.
> +This is for easy reprogrammibility via JTAG.
> +
> +The BootRAM initializes the cache and the axi_uart peripheral.
> +
> +DDR initialization is already handled by a HW IP block.
> +
> +When the example project bitstream is loaded, the cpu_reset button
> +needs to be pressed.
> +
> +The bootram initializes the cache and axi_uart.
> +Then outputs MIPSFPGA\n\r on the serial port on the Nexys4DDR board.
> +
> +At this point, the board is ready to load the Linux kernel
> +vmlinux file via JTAG.
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv2 1/2] power: domain: add pm_genpd_uninit

[Alexander Aring]

Hi,

On Wed, Nov 11, 2015 at 09:33:40PM +0100, Ulf Hansson wrote:
> On 11 November 2015 at 19:00, Alexander Aring  wrote:
> > Hi,
> >
> > On Thu, Nov 05, 2015 at 03:34:45PM +0100, Alexander Aring wrote:
> >>
> >> What do you suggest to me for e.g. the raspberrypi power domain driver,
> >> also simple ignore such error handling?
> >>
> >
> > ping, I also can add some WARN_ON_ONCE, if the list for sub-domains,
> > etc. are not empty. This would then report about wrong use of
> > pm_genpd_uninit.
> >
> > - Alex
> 
> Sorry for the delay.
> 
> I think what you suggest would be an okay solution, at least it will
> improve the current behaviour.
> 
> We should verify for sub-domains, attached devices, and if the genpd
> has an of-provider. That's all I can think of right now, but there may
> be other things as well.
> 

okay, I added now:

WARN_ON_ONCE(!list_empty(genpd->master_links) ||
 !list_empty(genpd->slave_links) ||
 !list_empty(genpd->dev_list));

So far I understand is master/slave something about domains/subdomains,
the dev_list fis for atteched devices.

But how can I check "if the genpd has an of-provider", the "struct
generic_pm_domain" doesn't know a "of-provider". There is a static list
"of_genpd_providers", do you want to iterate over all and then doing
some matching algorithmn? Or do you want to add something inside "struct
generic_pm_domain", so a genpd knows about the "of-provider".

I am currently confused about how to check on "of-provider".

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

Re: [RFCv2 2/2] rpi: add support to enable usb power domain

[Alexander Aring]

On Thu, Nov 05, 2015 at 08:15:35AM +0100, Stefan Wahren wrote:
...
> >+bool "Raspberry Pi power domain driver"
> >+depends on ARCH_BCM2835
> >+depends on RASPBERRYPI_FIRMWARE
> >+select PM_GENERIC_DOMAINS if PM
> 
> Since PM_GENERIC_DOMAINS_OF depends on PM_GENERIC_DOMAINS this line should
> be redundant.
> 

I can't remove the line:

select PM_GENERIC_DOMAINS if PM

here. It's true that "PM_GENERIC_DOMAINS_OF depends on PM_GENERIC_DOMAINS",
but Kconfig can't handle the dependency here with select. That's why
sometimes people teaches me "select is evil".

I will get:

warning: (RASPBERRYPI_POWER) selects PM_GENERIC_DOMAINS_OF which has
unmet direct dependencies (PM_GENERIC_DOMAINS && OF)

otherwise.

Nevertheless we can't also use "depends on PM_GENERIC_DOMAINS if PM"
because, PM_GENERIC_DOMAINS is a hidden entry (has no Kconfig prompt).

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

Re: [RFC PATCH v3 0/2] Expose DMA_MEMORY_EXCLUSIVE through shared-dma-pool

[Marek Szyprowski]

Hello,

On 2015-11-10 17:18, Neil Armstrong wrote:

The shared-dma-pool dt node only exposes exclusive memory, but in order to 
export
non-exclusive coherent memory, add the no-exclusive property and document it.

v3: use correct of_get_flat_dt_prop helper
v2: simplify patch by looking for DT attribute in callback

Neil Armstrong (2):
   base: dma-coherent: Add DT property for non exclusive shared-dma-pool
   devicetree: reserved-memory: document the optional no-exclusive parameter

  .../devicetree/bindings/reserved-memory/reserved-memory.txt | 3 +++
  drivers/base/dma-coherent.c | 6 +-
  2 files changed, 8 insertions(+), 1 deletion(-)



Acked-by: Marek Szyprowski 

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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