* [GIT PULL 2/2] ARM: imx: device tree changes for 3.14
@ 2013-12-31 5:44 Shawn Guo
[not found] ` <20131231054427.GA22383-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
0 siblings, 1 reply; 47+ messages in thread
From: Shawn Guo @ 2013-12-31 5:44 UTC (permalink / raw)
To: linux-arm-kernel
This pull-request has the following two dependencies:
- The first pull-request, i.e. [GIT PULL 1/2] ARM: imx: soc changes for 3.14
- The pinctrl 'devel' branch below.
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
Linus Walleij promised that the branch will be stable at least from
the point I pulled into my tree, that is commit 31d610f (pinctrl:
imx1-core populate subdevices).
Please pull, thanks.
Shawn
The following changes since commit 43cb02365bc4aacdef642ec0d3e913ab76fbee02:
Merge commit '31d610f' into imx/dt (2013-12-31 11:02:39 +0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.14
for you to fetch changes up to 52bfd188eccf69ee90d8279bccfbb041c9165080:
ARM: dts: imx6qdl-sabresd: Add PFUZE100 support (2013-12-31 11:10:02 +0800)
----------------------------------------------------------------
i.MX device tree changes for 3.14:
- New SoC device tree support for imx35 and imx50.
- A good number of new i.MX6 boards support: SolidRun HummingBoard,
cm-fx6, dmo-edmqmx6, nitrogen6x, and Gateworks Ventana gw5xxx family.
- A few other new i.MX boards support: imx25-eukrea, imx28-duckbill,
imx28-eukrea, imx50-evk, imx51-eukrea, and imx53-voipac.
- Add pinfunc headers for imx25, imx27 and imx50.
- Make pinctrl nodes board specific to avoid floating board specific
device tree blob with so many unused pinctrl data.
- Use clock defines in imx5 DTS files.
- Update imx6q-sabrelite device tree and add Dual Lite/Solo support.
- Use GPIO_6 for FEC interrupt to workaround a hardware bug (ERR006687
ENET: Only the ENET wake-up interrupt request can wake the system
from Wait mode.)
- A plenty of random updates on various SoC and board device tree
sources, adding pinctrl settings, device nodes, properties, etc.
----------------------------------------------------------------
Aida Mynzhasova (1):
ARM: dts: mxs: add auart2 pinmux to imx28.dtsi
Alexander Shiyan (23):
ARM: dts: i.MX51: Update CPU node
ARM: dts: i.MX51: Add dummy clock to AUDMUX
ARM: dts: i.MX51: Switch to use standard IRQ flags definitions
ARM: dts: i.MX51: Move usbphy0 node from AIPS1
ARM: dts: i.MX51 boards: Switch to use standard GPIO flags definitions
ARM: dts: imx51-babbage: Fix chipselect level for dataflash on spi0.1
ARM: dts: imx51-babbage: Define FEC reset pin
ARM: dts: imx27-phytec-phycore-som: Add on-flash BBT support
ARM: dts: imx27-phytec-phycore-rdk: Add DT node for camera module
ARM: dts: imx27-phytec-phycore-som: Update FEC node
ARM: dts: i.MX27 boards: Switch to use standard GPIO and IRQ flags definitions
ARM: dts: i.MX27: Configure GPIOs as "input" by default
ARM: dts: i.MX: Move include "imxXX-pinfunc.h" into "imxXX-pingrp.h"
ARM: dts: imx27-phytec-phycore-rdk: Change pinctrl settings for I2C1
ARM: dts: imx27-phytec-phycore-som: trivial: Typo fix
ARM: dts: imx27-phytec-phycore-som: Add pinctrl for CSPI1 and GPIOs used on module
ARM: dts: imx27-phytec-phycore-som: Rename file to .dtsi
ARM: dts: imx27-phytec-phycore-som: Add NFC pin group
ARM: dts: imx27-phytec-phycore-rdk: Enable 1-Wire module
ARM: dts: imx27-phytec-phycore-som: Add spi-cs-high property to PMIC
ARM: dts: i.MX27: Add missing pullup settings for SDHC pin groups
ARM: dts: imx27-phytec-phycore-rdk: Add pingrp for SDHC
ARM: dts: imx27-phytec-phycore-rdk: Add pinctrl definitions for WEIM
Alexandre Belloni (3):
ARM: dts: mxs: add #io-channel-cells to mx28 lradc
ARM: dts: mxs: Add iio-hwmon to mx28 soc
ARM: dts: mxs: Add iio-hwmon to mx23 soc
Anson Huang (5):
ARM: dts: imx6q: update setting of VDDARM_CAP voltage
ARM: dts: imx6q: add vddsoc/pu setpoint info
ARM: dts: imx6dl: enable cpufreq support
ARM: dts: imx6qdl: add necessary thermal clk
ARM: dts: imx6qdl-sabresd: Add power key support
Denis Carikli (13):
of: add vendor prefix for Eukrea Electromatique.
ARM: dts: i.MX25: Add ssi clocks and DMA events.
ARM: dts: i.MX25: Add sdma script path.
ARM: dts: imx25.dtsi: Add a label for the Audio Multiplexer.
ARM: dts: imx51.dtsi: Add some pinmux pins.
ARM: dts: Add support for the cpuimx51 board from Eukrea and its baseboard.
ARM: dts: imx25: Add pinctrl functions and groups.
ARM: dts: imx25.dtsi: label the iomuxc.
ARM: dts: mxs: Add 18bit pin config for lcdif.
ARM: dts: mxs: Add a new pin config for the usb0 ID.
ARM: dts: Add support for the cpuimx25 board from Eukrea and its baseboard.
ARM: dts: mbimxsd25: Add sound support.
ARM: dts: mbimxsd51: Add sound support.
Eric B?nard (1):
ARM: mxs: Add support for the eukrea-cpuimx28.
Fabio Estevam (6):
ARM: dts: imx6q-udoo: Add Ethernet support
ARM: dts: imx6q-sabrelite: Remove duplicate GPIO entry
ARM: dts: imx6q-sabrelite: Place 'status' as the last node
ARM: dts: imx28-evk: Run I2C0 at 400kHz
ARM: dts: imx6: Use 'vddarm' as the regulator name
ARM: dts: imx6qdl-sabresd: Add PFUZE100 support
Greg Ungerer (3):
ARM: dts: imx: add device tree pin definitions for the IMX50
ARM: dts: imx: add IMX50 SoC device tree
ARM: dts: imx: add device tree support for Freescale imx50evk board
Gwenhael Goavec-Merou (10):
ARM: imx27-apf27dev: Add sdhci support
ARM: dts: imx27-apf27dev: fix display size
ARM: imx27: add pingroups for cspi, sdhc and framebuffer
ARM: dts: imx27: imx27-apf27: add pinctrl for fec and uart1
ARM: dts: imx27: imx27-apf27dev: add pinctrl for cspi, i2c, sdhc and framebuffer
ARM: dts: apf28dev: set gpio polarity for usb regulator and pinctrl for regulator gpio
ARM: imx28: add apf28 specific initialization (macaddr)
ARM: imx27: add pwm pingrp
ARM: dts: apf27dev: Add pwm support
ARM: dts: imx27-apf27dev: Add pinctrl for cspi, sdhci, leds and keys
John Tobias (1):
ARM: dts: imx6sl: Adding cpu frequency and VDDSOC/PU table.
Lothar Wa?mann (3):
ARM: dts: imx6qdl: add aliases for can interfaces
ARM: dts: imx6qdl: add pingroup for enet interface in RMII mode
ARM: dts: imx6qdl: add new pingroup for audmux
Lucas Stach (3):
ARM: imx53: use clock defines in DTS files
ARM: imx51: use clock defines in DTS files
ARM: imx50: use clock defines in DTS files
Marek Vasut (6):
ARM: dts: imx53: Fix display pinmux for M53EVK
ARM: dts: imx53: Fix backlight for M53EVK
ARM: dts: imx53: Add USB support for M53EVK
ARM: dts: imx53: Add AHCI SATA DT node
ARM: dts: imx53: Enable AHCI SATA for M53EVK
ARM: dts: imx6q-sabrelite: Enable PCI express
Markus Pargmann (6):
ARM: dts: imx27 pin functions
ARM: dts: imx27 pingroups
ARM: dts: imx27 iomux device node
ARM: dts: imx27 phyCARD-S pinctrl
ARM: dts: imx27 phycore move uart1 to rdk
ARM: dts: imx27 phycore pinctrl
Maxime Ripard (2):
ARM: mxs: cfa10049: Add NAU7802 ADCs to the device tree
ARM: dts: cfa10036: Add dr_mode and phy_type properties to the DT
Michael Grzeschik (1):
ARM: i.MX28: dts: rename usbphy pin names
Michael Heimpold (1):
ARM: mxs: add support for I2SE's duckbill series
Nicolin Chen (2):
ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000
ARM: dts: imx6qdl: add spdif support for sabreauto
Peter Chen (3):
ARM: dts: imx6q-arm2: enable USB OTG
ARM: dts: imx6: add anatop phandle for usbphy
ARM: dts: imx: add mxs phy controller id
Philipp Zabel (1):
ARM: dts: imx6q-sabrelite: PHY reset is active-low
Robert Nelson (1):
ARM: dts: imx53: Enable AHCI SATA for imx53-qsb
Rostislav Lisovy (8):
ARM: dts: i.MX53: Add alternate pinmux option for i2c_3
ARM: dts: i.MX53: Internal keyboard controller
ARM: dts: Add vendor prefix for Voipac Technologies s.r.o.
ARM: dts: i.MX53: dts for Voipac x53-dmm-668 module
ARM: dts: i.MX53: Devicetree for Voipac Baseboard using x53-dmm-668 module
ARM: dts: voipac: Improve fixed voltage regulator definition
ARM: i.MX53: dts: NAND flash controller
ARM: i.MX53: dts: USB host controller
Russell King (1):
ARM: imx: initial SolidRun HummingBoard support
Shawn Guo (8):
ARM: dts: imx6qdl: make pinctrl nodes board specific
ARM: dts: imx6sl: make pinctrl nodes board specific
ARM: dts: imx53: make pinctrl nodes board specific
ARM: dts: imx51: make pinctrl nodes board specific
ARM: dts: imx50: make pinctrl nodes board specific
ARM: dts: imx53-mba53: create a container for fixed regulators
ARM: dts: imx: use generic node name for fixed regulator
ARM: dts: vf610: make pinctrl nodes board specific
Silvio F (2):
DT: Add Data Modul vendor prefix
ARM: dts: imx6: Add support for imx6q dmo edmqmx6
Steffen Trumtrar (1):
ARM: dts: Add support for the i.MX35.
Tim Harvey (3):
ARM: dts: disable flexcan by default
ARM: dts: added several new imx-pinmux groups
ARM: dts: add Gateworks Ventana support
Troy Kisky (30):
ARM: dts: imx: pinfunc: add MX6QDL_PAD_SD1_CLK__OSC32K_32K_OUT
ARM: dts: imx: imx6qdl.dtsi: add mipi_csi tag
ARM: dts: imx: imx6q.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6dl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6sl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6qdl.dtsi: use IRQ_TYPE_LEVEL_HIGH
ARM: dts: imx: imx6sl/qdl-pingrp: reorganize USDHCx pad groups
ARM: dts: imx: sabrelite: add Dual Lite/Solo support
ARM: dts: imx6qdl-sabrelite: Add uart1 support
ARM: dts: imx6qdl-sabrelite: remove usdhc4 wp-gpio
ARM: dts: imx6qdl-sabrelite: move pcie to imx6qdl-sabrelite.dtsi
ARM: dts: imx6qdl-sabrelite: move USDHC4 CD to pinctrl_usdhc4
ARM: dts: imx6qdl-sabrelite: move USDHC3 CD/WP to pinctrl_usdhc3
ARM: dts: imx6qdl-sabrelite: move spi-nor CS to pinctrl_ecspi1
ARM: dts: imx6qdl-sabrelite: move usbotg power enable to pinctrl_usbotg
ARM: dts: imx6qdl-sabrelite: move phy reset to pinctrl_enet
ARM: dts: imx6qdl-sabrelite: explicitly set pad for SGTL5000 sys_mclk
ARM: dts: imx6qdl-sabrelite: add pwms for backlights
ARM: dts: imx6qdl-sabrelite: add skews for Micrel phy
ARM: dts: imx6qdl-sabrelite: fix ENET group
ARM: dts: imx6qdl-sabrelite: Add over-current pin to usbotg
ARM: dts: imx: add nitrogen6x board
ARM: dts: imx6qdl-sabrelite: add gpio-keys
ARM: dts: imx: pinfunc: add MX6QDL_PAD_GPIO_6__ENET_IRQ
ARM: dts: imx6qdl: add pingroups for enet with GPIO6 interrupt
ARM: dts: imx6qdl-sabrelite: use MX6QDL_ENET_PINGRP_RGMII_MD
ARM: dts: imx6qdl: use interrupts-extended for fec
ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC interrupt.
ARM: dts: imx6qdl-sabreauto: use GPIO_6 for FEC interrupt.
ARM: dts: imx6q-arm2: use GPIO_6 for FEC interrupt.
Valentin Raevsky (1):
ARM: dts: Add initial support for cm-fx6.
.../devicetree/bindings/vendor-prefixes.txt | 3 +
arch/arm/boot/dts/Makefile | 23 +-
arch/arm/boot/dts/imx23-evk.dts | 8 +-
arch/arm/boot/dts/imx23-olinuxino.dts | 5 +-
arch/arm/boot/dts/imx23-stmp378x_devb.dts | 5 +-
arch/arm/boot/dts/imx23.dtsi | 8 +-
arch/arm/boot/dts/imx25-eukrea-cpuimx25.dtsi | 60 ++
.../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 128 +++
arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
arch/arm/boot/dts/imx25-pingrp.h | 81 ++
arch/arm/boot/dts/imx25.dtsi | 18 +-
arch/arm/boot/dts/imx27-apf27.dts | 16 +
arch/arm/boot/dts/imx27-apf27dev.dts | 98 ++-
arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts | 50 +-
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 20 +-
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 86 +-
...ycore-som.dts => imx27-phytec-phycore-som.dtsi} | 65 +-
arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
arch/arm/boot/dts/imx27.dtsi | 127 +--
arch/arm/boot/dts/imx28-apf28dev.dts | 18 +-
arch/arm/boot/dts/imx28-apx4devkit.dts | 5 +-
arch/arm/boot/dts/imx28-cfa10036.dts | 2 +
arch/arm/boot/dts/imx28-cfa10037.dts | 7 +-
arch/arm/boot/dts/imx28-cfa10049.dts | 31 +-
arch/arm/boot/dts/imx28-cfa10057.dts | 7 +-
arch/arm/boot/dts/imx28-cfa10058.dts | 7 +-
arch/arm/boot/dts/imx28-duckbill.dts | 121 +++
arch/arm/boot/dts/imx28-eukrea-mbmx283lc.dts | 71 ++
arch/arm/boot/dts/imx28-eukrea-mbmx287lc.dts | 50 ++
arch/arm/boot/dts/imx28-eukrea-mbmx28lc.dtsi | 326 +++++++
arch/arm/boot/dts/imx28-evk.dts | 24 +-
arch/arm/boot/dts/imx28-m28cu3.dts | 16 +-
arch/arm/boot/dts/imx28-m28evk.dts | 18 +-
arch/arm/boot/dts/imx28-sps1.dts | 7 +-
arch/arm/boot/dts/imx28-tx28.dts | 23 +-
arch/arm/boot/dts/imx28.dtsi | 65 +-
arch/arm/boot/dts/imx35-pingrp.h | 104 +++
arch/arm/boot/dts/imx35.dtsi | 360 ++++++++
arch/arm/boot/dts/imx50-evk.dts | 97 ++
arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
arch/arm/boot/dts/imx50.dtsi | 475 ++++++++++
arch/arm/boot/dts/imx51-apf51.dts | 18 +-
arch/arm/boot/dts/imx51-apf51dev.dts | 50 +-
arch/arm/boot/dts/imx51-babbage.dts | 100 ++-
arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi | 71 ++
.../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 153 ++++
arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
arch/arm/boot/dts/imx51.dtsi | 456 ++--------
arch/arm/boot/dts/imx53-ard.dts | 19 +-
arch/arm/boot/dts/imx53-evk.dts | 38 +-
arch/arm/boot/dts/imx53-m53evk.dts | 133 ++-
arch/arm/boot/dts/imx53-mba53.dts | 40 +-
arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
arch/arm/boot/dts/imx53-qsb.dts | 65 +-
arch/arm/boot/dts/imx53-smd.dts | 62 +-
arch/arm/boot/dts/imx53-tqma53.dtsi | 112 ++-
arch/arm/boot/dts/imx53-tx53.dtsi | 5 +-
arch/arm/boot/dts/imx53-voipac-bsb.dts | 144 +++
arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi | 240 +++++
arch/arm/boot/dts/imx53.dtsi | 649 ++------------
arch/arm/boot/dts/imx6dl-gw51xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw52xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw53xx.dts | 19 +
arch/arm/boot/dts/imx6dl-gw54xx.dts | 19 +
arch/arm/boot/dts/imx6dl-hummingboard.dts | 94 ++
arch/arm/boot/dts/imx6dl-nitrogen6x.dts | 21 +
arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
arch/arm/boot/dts/imx6dl-sabrelite.dts | 20 +
arch/arm/boot/dts/imx6dl.dtsi | 30 +-
arch/arm/boot/dts/imx6q-arm2.dts | 73 +-
arch/arm/boot/dts/imx6q-cm-fx6.dts | 69 ++
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 178 ++++
arch/arm/boot/dts/imx6q-gw51xx.dts | 19 +
arch/arm/boot/dts/imx6q-gw52xx.dts | 23 +
arch/arm/boot/dts/imx6q-gw53xx.dts | 23 +
arch/arm/boot/dts/imx6q-gw5400-a.dts | 493 +++++++++++
arch/arm/boot/dts/imx6q-gw54xx.dts | 23 +
arch/arm/boot/dts/imx6q-nitrogen6x.dts | 25 +
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 44 +-
arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
arch/arm/boot/dts/imx6q-sabrelite.dts | 178 +---
arch/arm/boot/dts/imx6q-sbc6x.dts | 29 +-
arch/arm/boot/dts/imx6q-udoo.dts | 27 +-
arch/arm/boot/dts/imx6q.dtsi | 18 +-
arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 317 +++++++
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 424 +++++++++
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 484 ++++++++++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 511 +++++++++++
arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi | 58 ++
arch/arm/boot/dts/imx6qdl-microsom.dtsi | 89 ++
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 382 ++++++++
arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 80 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 383 ++++++++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 208 ++++-
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 70 +-
arch/arm/boot/dts/imx6qdl.dtsi | 914 +++----------------
arch/arm/boot/dts/imx6sl-evk.dts | 88 +-
arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
arch/arm/boot/dts/imx6sl.dtsi | 366 ++------
arch/arm/boot/dts/vf610-cosmic.dts | 16 +-
arch/arm/boot/dts/vf610-pingrp.h | 127 +++
arch/arm/boot/dts/vf610-twr.dts | 34 +-
arch/arm/boot/dts/vf610.dtsi | 172 +---
arch/arm/mach-imx/mach-imx6q.c | 35 +
arch/arm/mach-mxs/mach-mxs.c | 33 +
108 files changed, 12039 insertions(+), 2730 deletions(-)
create mode 100644 arch/arm/boot/dts/imx25-eukrea-cpuimx25.dtsi
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts
create mode 100644 arch/arm/boot/dts/imx25-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx25-pingrp.h
rename arch/arm/boot/dts/{imx27-phytec-phycore-som.dts => imx27-phytec-phycore-som.dtsi} (74%)
create mode 100644 arch/arm/boot/dts/imx27-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx27-pingrp.h
create mode 100644 arch/arm/boot/dts/imx28-duckbill.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx283lc.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx287lc.dts
create mode 100644 arch/arm/boot/dts/imx28-eukrea-mbmx28lc.dtsi
create mode 100644 arch/arm/boot/dts/imx35-pingrp.h
create mode 100644 arch/arm/boot/dts/imx35.dtsi
create mode 100644 arch/arm/boot/dts/imx50-evk.dts
create mode 100644 arch/arm/boot/dts/imx50-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx50-pingrp.h
create mode 100644 arch/arm/boot/dts/imx50.dtsi
create mode 100644 arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
create mode 100644 arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts
create mode 100644 arch/arm/boot/dts/imx51-pingrp.h
create mode 100644 arch/arm/boot/dts/imx53-pingrp.h
create mode 100644 arch/arm/boot/dts/imx53-voipac-bsb.dts
create mode 100644 arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
create mode 100644 arch/arm/boot/dts/imx6dl-gw51xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw52xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw53xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-gw54xx.dts
create mode 100644 arch/arm/boot/dts/imx6dl-hummingboard.dts
create mode 100644 arch/arm/boot/dts/imx6dl-nitrogen6x.dts
create mode 100644 arch/arm/boot/dts/imx6dl-sabrelite.dts
create mode 100644 arch/arm/boot/dts/imx6q-cm-fx6.dts
create mode 100644 arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw51xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw52xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw53xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw5400-a.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw54xx.dts
create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6x.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-microsom-ar8035.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-microsom.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-pingrp.h
create mode 100644 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
create mode 100644 arch/arm/boot/dts/imx6sl-pingrp.h
create mode 100644 arch/arm/boot/dts/vf610-pingrp.h
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2013-12-31 5:44 [GIT PULL 2/2] ARM: imx: device tree changes for 3.14 Shawn Guo
@ 2014-01-02 20:21 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-02 20:21 UTC (permalink / raw)
To: Shawn Guo
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi,
On Tue, Dec 31, 2013 at 01:44:29PM +0800, Shawn Guo wrote:
> This pull-request has the following two dependencies:
>
> - The first pull-request, i.e. [GIT PULL 1/2] ARM: imx: soc changes for 3.14
>
> - The pinctrl 'devel' branch below.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
>
> Linus Walleij promised that the branch will be stable at least from
> the point I pulled into my tree, that is commit 31d610f (pinctrl:
> imx1-core populate subdevices).
>
> Please pull, thanks.
>
> Shawn
>
> .../devicetree/bindings/vendor-prefixes.txt | 3 +
> arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
> arch/arm/boot/dts/imx25-pingrp.h | 81 ++
> arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
> arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
> arch/arm/boot/dts/imx35-pingrp.h | 104 +++
> arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
> arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
> arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
> arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
> arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
> arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
> arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
> arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
> arch/arm/boot/dts/vf610-pingrp.h | 127 +++
Hm, these don't quite use include files the way include files were
originally meant to be used -- initially the idea was to use them to
define mostly simple constants instead of full properties like this.
I'm not against the idea of using it this way, but I also want to make sure the
DT maintainers are OK with it. So I've cc:d them on this reply.
I'm also not crazy about the insanely long identifiers used here, but I guess
they correlate with some user manual tables?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-02 20:21 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-02 20:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Dec 31, 2013 at 01:44:29PM +0800, Shawn Guo wrote:
> This pull-request has the following two dependencies:
>
> - The first pull-request, i.e. [GIT PULL 1/2] ARM: imx: soc changes for 3.14
>
> - The pinctrl 'devel' branch below.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
>
> Linus Walleij promised that the branch will be stable at least from
> the point I pulled into my tree, that is commit 31d610f (pinctrl:
> imx1-core populate subdevices).
>
> Please pull, thanks.
>
> Shawn
>
> .../devicetree/bindings/vendor-prefixes.txt | 3 +
> arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
> arch/arm/boot/dts/imx25-pingrp.h | 81 ++
> arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
> arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
> arch/arm/boot/dts/imx35-pingrp.h | 104 +++
> arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
> arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
> arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
> arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
> arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
> arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
> arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
> arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
> arch/arm/boot/dts/vf610-pingrp.h | 127 +++
Hm, these don't quite use include files the way include files were
originally meant to be used -- initially the idea was to use them to
define mostly simple constants instead of full properties like this.
I'm not against the idea of using it this way, but I also want to make sure the
DT maintainers are OK with it. So I've cc:d them on this reply.
I'm also not crazy about the insanely long identifiers used here, but I guess
they correlate with some user manual tables?
-Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-02 20:21 ` Olof Johansson
@ 2014-01-03 2:32 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-03 2:32 UTC (permalink / raw)
To: Olof Johansson
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi Olof,
On Thu, Jan 02, 2014 at 12:21:08PM -0800, Olof Johansson wrote:
> > .../devicetree/bindings/vendor-prefixes.txt | 3 +
> > arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
> > arch/arm/boot/dts/imx25-pingrp.h | 81 ++
> > arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
> > arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
> > arch/arm/boot/dts/imx35-pingrp.h | 104 +++
> > arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
> > arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
> > arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
> > arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
> > arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
> > arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
> > arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
> > arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
> > arch/arm/boot/dts/vf610-pingrp.h | 127 +++
>
> Hm, these don't quite use include files the way include files were
> originally meant to be used -- initially the idea was to use them to
> define mostly simple constants instead of full properties like this.
The DT macro support was introduced to improve the readability of device
tree sources by replacing those magic numbers with readable macros. I
think the usage in imx pinctrl binding perfectly fits the purpose. You
can get details of the binding in
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt.
>
> I'm not against the idea of using it this way, but I also want to make sure the
> DT maintainers are OK with it. So I've cc:d them on this reply.
This is not a new thing. It was firstly adopted for imx6q in v3.10
release with commit e164153 (pinctrl: imx: move hard-coding data into
device tree), which had been posted to devicetree list for sure. We're
just moving more i.MX SoCs to it.
>
> I'm also not crazy about the insanely long identifiers used here, but I guess
> they correlate with some user manual tables?
Yes, the identifiers follows the pad and function names from reference
manual.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-03 2:32 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-03 2:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof,
On Thu, Jan 02, 2014 at 12:21:08PM -0800, Olof Johansson wrote:
> > .../devicetree/bindings/vendor-prefixes.txt | 3 +
> > arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
> > arch/arm/boot/dts/imx25-pingrp.h | 81 ++
> > arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
> > arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
> > arch/arm/boot/dts/imx35-pingrp.h | 104 +++
> > arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
> > arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
> > arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
> > arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
> > arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
> > arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
> > arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
> > arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
> > arch/arm/boot/dts/vf610-pingrp.h | 127 +++
>
> Hm, these don't quite use include files the way include files were
> originally meant to be used -- initially the idea was to use them to
> define mostly simple constants instead of full properties like this.
The DT macro support was introduced to improve the readability of device
tree sources by replacing those magic numbers with readable macros. I
think the usage in imx pinctrl binding perfectly fits the purpose. You
can get details of the binding in
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt.
>
> I'm not against the idea of using it this way, but I also want to make sure the
> DT maintainers are OK with it. So I've cc:d them on this reply.
This is not a new thing. It was firstly adopted for imx6q in v3.10
release with commit e164153 (pinctrl: imx: move hard-coding data into
device tree), which had been posted to devicetree list for sure. We're
just moving more i.MX SoCs to it.
>
> I'm also not crazy about the insanely long identifiers used here, but I guess
> they correlate with some user manual tables?
Yes, the identifiers follows the pad and function names from reference
manual.
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-03 2:32 ` Shawn Guo
@ 2014-01-03 2:41 ` Olof Johansson
-1 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-03 2:41 UTC (permalink / raw)
To: Shawn Guo
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
On Thu, Jan 2, 2014 at 6:32 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Olof,
>
> On Thu, Jan 02, 2014 at 12:21:08PM -0800, Olof Johansson wrote:
>> > .../devicetree/bindings/vendor-prefixes.txt | 3 +
>> > arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
>> > arch/arm/boot/dts/imx25-pingrp.h | 81 ++
>> > arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
>> > arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
>> > arch/arm/boot/dts/imx35-pingrp.h | 104 +++
>> > arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
>> > arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
>> > arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
>> > arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
>> > arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
>> > arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
>> > arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
>> > arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
>> > arch/arm/boot/dts/vf610-pingrp.h | 127 +++
>>
>> Hm, these don't quite use include files the way include files were
>> originally meant to be used -- initially the idea was to use them to
>> define mostly simple constants instead of full properties like this.
>
> The DT macro support was introduced to improve the readability of device
> tree sources by replacing those magic numbers with readable macros. I
> think the usage in imx pinctrl binding perfectly fits the purpose. You
> can get details of the binding in
> Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt.
To be honest I didn't follow that discussion closely. If DT
maintainers are OK with that style, then I'm OK. :)
>> I'm not against the idea of using it this way, but I also want to make sure the
>> DT maintainers are OK with it. So I've cc:d them on this reply.
>
> This is not a new thing. It was firstly adopted for imx6q in v3.10
> release with commit e164153 (pinctrl: imx: move hard-coding data into
> device tree), which had been posted to devicetree list for sure. We're
> just moving more i.MX SoCs to it.
Ok, then it's probably just the location of the header files that
should be adjusted. Other subsystems have placed them under
include/dt-bindings/<subsystem>, so that's likely a better place for
these as well, don't you think?
>> I'm also not crazy about the insanely long identifiers used here, but I guess
>> they correlate with some user manual tables?
>
> Yes, the identifiers follows the pad and function names from reference
> manual.
Ok, fair enough.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-03 2:41 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-03 2:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 2, 2014 at 6:32 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Hi Olof,
>
> On Thu, Jan 02, 2014 at 12:21:08PM -0800, Olof Johansson wrote:
>> > .../devicetree/bindings/vendor-prefixes.txt | 3 +
>> > arch/arm/boot/dts/imx25-pinfunc.h | 494 +++++++++++
>> > arch/arm/boot/dts/imx25-pingrp.h | 81 ++
>> > arch/arm/boot/dts/imx27-pinfunc.h | 526 +++++++++++
>> > arch/arm/boot/dts/imx27-pingrp.h | 151 ++++
>> > arch/arm/boot/dts/imx35-pingrp.h | 104 +++
>> > arch/arm/boot/dts/imx50-pinfunc.h | 923 ++++++++++++++++++++
>> > arch/arm/boot/dts/imx50-pingrp.h | 146 ++++
>> > arch/arm/boot/dts/imx51-pingrp.h | 249 ++++++
>> > arch/arm/boot/dts/imx53-pingrp.h | 352 ++++++++
>> > arch/arm/boot/dts/imx6dl-pinfunc.h | 2 +
>> > arch/arm/boot/dts/imx6q-pinfunc.h | 2 +
>> > arch/arm/boot/dts/imx6qdl-pingrp.h | 532 +++++++++++
>> > arch/arm/boot/dts/imx6sl-pingrp.h | 148 ++++
>> > arch/arm/boot/dts/vf610-pingrp.h | 127 +++
>>
>> Hm, these don't quite use include files the way include files were
>> originally meant to be used -- initially the idea was to use them to
>> define mostly simple constants instead of full properties like this.
>
> The DT macro support was introduced to improve the readability of device
> tree sources by replacing those magic numbers with readable macros. I
> think the usage in imx pinctrl binding perfectly fits the purpose. You
> can get details of the binding in
> Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt.
To be honest I didn't follow that discussion closely. If DT
maintainers are OK with that style, then I'm OK. :)
>> I'm not against the idea of using it this way, but I also want to make sure the
>> DT maintainers are OK with it. So I've cc:d them on this reply.
>
> This is not a new thing. It was firstly adopted for imx6q in v3.10
> release with commit e164153 (pinctrl: imx: move hard-coding data into
> device tree), which had been posted to devicetree list for sure. We're
> just moving more i.MX SoCs to it.
Ok, then it's probably just the location of the header files that
should be adjusted. Other subsystems have placed them under
include/dt-bindings/<subsystem>, so that's likely a better place for
these as well, don't you think?
>> I'm also not crazy about the insanely long identifiers used here, but I guess
>> they correlate with some user manual tables?
>
> Yes, the identifiers follows the pad and function names from reference
> manual.
Ok, fair enough.
-Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-03 2:41 ` Olof Johansson
@ 2014-01-03 3:04 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-03 3:04 UTC (permalink / raw)
To: Olof Johansson
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> Ok, then it's probably just the location of the header files that
> should be adjusted. Other subsystems have placed them under
> include/dt-bindings/<subsystem>, so that's likely a better place for
> these as well, don't you think?
I had a little discussion with DT people when the headers were firstly
created. These pinctrl headers are a little different from the headers
in include/dt-bindings/<subsystem>. The latter are used by both kernel
and device tree sources, while the pinctrl headers are used by device
tree sources only, so I chose to put them just in the same folder as
dts files. And DT people are fine with my take.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-03 3:04 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-03 3:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> Ok, then it's probably just the location of the header files that
> should be adjusted. Other subsystems have placed them under
> include/dt-bindings/<subsystem>, so that's likely a better place for
> these as well, don't you think?
I had a little discussion with DT people when the headers were firstly
created. These pinctrl headers are a little different from the headers
in include/dt-bindings/<subsystem>. The latter are used by both kernel
and device tree sources, while the pinctrl headers are used by device
tree sources only, so I chose to put them just in the same folder as
dts files. And DT people are fine with my take.
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-03 3:04 ` Shawn Guo
@ 2014-01-03 19:29 ` Olof Johansson
-1 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-03 19:29 UTC (permalink / raw)
To: Shawn Guo
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tomasz Figa, Grant Likely,
Kumar Gala, Pawel Moll, Mark Rutland, Rob Herring
On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>> Ok, then it's probably just the location of the header files that
>> should be adjusted. Other subsystems have placed them under
>> include/dt-bindings/<subsystem>, so that's likely a better place for
>> these as well, don't you think?
>
> I had a little discussion with DT people when the headers were firstly
> created. These pinctrl headers are a little different from the headers
> in include/dt-bindings/<subsystem>. The latter are used by both kernel
> and device tree sources, while the pinctrl headers are used by device
> tree sources only, so I chose to put them just in the same folder as
> dts files. And DT people are fine with my take.
Since you don't provide references to this I had to go searching for
it. All I find is some discussion from 8 months ago, and quite a bit
of that seems to have been about changing bindings, and some about the
preprocessor behavior. Also, the patches seem to have been too big to
make it out on the lists.
I'd like a fresh look from DT people on this just to make sure no
opinions have changed -- lots of things have changed in the last 8
months w.r.t. DT.
I've pinged them on IRC, let's see if they wake up. Adding explicit cc too.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-03 19:29 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-03 19:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>> Ok, then it's probably just the location of the header files that
>> should be adjusted. Other subsystems have placed them under
>> include/dt-bindings/<subsystem>, so that's likely a better place for
>> these as well, don't you think?
>
> I had a little discussion with DT people when the headers were firstly
> created. These pinctrl headers are a little different from the headers
> in include/dt-bindings/<subsystem>. The latter are used by both kernel
> and device tree sources, while the pinctrl headers are used by device
> tree sources only, so I chose to put them just in the same folder as
> dts files. And DT people are fine with my take.
Since you don't provide references to this I had to go searching for
it. All I find is some discussion from 8 months ago, and quite a bit
of that seems to have been about changing bindings, and some about the
preprocessor behavior. Also, the patches seem to have been too big to
make it out on the lists.
I'd like a fresh look from DT people on this just to make sure no
opinions have changed -- lots of things have changed in the last 8
months w.r.t. DT.
I've pinged them on IRC, let's see if they wake up. Adding explicit cc too.
-Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-03 19:29 ` Olof Johansson
@ 2014-01-04 1:10 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-04 1:10 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, Pawel Moll, Linus Walleij,
Grant Likely, arm, Kumar Gala, Tomasz Figa, linux-arm-kernel
On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> >> Ok, then it's probably just the location of the header files that
> >> should be adjusted. Other subsystems have placed them under
> >> include/dt-bindings/<subsystem>, so that's likely a better place for
> >> these as well, don't you think?
> >
> > I had a little discussion with DT people when the headers were firstly
> > created. These pinctrl headers are a little different from the headers
> > in include/dt-bindings/<subsystem>. The latter are used by both kernel
> > and device tree sources, while the pinctrl headers are used by device
> > tree sources only, so I chose to put them just in the same folder as
> > dts files. And DT people are fine with my take.
>
> Since you don't provide references to this I had to go searching for
> it. All I find is some discussion from 8 months ago, and quite a bit
> of that seems to have been about changing bindings, and some about the
> preprocessor behavior. Also, the patches seem to have been too big to
> make it out on the lists.
>
> I'd like a fresh look from DT people on this just to make sure no
> opinions have changed -- lots of things have changed in the last 8
> months w.r.t. DT.
Indeed, it's been quite a long time. Let me restate my point. The
include/dt-bindings is introduced as a folder to hold headers that are
referenced by both kernel and DTS. That's why we create the folder in
the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
being a symbol link to it. All the headers in there need to be
duplicated between kernel and DTS tree, when we move DTS files into
a separated repository. Putting DTS local headers into the folder is
absolutely unnecessary, and will only confuse people and bother
ourselves when moving DTS files out of kernel tree.
Shawn
>
> I've pinged them on IRC, let's see if they wake up. Adding explicit cc too.
>
>
> -Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-04 1:10 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-04 1:10 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> >> Ok, then it's probably just the location of the header files that
> >> should be adjusted. Other subsystems have placed them under
> >> include/dt-bindings/<subsystem>, so that's likely a better place for
> >> these as well, don't you think?
> >
> > I had a little discussion with DT people when the headers were firstly
> > created. These pinctrl headers are a little different from the headers
> > in include/dt-bindings/<subsystem>. The latter are used by both kernel
> > and device tree sources, while the pinctrl headers are used by device
> > tree sources only, so I chose to put them just in the same folder as
> > dts files. And DT people are fine with my take.
>
> Since you don't provide references to this I had to go searching for
> it. All I find is some discussion from 8 months ago, and quite a bit
> of that seems to have been about changing bindings, and some about the
> preprocessor behavior. Also, the patches seem to have been too big to
> make it out on the lists.
>
> I'd like a fresh look from DT people on this just to make sure no
> opinions have changed -- lots of things have changed in the last 8
> months w.r.t. DT.
Indeed, it's been quite a long time. Let me restate my point. The
include/dt-bindings is introduced as a folder to hold headers that are
referenced by both kernel and DTS. That's why we create the folder in
the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
being a symbol link to it. All the headers in there need to be
duplicated between kernel and DTS tree, when we move DTS files into
a separated repository. Putting DTS local headers into the folder is
absolutely unnecessary, and will only confuse people and bother
ourselves when moving DTS files out of kernel tree.
Shawn
>
> I've pinged them on IRC, let's see if they wake up. Adding explicit cc too.
>
>
> -Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-04 1:10 ` Shawn Guo
@ 2014-01-10 2:41 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-10 2:41 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Linus Walleij, Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A,
Kumar Gala, Tomasz Figa,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
> > On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> > >> Ok, then it's probably just the location of the header files that
> > >> should be adjusted. Other subsystems have placed them under
> > >> include/dt-bindings/<subsystem>, so that's likely a better place for
> > >> these as well, don't you think?
> > >
> > > I had a little discussion with DT people when the headers were firstly
> > > created. These pinctrl headers are a little different from the headers
> > > in include/dt-bindings/<subsystem>. The latter are used by both kernel
> > > and device tree sources, while the pinctrl headers are used by device
> > > tree sources only, so I chose to put them just in the same folder as
> > > dts files. And DT people are fine with my take.
> >
> > Since you don't provide references to this I had to go searching for
> > it. All I find is some discussion from 8 months ago, and quite a bit
> > of that seems to have been about changing bindings, and some about the
> > preprocessor behavior. Also, the patches seem to have been too big to
> > make it out on the lists.
> >
> > I'd like a fresh look from DT people on this just to make sure no
> > opinions have changed -- lots of things have changed in the last 8
> > months w.r.t. DT.
>
> Indeed, it's been quite a long time. Let me restate my point. The
> include/dt-bindings is introduced as a folder to hold headers that are
> referenced by both kernel and DTS. That's why we create the folder in
> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
> being a symbol link to it. All the headers in there need to be
> duplicated between kernel and DTS tree, when we move DTS files into
> a separated repository. Putting DTS local headers into the folder is
> absolutely unnecessary, and will only confuse people and bother
> ourselves when moving DTS files out of kernel tree.
Just a gentle ping to ensure we do not get the pull request lost. Or do
you have any further comment?
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-10 2:41 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-10 2:41 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
> > On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
> > >> Ok, then it's probably just the location of the header files that
> > >> should be adjusted. Other subsystems have placed them under
> > >> include/dt-bindings/<subsystem>, so that's likely a better place for
> > >> these as well, don't you think?
> > >
> > > I had a little discussion with DT people when the headers were firstly
> > > created. These pinctrl headers are a little different from the headers
> > > in include/dt-bindings/<subsystem>. The latter are used by both kernel
> > > and device tree sources, while the pinctrl headers are used by device
> > > tree sources only, so I chose to put them just in the same folder as
> > > dts files. And DT people are fine with my take.
> >
> > Since you don't provide references to this I had to go searching for
> > it. All I find is some discussion from 8 months ago, and quite a bit
> > of that seems to have been about changing bindings, and some about the
> > preprocessor behavior. Also, the patches seem to have been too big to
> > make it out on the lists.
> >
> > I'd like a fresh look from DT people on this just to make sure no
> > opinions have changed -- lots of things have changed in the last 8
> > months w.r.t. DT.
>
> Indeed, it's been quite a long time. Let me restate my point. The
> include/dt-bindings is introduced as a folder to hold headers that are
> referenced by both kernel and DTS. That's why we create the folder in
> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
> being a symbol link to it. All the headers in there need to be
> duplicated between kernel and DTS tree, when we move DTS files into
> a separated repository. Putting DTS local headers into the folder is
> absolutely unnecessary, and will only confuse people and bother
> ourselves when moving DTS files out of kernel tree.
Just a gentle ping to ensure we do not get the pull request lost. Or do
you have any further comment?
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
2014-01-10 2:41 ` Shawn Guo
@ 2014-01-10 2:41 ` Olof Johansson
-1 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-10 2:41 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Linus Walleij, Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A,
Kumar Gala, Tomasz Figa,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>> > On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>> > >> Ok, then it's probably just the location of the header files that
>> > >> should be adjusted. Other subsystems have placed them under
>> > >> include/dt-bindings/<subsystem>, so that's likely a better place for
>> > >> these as well, don't you think?
>> > >
>> > > I had a little discussion with DT people when the headers were firstly
>> > > created. These pinctrl headers are a little different from the headers
>> > > in include/dt-bindings/<subsystem>. The latter are used by both kernel
>> > > and device tree sources, while the pinctrl headers are used by device
>> > > tree sources only, so I chose to put them just in the same folder as
>> > > dts files. And DT people are fine with my take.
>> >
>> > Since you don't provide references to this I had to go searching for
>> > it. All I find is some discussion from 8 months ago, and quite a bit
>> > of that seems to have been about changing bindings, and some about the
>> > preprocessor behavior. Also, the patches seem to have been too big to
>> > make it out on the lists.
>> >
>> > I'd like a fresh look from DT people on this just to make sure no
>> > opinions have changed -- lots of things have changed in the last 8
>> > months w.r.t. DT.
>>
>> Indeed, it's been quite a long time. Let me restate my point. The
>> include/dt-bindings is introduced as a folder to hold headers that are
>> referenced by both kernel and DTS. That's why we create the folder in
>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>> being a symbol link to it. All the headers in there need to be
>> duplicated between kernel and DTS tree, when we move DTS files into
>> a separated repository. Putting DTS local headers into the folder is
>> absolutely unnecessary, and will only confuse people and bother
>> ourselves when moving DTS files out of kernel tree.
>
> Just a gentle ping to ensure we do not get the pull request lost. Or do
> you have any further comment?
Still waiting on DT maintainers to chime in.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14)
@ 2014-01-10 2:41 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-10 2:41 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>> > On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>> > > On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>> > >> Ok, then it's probably just the location of the header files that
>> > >> should be adjusted. Other subsystems have placed them under
>> > >> include/dt-bindings/<subsystem>, so that's likely a better place for
>> > >> these as well, don't you think?
>> > >
>> > > I had a little discussion with DT people when the headers were firstly
>> > > created. These pinctrl headers are a little different from the headers
>> > > in include/dt-bindings/<subsystem>. The latter are used by both kernel
>> > > and device tree sources, while the pinctrl headers are used by device
>> > > tree sources only, so I chose to put them just in the same folder as
>> > > dts files. And DT people are fine with my take.
>> >
>> > Since you don't provide references to this I had to go searching for
>> > it. All I find is some discussion from 8 months ago, and quite a bit
>> > of that seems to have been about changing bindings, and some about the
>> > preprocessor behavior. Also, the patches seem to have been too big to
>> > make it out on the lists.
>> >
>> > I'd like a fresh look from DT people on this just to make sure no
>> > opinions have changed -- lots of things have changed in the last 8
>> > months w.r.t. DT.
>>
>> Indeed, it's been quite a long time. Let me restate my point. The
>> include/dt-bindings is introduced as a folder to hold headers that are
>> referenced by both kernel and DTS. That's why we create the folder in
>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>> being a symbol link to it. All the headers in there need to be
>> duplicated between kernel and DTS tree, when we move DTS files into
>> a separated repository. Putting DTS local headers into the folder is
>> absolutely unnecessary, and will only confuse people and bother
>> ourselves when moving DTS files out of kernel tree.
>
> Just a gentle ping to ensure we do not get the pull request lost. Or do
> you have any further comment?
Still waiting on DT maintainers to chime in.
-Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 2:41 ` Olof Johansson
@ 2014-01-10 13:28 ` Tomasz Figa
-1 siblings, 0 replies; 47+ messages in thread
From: Tomasz Figa @ 2014-01-10 13:28 UTC (permalink / raw)
To: Olof Johansson, Shawn Guo
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Linus Walleij, Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A,
Kumar Gala, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hi,
On 10.01.2014 03:41, Olof Johansson wrote:
> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>> Ok, then it's probably just the location of the header files that
>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>> these as well, don't you think?
>>>>>
>>>>> I had a little discussion with DT people when the headers were firstly
>>>>> created. These pinctrl headers are a little different from the headers
>>>>> in include/dt-bindings/<subsystem>. The latter are used by both kernel
>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>> dts files. And DT people are fine with my take.
>>>>
>>>> Since you don't provide references to this I had to go searching for
>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>> of that seems to have been about changing bindings, and some about the
>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>> make it out on the lists.
>>>>
>>>> I'd like a fresh look from DT people on this just to make sure no
>>>> opinions have changed -- lots of things have changed in the last 8
>>>> months w.r.t. DT.
>>>
>>> Indeed, it's been quite a long time. Let me restate my point. The
>>> include/dt-bindings is introduced as a folder to hold headers that are
>>> referenced by both kernel and DTS. That's why we create the folder in
>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>> being a symbol link to it. All the headers in there need to be
>>> duplicated between kernel and DTS tree, when we move DTS files into
>>> a separated repository. Putting DTS local headers into the folder is
>>> absolutely unnecessary, and will only confuse people and bother
>>> ourselves when moving DTS files out of kernel tree.
>>
>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>> you have any further comment?
>
> Still waiting on DT maintainers to chime in.
I'm not officially a DT maintainer, but let me share my thoughts on this.
So what options we have for this:
1) include/dt-bindings - this directory is designed to contain headers
that define the ABI between firmware and kernel code, in other
words - DT bindings.
2) arch/*/boot/dts - we already have files that can be included by
other files in this directory, i.e. *.dtsi. Some are used to
implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
purely used as headers (s3c64xx-pinctrl.dtsi).
3) include/dts? - I'm not sure if this have any benefits, but I'm
listing it since it's one of the ideas that came to my mind.
Now 2) seems to be already used and doesn't seem to generate any
problems, so I'm all for it. Still, there is one more issue. For files
to be included merely by DTS files and so limited by DTS+CPP syntax, I
don't think it's too good idea to call them *.h. Let's stay with *.dtsi,
since that's the file extension supposed to be used for files that can
be included from device tree sources.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-10 13:28 ` Tomasz Figa
0 siblings, 0 replies; 47+ messages in thread
From: Tomasz Figa @ 2014-01-10 13:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 10.01.2014 03:41, Olof Johansson wrote:
> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>> Ok, then it's probably just the location of the header files that
>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>> these as well, don't you think?
>>>>>
>>>>> I had a little discussion with DT people when the headers were firstly
>>>>> created. These pinctrl headers are a little different from the headers
>>>>> in include/dt-bindings/<subsystem>. The latter are used by both kernel
>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>> dts files. And DT people are fine with my take.
>>>>
>>>> Since you don't provide references to this I had to go searching for
>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>> of that seems to have been about changing bindings, and some about the
>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>> make it out on the lists.
>>>>
>>>> I'd like a fresh look from DT people on this just to make sure no
>>>> opinions have changed -- lots of things have changed in the last 8
>>>> months w.r.t. DT.
>>>
>>> Indeed, it's been quite a long time. Let me restate my point. The
>>> include/dt-bindings is introduced as a folder to hold headers that are
>>> referenced by both kernel and DTS. That's why we create the folder in
>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>> being a symbol link to it. All the headers in there need to be
>>> duplicated between kernel and DTS tree, when we move DTS files into
>>> a separated repository. Putting DTS local headers into the folder is
>>> absolutely unnecessary, and will only confuse people and bother
>>> ourselves when moving DTS files out of kernel tree.
>>
>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>> you have any further comment?
>
> Still waiting on DT maintainers to chime in.
I'm not officially a DT maintainer, but let me share my thoughts on this.
So what options we have for this:
1) include/dt-bindings - this directory is designed to contain headers
that define the ABI between firmware and kernel code, in other
words - DT bindings.
2) arch/*/boot/dts - we already have files that can be included by
other files in this directory, i.e. *.dtsi. Some are used to
implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
purely used as headers (s3c64xx-pinctrl.dtsi).
3) include/dts? - I'm not sure if this have any benefits, but I'm
listing it since it's one of the ideas that came to my mind.
Now 2) seems to be already used and doesn't seem to generate any
problems, so I'm all for it. Still, there is one more issue. For files
to be included merely by DTS files and so limited by DTS+CPP syntax, I
don't think it's too good idea to call them *.h. Let's stay with *.dtsi,
since that's the file extension supposed to be used for files that can
be included from device tree sources.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 13:28 ` Tomasz Figa
@ 2014-01-10 15:30 ` Rob Herring
-1 siblings, 0 replies; 47+ messages in thread
From: Rob Herring @ 2014-01-10 15:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: Olof Johansson, Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Jan 10, 2014 at 7:28 AM, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi,
>
> On 10.01.2014 03:41, Olof Johansson wrote:
>>
>> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>
>>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>>>
>>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>>>
>>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>>>
>>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>>>
>>>>>>> Ok, then it's probably just the location of the header files that
>>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>>> these as well, don't you think?
>>>>>>
>>>>>>
>>>>>> I had a little discussion with DT people when the headers were firstly
>>>>>> created. These pinctrl headers are a little different from the
>>>>>> headers
>>>>>> in include/dt-bindings/<subsystem>. The latter are used by both
>>>>>> kernel
>>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>>> dts files. And DT people are fine with my take.
>>>>>
>>>>>
>>>>> Since you don't provide references to this I had to go searching for
>>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>>> of that seems to have been about changing bindings, and some about the
>>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>>> make it out on the lists.
>>>>>
>>>>> I'd like a fresh look from DT people on this just to make sure no
>>>>> opinions have changed -- lots of things have changed in the last 8
>>>>> months w.r.t. DT.
>>>>
>>>>
>>>> Indeed, it's been quite a long time. Let me restate my point. The
>>>> include/dt-bindings is introduced as a folder to hold headers that are
>>>> referenced by both kernel and DTS. That's why we create the folder in
>>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>>> being a symbol link to it. All the headers in there need to be
>>>> duplicated between kernel and DTS tree, when we move DTS files into
>>>> a separated repository. Putting DTS local headers into the folder is
>>>> absolutely unnecessary, and will only confuse people and bother
>>>> ourselves when moving DTS files out of kernel tree.
>>>
>>>
>>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>>> you have any further comment?
>>
>>
>> Still waiting on DT maintainers to chime in.
It helps (slightly) to be copied directly.
> I'm not officially a DT maintainer, but let me share my thoughts on this.
We can fix that... :)
> So what options we have for this:
>
> 1) include/dt-bindings - this directory is designed to contain headers
> that define the ABI between firmware and kernel code, in other
> words - DT bindings.
>
> 2) arch/*/boot/dts - we already have files that can be included by
> other files in this directory, i.e. *.dtsi. Some are used to
> implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
> purely used as headers (s3c64xx-pinctrl.dtsi).
>
> 3) include/dts? - I'm not sure if this have any benefits, but I'm
> listing it since it's one of the ideas that came to my mind.
>
> Now 2) seems to be already used and doesn't seem to generate any problems,
> so I'm all for it. Still, there is one more issue. For files to be included
> merely by DTS files and so limited by DTS+CPP syntax, I don't think it's too
> good idea to call them *.h. Let's stay with *.dtsi, since that's the file
> extension supposed to be used for files that can be included from device
> tree sources.
I think having 1 and 2 is the right way. Minimizing the number of
shared headers between dts and the kernel is a good thing.
As for *.h vs. *.dtsi naming, if the include is only pre-processor
defines, then I think using .h is the right way. Otherwise, if there
is any dts syntax, then .dtsi is the right name. It looks to me like
this style has been followed in both the imx and s3c64xx cases.
On a side note, I'm not really a fan of this pattern:
#define FOO1 1 2 3
#define BAR FOO1 FOO2 FOO3
While it definitely simplifies the dts files, it would never be used
in C and obfuscates what the actual property size is. Reading a dts
file, I would naturally assume the define was a single value while in
fact it could expand to a very large property size.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-10 15:30 ` Rob Herring
0 siblings, 0 replies; 47+ messages in thread
From: Rob Herring @ 2014-01-10 15:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 10, 2014 at 7:28 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi,
>
> On 10.01.2014 03:41, Olof Johansson wrote:
>>
>> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>>
>>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>>>
>>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>>>
>>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>>>>>
>>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>>>
>>>>>>> Ok, then it's probably just the location of the header files that
>>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>>> these as well, don't you think?
>>>>>>
>>>>>>
>>>>>> I had a little discussion with DT people when the headers were firstly
>>>>>> created. These pinctrl headers are a little different from the
>>>>>> headers
>>>>>> in include/dt-bindings/<subsystem>. The latter are used by both
>>>>>> kernel
>>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>>> dts files. And DT people are fine with my take.
>>>>>
>>>>>
>>>>> Since you don't provide references to this I had to go searching for
>>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>>> of that seems to have been about changing bindings, and some about the
>>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>>> make it out on the lists.
>>>>>
>>>>> I'd like a fresh look from DT people on this just to make sure no
>>>>> opinions have changed -- lots of things have changed in the last 8
>>>>> months w.r.t. DT.
>>>>
>>>>
>>>> Indeed, it's been quite a long time. Let me restate my point. The
>>>> include/dt-bindings is introduced as a folder to hold headers that are
>>>> referenced by both kernel and DTS. That's why we create the folder in
>>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>>> being a symbol link to it. All the headers in there need to be
>>>> duplicated between kernel and DTS tree, when we move DTS files into
>>>> a separated repository. Putting DTS local headers into the folder is
>>>> absolutely unnecessary, and will only confuse people and bother
>>>> ourselves when moving DTS files out of kernel tree.
>>>
>>>
>>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>>> you have any further comment?
>>
>>
>> Still waiting on DT maintainers to chime in.
It helps (slightly) to be copied directly.
> I'm not officially a DT maintainer, but let me share my thoughts on this.
We can fix that... :)
> So what options we have for this:
>
> 1) include/dt-bindings - this directory is designed to contain headers
> that define the ABI between firmware and kernel code, in other
> words - DT bindings.
>
> 2) arch/*/boot/dts - we already have files that can be included by
> other files in this directory, i.e. *.dtsi. Some are used to
> implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
> purely used as headers (s3c64xx-pinctrl.dtsi).
>
> 3) include/dts? - I'm not sure if this have any benefits, but I'm
> listing it since it's one of the ideas that came to my mind.
>
> Now 2) seems to be already used and doesn't seem to generate any problems,
> so I'm all for it. Still, there is one more issue. For files to be included
> merely by DTS files and so limited by DTS+CPP syntax, I don't think it's too
> good idea to call them *.h. Let's stay with *.dtsi, since that's the file
> extension supposed to be used for files that can be included from device
> tree sources.
I think having 1 and 2 is the right way. Minimizing the number of
shared headers between dts and the kernel is a good thing.
As for *.h vs. *.dtsi naming, if the include is only pre-processor
defines, then I think using .h is the right way. Otherwise, if there
is any dts syntax, then .dtsi is the right name. It looks to me like
this style has been followed in both the imx and s3c64xx cases.
On a side note, I'm not really a fan of this pattern:
#define FOO1 1 2 3
#define BAR FOO1 FOO2 FOO3
While it definitely simplifies the dts files, it would never be used
in C and obfuscates what the actual property size is. Reading a dts
file, I would naturally assume the define was a single value while in
fact it could expand to a very large property size.
Rob
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 15:30 ` Rob Herring
@ 2014-01-10 17:03 ` Gerhard Sittig
-1 siblings, 0 replies; 47+ messages in thread
From: Gerhard Sittig @ 2014-01-10 17:03 UTC (permalink / raw)
To: Rob Herring
Cc: Tomasz Figa, Olof Johansson, Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
>
> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> defines, then I think using .h is the right way. Otherwise, if there
> is any dts syntax, then .dtsi is the right name. It looks to me like
> this style has been followed in both the imx and s3c64xx cases.
>
> On a side note, I'm not really a fan of this pattern:
>
> #define FOO1 1 2 3
>
> #define BAR FOO1 FOO2 FOO3
>
> While it definitely simplifies the dts files, it would never be used
> in C and obfuscates what the actual property size is. Reading a dts
> file, I would naturally assume the define was a single value while in
> fact it could expand to a very large property size.
For more complex yet tedious repetitive cases like GPIO banks and
pins I've seen #define directives which introduce "functions"
(macros with parameters). They appear to be rather useful, can
reflect very well the essence of the information, don't
necessarily pretend to be single values, but still may hide how
many cells they expand to. For example:
arch/arm/boot/dts/tegra30-cardhu.dtsi:
interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office-ynQEQJNshbs@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-10 17:03 ` Gerhard Sittig
0 siblings, 0 replies; 47+ messages in thread
From: Gerhard Sittig @ 2014-01-10 17:03 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
>
> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> defines, then I think using .h is the right way. Otherwise, if there
> is any dts syntax, then .dtsi is the right name. It looks to me like
> this style has been followed in both the imx and s3c64xx cases.
>
> On a side note, I'm not really a fan of this pattern:
>
> #define FOO1 1 2 3
>
> #define BAR FOO1 FOO2 FOO3
>
> While it definitely simplifies the dts files, it would never be used
> in C and obfuscates what the actual property size is. Reading a dts
> file, I would naturally assume the define was a single value while in
> fact it could expand to a very large property size.
For more complex yet tedious repetitive cases like GPIO banks and
pins I've seen #define directives which introduce "functions"
(macros with parameters). They appear to be rather useful, can
reflect very well the essence of the information, don't
necessarily pretend to be single values, but still may hide how
many cells they expand to. For example:
arch/arm/boot/dts/tegra30-cardhu.dtsi:
interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 15:30 ` Rob Herring
@ 2014-01-10 18:37 ` Olof Johansson
-1 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-10 18:37 UTC (permalink / raw)
To: Rob Herring
Cc: Tomasz Figa, Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Jan 10, 2014 at 7:30 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Jan 10, 2014 at 7:28 AM, Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>> Hi,
>>
>> On 10.01.2014 03:41, Olof Johansson wrote:
>>>
>>> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>
>>>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>>>>
>>>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>>>>
>>>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>>>>
>>>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>>>>
>>>>>>>> Ok, then it's probably just the location of the header files that
>>>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>>>> these as well, don't you think?
>>>>>>>
>>>>>>>
>>>>>>> I had a little discussion with DT people when the headers were firstly
>>>>>>> created. These pinctrl headers are a little different from the
>>>>>>> headers
>>>>>>> in include/dt-bindings/<subsystem>. The latter are used by both
>>>>>>> kernel
>>>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>>>> dts files. And DT people are fine with my take.
>>>>>>
>>>>>>
>>>>>> Since you don't provide references to this I had to go searching for
>>>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>>>> of that seems to have been about changing bindings, and some about the
>>>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>>>> make it out on the lists.
>>>>>>
>>>>>> I'd like a fresh look from DT people on this just to make sure no
>>>>>> opinions have changed -- lots of things have changed in the last 8
>>>>>> months w.r.t. DT.
>>>>>
>>>>>
>>>>> Indeed, it's been quite a long time. Let me restate my point. The
>>>>> include/dt-bindings is introduced as a folder to hold headers that are
>>>>> referenced by both kernel and DTS. That's why we create the folder in
>>>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>>>> being a symbol link to it. All the headers in there need to be
>>>>> duplicated between kernel and DTS tree, when we move DTS files into
>>>>> a separated repository. Putting DTS local headers into the folder is
>>>>> absolutely unnecessary, and will only confuse people and bother
>>>>> ourselves when moving DTS files out of kernel tree.
>>>>
>>>>
>>>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>>>> you have any further comment?
>>>
>>>
>>> Still waiting on DT maintainers to chime in.
>
> It helps (slightly) to be copied directly.
I should have copied you on some of the thread, but this was also
right around when your calxeda address was going away so I might have
missed you.
>
>> I'm not officially a DT maintainer, but let me share my thoughts on this.
>
> We can fix that... :)
>
>> So what options we have for this:
>>
>> 1) include/dt-bindings - this directory is designed to contain headers
>> that define the ABI between firmware and kernel code, in other
>> words - DT bindings.
>>
>> 2) arch/*/boot/dts - we already have files that can be included by
>> other files in this directory, i.e. *.dtsi. Some are used to
>> implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
>> purely used as headers (s3c64xx-pinctrl.dtsi).
>>
>> 3) include/dts? - I'm not sure if this have any benefits, but I'm
>> listing it since it's one of the ideas that came to my mind.
>>
>> Now 2) seems to be already used and doesn't seem to generate any problems,
>> so I'm all for it. Still, there is one more issue. For files to be included
>> merely by DTS files and so limited by DTS+CPP syntax, I don't think it's too
>> good idea to call them *.h. Let's stay with *.dtsi, since that's the file
>> extension supposed to be used for files that can be included from device
>> tree sources.
>
> I think having 1 and 2 is the right way. Minimizing the number of
> shared headers between dts and the kernel is a good thing.
>
> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> defines, then I think using .h is the right way. Otherwise, if there
> is any dts syntax, then .dtsi is the right name. It looks to me like
> this style has been followed in both the imx and s3c64xx cases.
I'm mostly reacting to the use of .h for something that isn't C
preprocessing. Since dtc/dts has their own namespace for everything
else, it seems appropriate to have something unique. But this is
pretty far up bikeshed alley.
> On a side note, I'm not really a fan of this pattern:
>
> #define FOO1 1 2 3
>
> #define BAR FOO1 FOO2 FOO3
>
> While it definitely simplifies the dts files, it would never be used
> in C and obfuscates what the actual property size is. Reading a dts
> file, I would naturally assume the define was a single value while in
> fact it could expand to a very large property size.
Hmm. Shawn?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-10 18:37 ` Olof Johansson
0 siblings, 0 replies; 47+ messages in thread
From: Olof Johansson @ 2014-01-10 18:37 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 10, 2014 at 7:30 AM, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Jan 10, 2014 at 7:28 AM, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hi,
>>
>> On 10.01.2014 03:41, Olof Johansson wrote:
>>>
>>> On Thu, Jan 9, 2014 at 6:41 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>>>
>>>> On Sat, Jan 04, 2014 at 09:10:58AM +0800, Shawn Guo wrote:
>>>>>
>>>>> On Fri, Jan 03, 2014 at 11:29:35AM -0800, Olof Johansson wrote:
>>>>>>
>>>>>> On Thu, Jan 2, 2014 at 7:04 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>>>>>>
>>>>>>> On Thu, Jan 02, 2014 at 06:41:30PM -0800, Olof Johansson wrote:
>>>>>>>>
>>>>>>>> Ok, then it's probably just the location of the header files that
>>>>>>>> should be adjusted. Other subsystems have placed them under
>>>>>>>> include/dt-bindings/<subsystem>, so that's likely a better place for
>>>>>>>> these as well, don't you think?
>>>>>>>
>>>>>>>
>>>>>>> I had a little discussion with DT people when the headers were firstly
>>>>>>> created. These pinctrl headers are a little different from the
>>>>>>> headers
>>>>>>> in include/dt-bindings/<subsystem>. The latter are used by both
>>>>>>> kernel
>>>>>>> and device tree sources, while the pinctrl headers are used by device
>>>>>>> tree sources only, so I chose to put them just in the same folder as
>>>>>>> dts files. And DT people are fine with my take.
>>>>>>
>>>>>>
>>>>>> Since you don't provide references to this I had to go searching for
>>>>>> it. All I find is some discussion from 8 months ago, and quite a bit
>>>>>> of that seems to have been about changing bindings, and some about the
>>>>>> preprocessor behavior. Also, the patches seem to have been too big to
>>>>>> make it out on the lists.
>>>>>>
>>>>>> I'd like a fresh look from DT people on this just to make sure no
>>>>>> opinions have changed -- lots of things have changed in the last 8
>>>>>> months w.r.t. DT.
>>>>>
>>>>>
>>>>> Indeed, it's been quite a long time. Let me restate my point. The
>>>>> include/dt-bindings is introduced as a folder to hold headers that are
>>>>> referenced by both kernel and DTS. That's why we create the folder in
>>>>> the kernel include folder and have arch/arm/boot/dts/include/dt-bindings
>>>>> being a symbol link to it. All the headers in there need to be
>>>>> duplicated between kernel and DTS tree, when we move DTS files into
>>>>> a separated repository. Putting DTS local headers into the folder is
>>>>> absolutely unnecessary, and will only confuse people and bother
>>>>> ourselves when moving DTS files out of kernel tree.
>>>>
>>>>
>>>> Just a gentle ping to ensure we do not get the pull request lost. Or do
>>>> you have any further comment?
>>>
>>>
>>> Still waiting on DT maintainers to chime in.
>
> It helps (slightly) to be copied directly.
I should have copied you on some of the thread, but this was also
right around when your calxeda address was going away so I might have
missed you.
>
>> I'm not officially a DT maintainer, but let me share my thoughts on this.
>
> We can fix that... :)
>
>> So what options we have for this:
>>
>> 1) include/dt-bindings - this directory is designed to contain headers
>> that define the ABI between firmware and kernel code, in other
>> words - DT bindings.
>>
>> 2) arch/*/boot/dts - we already have files that can be included by
>> other files in this directory, i.e. *.dtsi. Some are used to
>> implement hierarchies of devices (e.g. s3c64xx.dtsi), but some are
>> purely used as headers (s3c64xx-pinctrl.dtsi).
>>
>> 3) include/dts? - I'm not sure if this have any benefits, but I'm
>> listing it since it's one of the ideas that came to my mind.
>>
>> Now 2) seems to be already used and doesn't seem to generate any problems,
>> so I'm all for it. Still, there is one more issue. For files to be included
>> merely by DTS files and so limited by DTS+CPP syntax, I don't think it's too
>> good idea to call them *.h. Let's stay with *.dtsi, since that's the file
>> extension supposed to be used for files that can be included from device
>> tree sources.
>
> I think having 1 and 2 is the right way. Minimizing the number of
> shared headers between dts and the kernel is a good thing.
>
> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> defines, then I think using .h is the right way. Otherwise, if there
> is any dts syntax, then .dtsi is the right name. It looks to me like
> this style has been followed in both the imx and s3c64xx cases.
I'm mostly reacting to the use of .h for something that isn't C
preprocessing. Since dtc/dts has their own namespace for everything
else, it seems appropriate to have something unique. But this is
pretty far up bikeshed alley.
> On a side note, I'm not really a fan of this pattern:
>
> #define FOO1 1 2 3
>
> #define BAR FOO1 FOO2 FOO3
>
> While it definitely simplifies the dts files, it would never be used
> in C and obfuscates what the actual property size is. Reading a dts
> file, I would naturally assume the define was a single value while in
> fact it could expand to a very large property size.
Hmm. Shawn?
-Olof
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 18:37 ` Olof Johansson
@ 2014-01-11 3:12 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-11 3:12 UTC (permalink / raw)
To: Olof Johansson
Cc: Rob Herring, Tomasz Figa, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Jan 10, 2014 at 10:37:01AM -0800, Olof Johansson wrote:
> > On a side note, I'm not really a fan of this pattern:
> >
> > #define FOO1 1 2 3
> >
> > #define BAR FOO1 FOO2 FOO3
> >
> > While it definitely simplifies the dts files, it would never be used
> > in C and obfuscates what the actual property size is. Reading a dts
> > file, I would naturally assume the define was a single value while in
> > fact it could expand to a very large property size.
>
> Hmm. Shawn?
What I read from Rob is that he does not like it but he does not hate it
so much either. And that's probably why I did not get either ACK or
NACK from him when the usage was firstly introduced :)
While I agree such macro usage should be avoided or limited, it really
helps IMX pinctrl case to improve the readability and make the handwriting
of these pinctrl entries less error prone. Isn't it the whole point of
introducing macro support for DTC?
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-11 3:12 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-11 3:12 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 10, 2014 at 10:37:01AM -0800, Olof Johansson wrote:
> > On a side note, I'm not really a fan of this pattern:
> >
> > #define FOO1 1 2 3
> >
> > #define BAR FOO1 FOO2 FOO3
> >
> > While it definitely simplifies the dts files, it would never be used
> > in C and obfuscates what the actual property size is. Reading a dts
> > file, I would naturally assume the define was a single value while in
> > fact it could expand to a very large property size.
>
> Hmm. Shawn?
What I read from Rob is that he does not like it but he does not hate it
so much either. And that's probably why I did not get either ACK or
NACK from him when the usage was firstly introduced :)
While I agree such macro usage should be avoided or limited, it really
helps IMX pinctrl case to improve the readability and make the handwriting
of these pinctrl entries less error prone. Isn't it the whole point of
introducing macro support for DTC?
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-11 3:12 ` Shawn Guo
@ 2014-01-11 13:15 ` Arnd Bergmann
-1 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2014-01-11 13:15 UTC (permalink / raw)
To: Shawn Guo
Cc: Olof Johansson, Rob Herring, Tomasz Figa, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Saturday 11 January 2014, Shawn Guo wrote:
> While I agree such macro usage should be avoided or limited, it really
> helps IMX pinctrl case to improve the readability and make the handwriting
> of these pinctrl entries less error prone. Isn't it the whole point of
> introducing macro support for DTC?
The macros are useful for all cases where the binding defines an
arbitrary number space, e.g. for the interrupt flags or when a
clock or pin controller provides a set of pins/clocks that don't
already have a number assigned to them. In this case, the header
file can be shared between the dts and kernel source files to ensure
that they are talking about the same things.
However, I don't like to see uses of such macros where the definition
is done to match a hardware constant (bit number, register index, etc),
like in the recently posted eDMA driver case. Here the macro /reduces/
readability of the dts source IMHO, because you cannot easily check
the dts file against the data sheet without cross-referencing the
header file as well.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-11 13:15 ` Arnd Bergmann
0 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2014-01-11 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 11 January 2014, Shawn Guo wrote:
> While I agree such macro usage should be avoided or limited, it really
> helps IMX pinctrl case to improve the readability and make the handwriting
> of these pinctrl entries less error prone. Isn't it the whole point of
> introducing macro support for DTC?
The macros are useful for all cases where the binding defines an
arbitrary number space, e.g. for the interrupt flags or when a
clock or pin controller provides a set of pins/clocks that don't
already have a number assigned to them. In this case, the header
file can be shared between the dts and kernel source files to ensure
that they are talking about the same things.
However, I don't like to see uses of such macros where the definition
is done to match a hardware constant (bit number, register index, etc),
like in the recently posted eDMA driver case. Here the macro /reduces/
readability of the dts source IMHO, because you cannot easily check
the dts file against the data sheet without cross-referencing the
header file as well.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-11 13:15 ` Arnd Bergmann
@ 2014-01-12 3:25 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-12 3:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, devicetree, Pawel Moll, Tomasz Figa, Grant Likely,
arm, Kumar Gala, Olof Johansson, Linus Walleij, linux-arm-kernel
On Sat, Jan 11, 2014 at 02:15:28PM +0100, Arnd Bergmann wrote:
> On Saturday 11 January 2014, Shawn Guo wrote:
> > While I agree such macro usage should be avoided or limited, it really
> > helps IMX pinctrl case to improve the readability and make the handwriting
> > of these pinctrl entries less error prone. Isn't it the whole point of
> > introducing macro support for DTC?
>
> The macros are useful for all cases where the binding defines an
> arbitrary number space, e.g. for the interrupt flags or when a
> clock or pin controller provides a set of pins/clocks that don't
> already have a number assigned to them. In this case, the header
> file can be shared between the dts and kernel source files to ensure
> that they are talking about the same things.
>
> However, I don't like to see uses of such macros where the definition
> is done to match a hardware constant (bit number, register index, etc),
> like in the recently posted eDMA driver case. Here the macro /reduces/
> readability of the dts source IMHO, because you cannot easily check
> the dts file against the data sheet without cross-referencing the
> header file as well.
I agree with you that we shouldn't use macros for IP block resources
like irq number and dma channel. Once we code these SoC specific
data/number in <soc>.dtsi, all that board level dts files need to do
is to include <soc>.dtsi, nothing else. However, pinctrl data is a
different case. Which pin is in use, which mux option is selected for
the pin, how the pin should be configured, all these are board specific.
So these pinctrl configuration should be defined by individual board
level dts file rather than <soc>.dtsi.
Let's say the mux option SPDIF_OUT of pin GPIO_17 is used on a few board
designs, hummingboard, nitrogen6x and wandboard. If we do not use
macro, every author of these board dts files need to look into reference
manual to find out the following numbers
- The mux register offset of pin GPIO_17
- The select input register offset of pin GPIO_17
- The config register offset of pin GPIO_17
- The value of SPDIF_OUT mux option for GPIO_17
- The select input value of SPDIF_OUT mux option for GPIO_17
, and then code these numbers in their <board>.dts by hand. It's
boring and error prone. As a comparison, we generate these numbers
from reference manual database using a tool and define a macro
MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
Isn't the macro use here helping to ease everyone's life and make the
coding less error prone, since the macro is generated from database?
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-12 3:25 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-12 3:25 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jan 11, 2014 at 02:15:28PM +0100, Arnd Bergmann wrote:
> On Saturday 11 January 2014, Shawn Guo wrote:
> > While I agree such macro usage should be avoided or limited, it really
> > helps IMX pinctrl case to improve the readability and make the handwriting
> > of these pinctrl entries less error prone. Isn't it the whole point of
> > introducing macro support for DTC?
>
> The macros are useful for all cases where the binding defines an
> arbitrary number space, e.g. for the interrupt flags or when a
> clock or pin controller provides a set of pins/clocks that don't
> already have a number assigned to them. In this case, the header
> file can be shared between the dts and kernel source files to ensure
> that they are talking about the same things.
>
> However, I don't like to see uses of such macros where the definition
> is done to match a hardware constant (bit number, register index, etc),
> like in the recently posted eDMA driver case. Here the macro /reduces/
> readability of the dts source IMHO, because you cannot easily check
> the dts file against the data sheet without cross-referencing the
> header file as well.
I agree with you that we shouldn't use macros for IP block resources
like irq number and dma channel. Once we code these SoC specific
data/number in <soc>.dtsi, all that board level dts files need to do
is to include <soc>.dtsi, nothing else. However, pinctrl data is a
different case. Which pin is in use, which mux option is selected for
the pin, how the pin should be configured, all these are board specific.
So these pinctrl configuration should be defined by individual board
level dts file rather than <soc>.dtsi.
Let's say the mux option SPDIF_OUT of pin GPIO_17 is used on a few board
designs, hummingboard, nitrogen6x and wandboard. If we do not use
macro, every author of these board dts files need to look into reference
manual to find out the following numbers
- The mux register offset of pin GPIO_17
- The select input register offset of pin GPIO_17
- The config register offset of pin GPIO_17
- The value of SPDIF_OUT mux option for GPIO_17
- The select input value of SPDIF_OUT mux option for GPIO_17
, and then code these numbers in their <board>.dts by hand. It's
boring and error prone. As a comparison, we generate these numbers
from reference manual database using a tool and define a macro
MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
Isn't the macro use here helping to ease everyone's life and make the
coding less error prone, since the macro is generated from database?
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-12 3:25 ` Shawn Guo
@ 2014-01-12 20:21 ` Arnd Bergmann
-1 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2014-01-12 20:21 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Pawel Moll, Tomasz Figa, Grant Likely,
arm, Kumar Gala, Olof Johansson, Linus Walleij, linux-arm-kernel
On Sunday 12 January 2014, Shawn Guo wrote:
> Let's say the mux option SPDIF_OUT of pin GPIO_17 is used on a few board
> designs, hummingboard, nitrogen6x and wandboard. If we do not use
> macro, every author of these board dts files need to look into reference
> manual to find out the following numbers
>
> - The mux register offset of pin GPIO_17
> - The select input register offset of pin GPIO_17
> - The config register offset of pin GPIO_17
> - The value of SPDIF_OUT mux option for GPIO_17
> - The select input value of SPDIF_OUT mux option for GPIO_17
>
> , and then code these numbers in their <board>.dts by hand. It's
> boring and error prone. As a comparison, we generate these numbers
> from reference manual database using a tool and define a macro
> MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
> to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
> Isn't the macro use here helping to ease everyone's life and make the
> coding less error prone, since the macro is generated from database?
I was under the impression that the generic pinctrl binding was designed
in a way to let you assign labels to each possible (reasonable)
configuration so you didn't have get to this level of detail at the
driver. I'm also surprised that you have to know multiple constants
(mux register, input register, config register offsets) to select a
particular pin. I would have expected that you could have one constant
from which the driver is able to compute the other ones.
If you actually need the complexity that you describe in the board files,
the macros don't seem worse than the alternative, I would just be happier
if the pinctrl driver binding could do without them.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-12 20:21 ` Arnd Bergmann
0 siblings, 0 replies; 47+ messages in thread
From: Arnd Bergmann @ 2014-01-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
On Sunday 12 January 2014, Shawn Guo wrote:
> Let's say the mux option SPDIF_OUT of pin GPIO_17 is used on a few board
> designs, hummingboard, nitrogen6x and wandboard. If we do not use
> macro, every author of these board dts files need to look into reference
> manual to find out the following numbers
>
> - The mux register offset of pin GPIO_17
> - The select input register offset of pin GPIO_17
> - The config register offset of pin GPIO_17
> - The value of SPDIF_OUT mux option for GPIO_17
> - The select input value of SPDIF_OUT mux option for GPIO_17
>
> , and then code these numbers in their <board>.dts by hand. It's
> boring and error prone. As a comparison, we generate these numbers
> from reference manual database using a tool and define a macro
> MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
> to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
> Isn't the macro use here helping to ease everyone's life and make the
> coding less error prone, since the macro is generated from database?
I was under the impression that the generic pinctrl binding was designed
in a way to let you assign labels to each possible (reasonable)
configuration so you didn't have get to this level of detail at the
driver. I'm also surprised that you have to know multiple constants
(mux register, input register, config register offsets) to select a
particular pin. I would have expected that you could have one constant
from which the driver is able to compute the other ones.
If you actually need the complexity that you describe in the board files,
the macros don't seem worse than the alternative, I would just be happier
if the pinctrl driver binding could do without them.
Arnd
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-12 20:21 ` Arnd Bergmann
@ 2014-01-12 23:16 ` Linus Walleij
-1 siblings, 0 replies; 47+ messages in thread
From: Linus Walleij @ 2014-01-12 23:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Shawn Guo, Olof Johansson, Rob Herring, Tomasz Figa,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Sun, Jan 12, 2014 at 9:21 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Sunday 12 January 2014, Shawn Guo wrote:
>> , and then code these numbers in their <board>.dts by hand. It's
>> boring and error prone. As a comparison, we generate these numbers
>> from reference manual database using a tool and define a macro
>> MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
>> to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
>> Isn't the macro use here helping to ease everyone's life and make the
>> coding less error prone, since the macro is generated from database?
>
> I was under the impression that the generic pinctrl binding was designed
> in a way to let you assign labels to each possible (reasonable)
> configuration so you didn't have get to this level of detail at the
> driver.
There is a binding for handles and states tied to a device.
There is no generic pinctrl binding for the definition of groups
and functions and how they map, i.e. muxing.
The discussion around this ended up with everyone disagreeing
and eventually everybody started writing their own bindings and
have them merged.
There is a generic pin config binding, not everyone uses it,
as they defined their bindings before I got that in place. It
is mostly a requirement for newer drivers.
This Freescale driver does not use the generic binding but
instead it's homebrew thing. The reason being that there was
no generic binding around when it was defined and written.
It is possible to migrate it to generic pinconf, which would
be nice.
> I'm also surprised that you have to know multiple constants
> (mux register, input register, config register offsets) to select a
> particular pin. I would have expected that you could have one constant
> from which the driver is able to compute the other ones.
I might have merged this but I was younger then :-/
Now I don't like the looks of this. I think the DT typically shall not
store register offsets and bitfield information. I think doing
so is taking away the responsibility of the driver knowing the
hardware and moving too close to Open Firmware.
pinctrl-single does store such things, the reason being that
the OMAP people did not even have a datasheet for these regs,
all they get is datafiles from the ASIC engineers, so there is
nothing sensible to encode in the driver in C. But I'm reluctant
also about this driver.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-12 23:16 ` Linus Walleij
0 siblings, 0 replies; 47+ messages in thread
From: Linus Walleij @ 2014-01-12 23:16 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Jan 12, 2014 at 9:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 12 January 2014, Shawn Guo wrote:
>> , and then code these numbers in their <board>.dts by hand. It's
>> boring and error prone. As a comparison, we generate these numbers
>> from reference manual database using a tool and define a macro
>> MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers. The authors only need
>> to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
>> Isn't the macro use here helping to ease everyone's life and make the
>> coding less error prone, since the macro is generated from database?
>
> I was under the impression that the generic pinctrl binding was designed
> in a way to let you assign labels to each possible (reasonable)
> configuration so you didn't have get to this level of detail at the
> driver.
There is a binding for handles and states tied to a device.
There is no generic pinctrl binding for the definition of groups
and functions and how they map, i.e. muxing.
The discussion around this ended up with everyone disagreeing
and eventually everybody started writing their own bindings and
have them merged.
There is a generic pin config binding, not everyone uses it,
as they defined their bindings before I got that in place. It
is mostly a requirement for newer drivers.
This Freescale driver does not use the generic binding but
instead it's homebrew thing. The reason being that there was
no generic binding around when it was defined and written.
It is possible to migrate it to generic pinconf, which would
be nice.
> I'm also surprised that you have to know multiple constants
> (mux register, input register, config register offsets) to select a
> particular pin. I would have expected that you could have one constant
> from which the driver is able to compute the other ones.
I might have merged this but I was younger then :-/
Now I don't like the looks of this. I think the DT typically shall not
store register offsets and bitfield information. I think doing
so is taking away the responsibility of the driver knowing the
hardware and moving too close to Open Firmware.
pinctrl-single does store such things, the reason being that
the OMAP people did not even have a datasheet for these regs,
all they get is datafiles from the ASIC engineers, so there is
nothing sensible to encode in the driver in C. But I'm reluctant
also about this driver.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-12 20:21 ` Arnd Bergmann
@ 2014-01-13 2:19 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-13 2:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, devicetree, Pawel Moll, Tomasz Figa, Grant Likely,
arm, Kumar Gala, Olof Johansson, Linus Walleij, linux-arm-kernel
On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> I was under the impression that the generic pinctrl binding was designed
> in a way to let you assign labels to each possible (reasonable)
> configuration so you didn't have get to this level of detail at the
> driver.
The generic part of pinctrl binding only covers the procedure how a
client device get its pinctrl state configuration from a pin controller
node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
and implemented in pinctrl core. But the details of how a pinctrl state
configuration should be interpreted for a particular pin controller is
defined by individual pin controller binding like fsl,imx-pinctrl.txt,
and implemented in the pin controller driver like
drivers/pinctrl/pinctrl-imx.c.
> I'm also surprised that you have to know multiple constants
> (mux register, input register, config register offsets) to select a
> particular pin. I would have expected that you could have one constant
> from which the driver is able to compute the other ones.
That's what we do before. We define a constant in the binding and have
the driver to maintain these data and look up the data using the
constant. See commit below for imx6q example.
d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
The biggest problem with that approach is we have huge data to maintain
in the driver because of the complexity and flexibility of IMX pin
controller design. And these data can not be init data. Check that big
array of struct imx_pin_reg in commit above for what I'm talking about.
So when we build a v7 kernel image for IMX, we will have such big array
for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
more to come.
That's why we went through the pain of breaking DT compatibility to move
all these data into device tree one year ago with the commit below.
e164153 pinctrl: imx: move hard-coding data into device tree
Now kernel gets released from the floating and we do not even need to
touch kernel to add these data when new SoC support is added.
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-13 2:19 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-13 2:19 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> I was under the impression that the generic pinctrl binding was designed
> in a way to let you assign labels to each possible (reasonable)
> configuration so you didn't have get to this level of detail at the
> driver.
The generic part of pinctrl binding only covers the procedure how a
client device get its pinctrl state configuration from a pin controller
node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
and implemented in pinctrl core. But the details of how a pinctrl state
configuration should be interpreted for a particular pin controller is
defined by individual pin controller binding like fsl,imx-pinctrl.txt,
and implemented in the pin controller driver like
drivers/pinctrl/pinctrl-imx.c.
> I'm also surprised that you have to know multiple constants
> (mux register, input register, config register offsets) to select a
> particular pin. I would have expected that you could have one constant
> from which the driver is able to compute the other ones.
That's what we do before. We define a constant in the binding and have
the driver to maintain these data and look up the data using the
constant. See commit below for imx6q example.
d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
The biggest problem with that approach is we have huge data to maintain
in the driver because of the complexity and flexibility of IMX pin
controller design. And these data can not be init data. Check that big
array of struct imx_pin_reg in commit above for what I'm talking about.
So when we build a v7 kernel image for IMX, we will have such big array
for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
more to come.
That's why we went through the pain of breaking DT compatibility to move
all these data into device tree one year ago with the commit below.
e164153 pinctrl: imx: move hard-coding data into device tree
Now kernel gets released from the floating and we do not even need to
touch kernel to add these data when new SoC support is added.
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-12 23:16 ` Linus Walleij
@ 2014-01-13 2:31 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-13 2:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Olof Johansson, Rob Herring, Tomasz Figa,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Jan 13, 2014 at 12:16:10AM +0100, Linus Walleij wrote:
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> I might have merged this but I was younger then :-/
>
> Now I don't like the looks of this. I think the DT typically shall not
> store register offsets and bitfield information. I think doing
> so is taking away the responsibility of the driver knowing the
> hardware and moving too close to Open Firmware.
We only have data in device tree, and drivers, at least imx pinctrl
driver, still need to know hardware for how to apply these data into
hardware.
As I just replied to Arnd, all the motivation of having these data in
device tree is to release kernel from being bloated by those huge mount
of data due to the complexity and flexibility of IMX pin controller.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-13 2:31 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-13 2:31 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 13, 2014 at 12:16:10AM +0100, Linus Walleij wrote:
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> I might have merged this but I was younger then :-/
>
> Now I don't like the looks of this. I think the DT typically shall not
> store register offsets and bitfield information. I think doing
> so is taking away the responsibility of the driver knowing the
> hardware and moving too close to Open Firmware.
We only have data in device tree, and drivers, at least imx pinctrl
driver, still need to know hardware for how to apply these data into
hardware.
As I just replied to Arnd, all the motivation of having these data in
device tree is to release kernel from being bloated by those huge mount
of data due to the complexity and flexibility of IMX pin controller.
Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-10 17:03 ` Gerhard Sittig
@ 2014-01-13 16:48 ` Stephen Warren
-1 siblings, 0 replies; 47+ messages in thread
From: Stephen Warren @ 2014-01-13 16:48 UTC (permalink / raw)
To: Gerhard Sittig, Rob Herring
Cc: Tomasz Figa, Olof Johansson, Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Linus Walleij,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 01/10/2014 10:03 AM, Gerhard Sittig wrote:
> On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
>>
>> As for *.h vs. *.dtsi naming, if the include is only pre-processor
>> defines, then I think using .h is the right way. Otherwise, if there
>> is any dts syntax, then .dtsi is the right name. It looks to me like
>> this style has been followed in both the imx and s3c64xx cases.
>>
>> On a side note, I'm not really a fan of this pattern:
>>
>> #define FOO1 1 2 3
>>
>> #define BAR FOO1 FOO2 FOO3
>>
>> While it definitely simplifies the dts files, it would never be used
>> in C and obfuscates what the actual property size is. Reading a dts
>> file, I would naturally assume the define was a single value while in
>> fact it could expand to a very large property size.
>
> For more complex yet tedious repetitive cases like GPIO banks and
> pins I've seen #define directives which introduce "functions"
> (macros with parameters). They appear to be rather useful, can
> reflect very well the essence of the information, don't
> necessarily pretend to be single values, but still may hide how
> many cells they expand to. For example:
>
> arch/arm/boot/dts/tegra30-cardhu.dtsi:
> interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
I'm not sure I entirely understand your point, but for the record, both
TEGRA_GPIO() and IRQ_TYPE_LEVEL_HIGH expand to a single cell, as I would
expect (almost?) any DT macro to do.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-13 16:48 ` Stephen Warren
0 siblings, 0 replies; 47+ messages in thread
From: Stephen Warren @ 2014-01-13 16:48 UTC (permalink / raw)
To: linux-arm-kernel
On 01/10/2014 10:03 AM, Gerhard Sittig wrote:
> On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
>>
>> As for *.h vs. *.dtsi naming, if the include is only pre-processor
>> defines, then I think using .h is the right way. Otherwise, if there
>> is any dts syntax, then .dtsi is the right name. It looks to me like
>> this style has been followed in both the imx and s3c64xx cases.
>>
>> On a side note, I'm not really a fan of this pattern:
>>
>> #define FOO1 1 2 3
>>
>> #define BAR FOO1 FOO2 FOO3
>>
>> While it definitely simplifies the dts files, it would never be used
>> in C and obfuscates what the actual property size is. Reading a dts
>> file, I would naturally assume the define was a single value while in
>> fact it could expand to a very large property size.
>
> For more complex yet tedious repetitive cases like GPIO banks and
> pins I've seen #define directives which introduce "functions"
> (macros with parameters). They appear to be rather useful, can
> reflect very well the essence of the information, don't
> necessarily pretend to be single values, but still may hide how
> many cells they expand to. For example:
>
> arch/arm/boot/dts/tegra30-cardhu.dtsi:
> interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
I'm not sure I entirely understand your point, but for the record, both
TEGRA_GPIO() and IRQ_TYPE_LEVEL_HIGH expand to a single cell, as I would
expect (almost?) any DT macro to do.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-13 16:48 ` Stephen Warren
@ 2014-01-13 18:10 ` Gerhard Sittig
-1 siblings, 0 replies; 47+ messages in thread
From: Gerhard Sittig @ 2014-01-13 18:10 UTC (permalink / raw)
To: Stephen Warren
Cc: Rob Herring, Tomasz Figa, Olof Johansson, Shawn Guo,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Linus Walleij, Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A,
Kumar Gala, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Jan 13, 2014 at 09:48 -0700, Stephen Warren wrote:
>
> On 01/10/2014 10:03 AM, Gerhard Sittig wrote:
> > On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
> >>
> >> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> >> defines, then I think using .h is the right way. Otherwise, if there
> >> is any dts syntax, then .dtsi is the right name. It looks to me like
> >> this style has been followed in both the imx and s3c64xx cases.
> >>
> >> On a side note, I'm not really a fan of this pattern:
> >>
> >> #define FOO1 1 2 3
> >>
> >> #define BAR FOO1 FOO2 FOO3
> >>
> >> While it definitely simplifies the dts files, it would never be used
> >> in C and obfuscates what the actual property size is. Reading a dts
> >> file, I would naturally assume the define was a single value while in
> >> fact it could expand to a very large property size.
> >
> > For more complex yet tedious repetitive cases like GPIO banks and
> > pins I've seen #define directives which introduce "functions"
> > (macros with parameters). They appear to be rather useful, can
> > reflect very well the essence of the information, don't
> > necessarily pretend to be single values, but still may hide how
> > many cells they expand to. For example:
> >
> > arch/arm/boot/dts/tegra30-cardhu.dtsi:
> > interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
>
> I'm not sure I entirely understand your point, but for the record, both
> TEGRA_GPIO() and IRQ_TYPE_LEVEL_HIGH expand to a single cell, as I would
> expect (almost?) any DT macro to do.
It turns out I slightly misunderstood Rob's concern. The issue
is not that the use of the C language preprocessor is discouraged
or frouned upon, but instead that obfuscating invariant data or
spilling random parts of the information across the place in
unneeded ways is unwanted. While there is agreement that the use
of symbolic identifiers can help readability and maintainability
in certain situations.
Regarding your specific reply: I haven't noticed before that all
of the macros I cited do expand to a single cell. Before that I
saw the potential to generate more cells when required for a
single value (like "wide" addresses, or multi cell pins or
channels or whatever). Can't tell how much of a concern there is
against such an approach, don't have strong feelings about it.
Actually I wasn't picking at those specific macros above, quite
the contrary. Those were the first I came across searching for
demonstration of useful preprocessor use. :) I just did not
bother to cite several hundred other useful phrases as well.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office-ynQEQJNshbs@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-13 18:10 ` Gerhard Sittig
0 siblings, 0 replies; 47+ messages in thread
From: Gerhard Sittig @ 2014-01-13 18:10 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 13, 2014 at 09:48 -0700, Stephen Warren wrote:
>
> On 01/10/2014 10:03 AM, Gerhard Sittig wrote:
> > On Fri, Jan 10, 2014 at 09:30 -0600, Rob Herring wrote:
> >>
> >> As for *.h vs. *.dtsi naming, if the include is only pre-processor
> >> defines, then I think using .h is the right way. Otherwise, if there
> >> is any dts syntax, then .dtsi is the right name. It looks to me like
> >> this style has been followed in both the imx and s3c64xx cases.
> >>
> >> On a side note, I'm not really a fan of this pattern:
> >>
> >> #define FOO1 1 2 3
> >>
> >> #define BAR FOO1 FOO2 FOO3
> >>
> >> While it definitely simplifies the dts files, it would never be used
> >> in C and obfuscates what the actual property size is. Reading a dts
> >> file, I would naturally assume the define was a single value while in
> >> fact it could expand to a very large property size.
> >
> > For more complex yet tedious repetitive cases like GPIO banks and
> > pins I've seen #define directives which introduce "functions"
> > (macros with parameters). They appear to be rather useful, can
> > reflect very well the essence of the information, don't
> > necessarily pretend to be single values, but still may hide how
> > many cells they expand to. For example:
> >
> > arch/arm/boot/dts/tegra30-cardhu.dtsi:
> > interrupts = <TEGRA_GPIO(L, 0) IRQ_TYPE_LEVEL_HIGH>;
>
> I'm not sure I entirely understand your point, but for the record, both
> TEGRA_GPIO() and IRQ_TYPE_LEVEL_HIGH expand to a single cell, as I would
> expect (almost?) any DT macro to do.
It turns out I slightly misunderstood Rob's concern. The issue
is not that the use of the C language preprocessor is discouraged
or frouned upon, but instead that obfuscating invariant data or
spilling random parts of the information across the place in
unneeded ways is unwanted. While there is agreement that the use
of symbolic identifiers can help readability and maintainability
in certain situations.
Regarding your specific reply: I haven't noticed before that all
of the macros I cited do expand to a single cell. Before that I
saw the potential to generate more cells when required for a
single value (like "wide" addresses, or multi cell pins or
channels or whatever). Can't tell how much of a concern there is
against such an approach, don't have strong feelings about it.
Actually I wasn't picking at those specific macros above, quite
the contrary. Those were the first I came across searching for
demonstration of useful preprocessor use. :) I just did not
bother to cite several hundred other useful phrases as well.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-13 2:19 ` Shawn Guo
@ 2014-01-24 8:02 ` Heiko Stübner
-1 siblings, 0 replies; 47+ messages in thread
From: Heiko Stübner @ 2014-01-24 8:02 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Shawn Guo, Arnd Bergmann, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll, Tomasz Figa,
Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A, Kumar Gala,
Olof Johansson, Linus Walleij
Hi Shawn,
did this topic get any final resolution - especially in terms of the pingrp.h
header?
As I'm currently preparing two board files (imx50 and imx6sl) this discussion
made me unsure if using the pin-group definitions is still the preferred style.
Thanks
Heiko
On Monday 13 January 2014 10:19:14 Shawn Guo wrote:
> On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> > I was under the impression that the generic pinctrl binding was designed
> > in a way to let you assign labels to each possible (reasonable)
> > configuration so you didn't have get to this level of detail at the
> > driver.
>
> The generic part of pinctrl binding only covers the procedure how a
> client device get its pinctrl state configuration from a pin controller
> node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
> and implemented in pinctrl core. But the details of how a pinctrl state
> configuration should be interpreted for a particular pin controller is
> defined by individual pin controller binding like fsl,imx-pinctrl.txt,
> and implemented in the pin controller driver like
> drivers/pinctrl/pinctrl-imx.c.
>
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> That's what we do before. We define a constant in the binding and have
> the driver to maintain these data and look up the data using the
> constant. See commit below for imx6q example.
>
> d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
>
> The biggest problem with that approach is we have huge data to maintain
> in the driver because of the complexity and flexibility of IMX pin
> controller design. And these data can not be init data. Check that big
> array of struct imx_pin_reg in commit above for what I'm talking about.
> So when we build a v7 kernel image for IMX, we will have such big array
> for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
> more to come.
>
> That's why we went through the pain of breaking DT compatibility to move
> all these data into device tree one year ago with the commit below.
>
> e164153 pinctrl: imx: move hard-coding data into device tree
>
> Now kernel gets released from the floating and we do not even need to
> touch kernel to add these data when new SoC support is added.
>
> Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-24 8:02 ` Heiko Stübner
0 siblings, 0 replies; 47+ messages in thread
From: Heiko Stübner @ 2014-01-24 8:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Shawn,
did this topic get any final resolution - especially in terms of the pingrp.h
header?
As I'm currently preparing two board files (imx50 and imx6sl) this discussion
made me unsure if using the pin-group definitions is still the preferred style.
Thanks
Heiko
On Monday 13 January 2014 10:19:14 Shawn Guo wrote:
> On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> > I was under the impression that the generic pinctrl binding was designed
> > in a way to let you assign labels to each possible (reasonable)
> > configuration so you didn't have get to this level of detail at the
> > driver.
>
> The generic part of pinctrl binding only covers the procedure how a
> client device get its pinctrl state configuration from a pin controller
> node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
> and implemented in pinctrl core. But the details of how a pinctrl state
> configuration should be interpreted for a particular pin controller is
> defined by individual pin controller binding like fsl,imx-pinctrl.txt,
> and implemented in the pin controller driver like
> drivers/pinctrl/pinctrl-imx.c.
>
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> That's what we do before. We define a constant in the binding and have
> the driver to maintain these data and look up the data using the
> constant. See commit below for imx6q example.
>
> d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
>
> The biggest problem with that approach is we have huge data to maintain
> in the driver because of the complexity and flexibility of IMX pin
> controller design. And these data can not be init data. Check that big
> array of struct imx_pin_reg in commit above for what I'm talking about.
> So when we build a v7 kernel image for IMX, we will have such big array
> for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
> more to come.
>
> That's why we went through the pain of breaking DT compatibility to move
> all these data into device tree one year ago with the commit below.
>
> e164153 pinctrl: imx: move hard-coding data into device tree
>
> Now kernel gets released from the floating and we do not even need to
> touch kernel to add these data when new SoC support is added.
>
> Shawn
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: DT include files
2014-01-24 8:02 ` Heiko Stübner
@ 2014-01-25 2:25 ` Shawn Guo
-1 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-25 2:25 UTC (permalink / raw)
To: Heiko Stübner
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Arnd Bergmann,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Pawel Moll,
Tomasz Figa, Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A,
Kumar Gala, Olof Johansson, Linus Walleij
On Fri, Jan 24, 2014 at 09:02:09AM +0100, Heiko Stübner wrote:
> Hi Shawn,
>
> did this topic get any final resolution - especially in terms of the pingrp.h
> header?
>
> As I'm currently preparing two board files (imx50 and imx6sl) this discussion
> made me unsure if using the pin-group definitions is still the preferred style.
Yes, we need to get a conclusion ASAP. The whole imx-dt-3.14 pull
request has been held for a few weeks because of that, and I'm asking
for direction there [1].
Shawn
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/58685/focus=296761
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* DT include files
@ 2014-01-25 2:25 ` Shawn Guo
0 siblings, 0 replies; 47+ messages in thread
From: Shawn Guo @ 2014-01-25 2:25 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 24, 2014 at 09:02:09AM +0100, Heiko St?bner wrote:
> Hi Shawn,
>
> did this topic get any final resolution - especially in terms of the pingrp.h
> header?
>
> As I'm currently preparing two board files (imx50 and imx6sl) this discussion
> made me unsure if using the pin-group definitions is still the preferred style.
Yes, we need to get a conclusion ASAP. The whole imx-dt-3.14 pull
request has been held for a few weeks because of that, and I'm asking
for direction there [1].
Shawn
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/58685/focus=296761
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2014-01-25 2:25 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-31 5:44 [GIT PULL 2/2] ARM: imx: device tree changes for 3.14 Shawn Guo
[not found] ` <20131231054427.GA22383-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-02 20:21 ` DT include files (was: [GIT PULL 2/2] ARM: imx: device tree changes for 3.14) Olof Johansson
2014-01-02 20:21 ` Olof Johansson
[not found] ` <20140102202108.GF19720-O5ziIzlqnXUVNXGz7ipsyg@public.gmane.org>
2014-01-03 2:32 ` Shawn Guo
2014-01-03 2:32 ` Shawn Guo
[not found] ` <20140103023211.GA25079-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-03 2:41 ` Olof Johansson
2014-01-03 2:41 ` Olof Johansson
[not found] ` <CAOesGMheei8YgzfRp9pmQ0rT9zhJ2_hF56j5Y+jLSy5TadPZ-g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-03 3:04 ` Shawn Guo
2014-01-03 3:04 ` Shawn Guo
[not found] ` <20140103030455.GB25079-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-03 19:29 ` Olof Johansson
2014-01-03 19:29 ` Olof Johansson
2014-01-04 1:10 ` Shawn Guo
2014-01-04 1:10 ` Shawn Guo
[not found] ` <20140104011056.GA3282-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-10 2:41 ` Shawn Guo
2014-01-10 2:41 ` Shawn Guo
[not found] ` <20140110024124.GA6844-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-10 2:41 ` Olof Johansson
2014-01-10 2:41 ` Olof Johansson
[not found] ` <CAOesGMh3HBCYut2hfub3svrJT5JJzoWq8mU=VU0grZbg-JqqbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-10 13:28 ` DT include files Tomasz Figa
2014-01-10 13:28 ` Tomasz Figa
[not found] ` <52CFF57D.8060808-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-01-10 15:30 ` Rob Herring
2014-01-10 15:30 ` Rob Herring
[not found] ` <CAL_JsqKHr6v+6kNXrAdnzH0gpoFCPAjPSnX8iBDgRSMh9JgxvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-10 17:03 ` Gerhard Sittig
2014-01-10 17:03 ` Gerhard Sittig
[not found] ` <20140110170319.GC20094-kDjWylLy9wD0K7fsECOQyeGNnDKD8DIp@public.gmane.org>
2014-01-13 16:48 ` Stephen Warren
2014-01-13 16:48 ` Stephen Warren
[not found] ` <52D418EB.1040605-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-13 18:10 ` Gerhard Sittig
2014-01-13 18:10 ` Gerhard Sittig
2014-01-10 18:37 ` Olof Johansson
2014-01-10 18:37 ` Olof Johansson
[not found] ` <CAOesGMhP5t=QHj7TdDY9Nq+=WHeQXv1V0n9TGmmEnqSG9SaFKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-11 3:12 ` Shawn Guo
2014-01-11 3:12 ` Shawn Guo
[not found] ` <20140111031214.GK21717-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-11 13:15 ` Arnd Bergmann
2014-01-11 13:15 ` Arnd Bergmann
2014-01-12 3:25 ` Shawn Guo
2014-01-12 3:25 ` Shawn Guo
2014-01-12 20:21 ` Arnd Bergmann
2014-01-12 20:21 ` Arnd Bergmann
[not found] ` <201401122121.20084.arnd-r2nGTMty4D4@public.gmane.org>
2014-01-12 23:16 ` Linus Walleij
2014-01-12 23:16 ` Linus Walleij
[not found] ` <CACRpkdYPrso7KSfWPhZC6chA4z=+YSjKb_SCLx4B-aMmYZYb4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-13 2:31 ` Shawn Guo
2014-01-13 2:31 ` Shawn Guo
2014-01-13 2:19 ` Shawn Guo
2014-01-13 2:19 ` Shawn Guo
[not found] ` <20140113021912.GB23525-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-01-24 8:02 ` Heiko Stübner
2014-01-24 8:02 ` Heiko Stübner
2014-01-25 2:25 ` Shawn Guo
2014-01-25 2:25 ` Shawn Guo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.