[PATCH 2/2] arm/layerscape: add RCPM device tree support for ls1021a.
From: Wang Dongsheng
Signed-off-by: Wang Dongsheng
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 973a496..deb1271 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -139,6 +139,7 @@
sdhci,auto-cmd12;
big-endian;
bus-width = <4>;
+ rcpm-wakeup = <&rcpm 0x0080 0x0>;
status = "disabled";
};
@@ -186,6 +187,11 @@
};
};
+ rcpm: rcpm@1ee2000 {
+ compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1";
+ reg = <0x0 0x1ee2000 0x0 0x1>;
+ };
+
dspi0: dspi@210 {
compatible = "fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
@@ -287,6 +293,7 @@
interrupts = ;
clocks = <&sysclk>;
clock-names = "ipg";
+ rcpm-wakeup = <&rcpm 0x0 0x4000>;
status = "disabled";
};
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] fsl: Add binding for RCPM
From: Wang Dongsheng
RCPM is the Run Control and Power Management module performs all
device-level tasks associated with device run control and power
management.
Add this for freescale powerpc platform and layerscape platform.
Signed-off-by: Chenhui Zhao
Signed-off-by: Tang Yuantian
Signed-off-by: Wang Dongsheng
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..284070c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,64 @@
+* Run Control and Power Management
+---
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+ - reg : Offset and length of the register set of RCPM block.
+ - compatible : Sould contain a chip-specific RCPM block compatible string
+ and (if applicable) may contain a chassis-version RCPM compatible
string.
+ Chip-specific strings are of the form "fsl,-rcpm", such as:
+ * "fsl,p2041-rcpm"
+ * "fsl,p3041-rcpm"
+ * "fsl,p4080-rcpm"
+ * "fsl,p5020-rcpm"
+ * "fsl,p5040-rcpm"
+ * "fsl,t4240-rcpm"
+ * "fsl,b4420-rcpm"
+ * "fsl,b4860-rcpm"
+
+ Chassis-version strings are of the form "fsl,qoriq-rcpm-",
+ such as:
+ * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
+ * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
+ * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+
+All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+which the chip complies.
+Chassis VersionExample Chips
+------
+1.0p4080, p5020, p5040, p2041, p3041
+2.0t4240, b4860, b4420
+2.1t1040, ls1021
+
+Example:
+The RCPM node for T4240:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+The RCPM node for P4080:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+* Freescale RCPM Wakeup Source Device Tree Bindings
+---
+Required rcpm-wakeup property should be added to a device node if the device
+can be used as a wakeup source.
+
+ - rcpm-wakeup: should contain a pointer to the rcpm node and the
+ corresponding bit of device in the register.
+
+Example:
+ lpuart0: serial@295 {
+ compatible = "fsl,ls1021a-lpuart";
+ reg = <0x0 0x295 0x0 0x1000>;
+ interrupts = ;
+ clocks = <&sysclk>;
+ clock-names = "ipg";
+ rcpm-wakeup = <&rcpm 0x0 0x4000>;
+ status = "disabled";
+ };
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/6] pci:host: Add Altera PCIe host controller driver
On Tue, Sep 8, 2015 at 5:19 PM, Lorenzo Pieralisi
wrote:
> On Fri, Sep 04, 2015 at 09:29:14AM +0100, Ley Foon Tan wrote:
>> On Wed, Sep 2, 2015 at 12:33 AM, Lorenzo Pieralisi
>> wrote:
>
> [...]
>
>> > > +static bool altera_pcie_valid_config(struct altera_pcie *pcie,
>> > > +struct pci_bus *bus, int dev)
>> > > +{
>> > > + /* If there is no link, then there is no device */
>> > > + if (bus->number != pcie->root_bus_nr) {
>> > > + if (!altera_pcie_link_is_up(pcie))
>> > > + return false;
>> > > + }
>> >
>> > Can you explain to pls me why you have to check this for every config
>> > transaction ? Isn't it something that can prevent probing the
>> > host controller altogether ?
>> In our PCIe hardware spec, it stated that software should check the
>> link status before issuing a configuration request to downstream
>> ports.
>> BTW, other pci controllers have similar implementation as well, eg: dw
>> pci, mvebu pci.
>
> Understood, thanks.
>
> [...]
>
>> > > +static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
>> > > +{
>> > > + u8 loop;
>> > > + struct tlp_rp_regpair_t tlp_rp_regdata;
>> > > +
>> > > + for (loop = 0; loop < TLP_LOOP; loop++) {
>> > > + tlp_read_rx(pcie, &tlp_rp_regdata);
>> > > + if (tlp_rp_regdata.ctrl & RP_RXCPL_EOP) {
>> > > + if (value)
>> > > + *value = tlp_rp_regdata.reg0;
>> > > + return PCIBIOS_SUCCESSFUL;
>> > > + }
>> > > + udelay(5);
>> >
>> > Could you comment please on the chosen udelay/TLP_LOOP values (ie how
>> > did you come up with them) ?
>> For udelay value, we just want to have small delay between each read.
>
> I would explain how you chose the value, in particular if it can
> affect next generation hosts sharing the same driver.
Actually, we don't have any calculation to choose the value. Just want
to give small relaxation between each read.
It is request from Marc in previous review.
>
>> For TLP_LOOP value, minimum 2 loops to read tlp headers and 1 loop to
>> read data payload. So, we choose to poll 10 loops for maximum.
>
> Add it to a comment.
Okay.
>
[...]
>> >
>> > > +
>> > > + /* clear all interrupts */
>> > > + cra_writel(pcie, P2A_INT_STS_ALL, P2A_INT_STATUS);
>> > > + /* enable all interrupts */
>> > > + cra_writel(pcie, P2A_INT_ENA_ALL, P2A_INT_ENABLE);
>> > > +
>> > > + bus = pci_scan_root_bus(&pdev->dev, pcie->root_bus_nr,
>> > > &altera_pcie_ops,
>> > > + pcie, &pcie->resources);
>> > > + if (!bus)
>> > > + return -ENOMEM;
>> > > +
>> > > + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
>> > > + pci_assign_unassigned_bus_resources(bus);
>> >
>> > I think you are missing a call to pcie_bus_configure_settings(),
>> > see drivers/pci/host/pci-host-generic.c
>> Other pci controller drivers like xgene and iproc don't call to this
>> function, but it call in
>> arch/arm/kernel/bios32.c:pci_common_init_dev().
>> Do we really need this?
>
> It is there to provide a way to configure the system MPS, through
> command line parameters, it is always a good idea to have it and
> it should be part of your driver so that you can tune it in case
> the MPS is misconfigured or you want to apply a specific configuration
> for a given system.
>
> Have a look at pcie_bus_config and how it is used in
> pcie_bus_configure_settings(), that would clarify further.
Thanks for explanation. I will add it.
Thanks.
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] mtd: mtk-nor: mtk serial flash controller driver
On Tue, Sep 08, 2015 at 05:49:55PM +0800, Bayi Cheng wrote: > add spi nor flash driver for mediatek controller > > Signed-off-by: Bayi Cheng > --- > drivers/mtd/spi-nor/Kconfig | 7 + > drivers/mtd/spi-nor/Makefile | 1 + > drivers/mtd/spi-nor/mtk_nor.c | 533 > ++ > 3 files changed, 541 insertions(+) > create mode 100644 drivers/mtd/spi-nor/mtk_nor.c > > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 89bf4c1..f433890 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -7,6 +7,13 @@ menuconfig MTD_SPI_NOR > > if MTD_SPI_NOR > > +config MTD_MT81xx_NOR > + tristate "Support SPI flash Controller MTD_MT81xx_NOR" > + help > + This enables access to SPI Nor flash, using MTD_MT81XX_NOR controller. > + This controller does nor support generic SPI BUS, It only supports > + SPI NOR Flash. > + > config MTD_SPI_NOR_USE_4K_SECTORS > bool "Use small 4096 B erase sectors" > default y > diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile > index e5e..2f4fe62 100644 > --- a/drivers/mtd/spi-nor/Makefile > +++ b/drivers/mtd/spi-nor/Makefile > @@ -1,3 +1,4 @@ > +obj-$(CONFIG_MTD_MT81xx_NOR) += mtk_nor.o > obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o > obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o > obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o > diff --git a/drivers/mtd/spi-nor/mtk_nor.c b/drivers/mtd/spi-nor/mtk_nor.c > new file mode 100644 > index 000..e675fb6 > --- /dev/null > +++ b/drivers/mtd/spi-nor/mtk_nor.c > @@ -0,0 +1,533 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Bayi.Cheng > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define MTK_NOR_CMD_REG 0x00 > +#define MTK_NOR_CNT_REG 0x04 > +#define MTK_NOR_RDSR_REG 0x08 > +#define MTK_NOR_RDATA_REG0x0c > +#define MTK_NOR_RADR0_REG0x10 > +#define MTK_NOR_RADR1_REG0x14 > +#define MTK_NOR_RADR2_REG0x18 > +#define MTK_NOR_WDATA_REG0x1c > +#define MTK_NOR_PRGDATA0_REG 0x20 > +#define MTK_NOR_PRGDATA1_REG 0x24 > +#define MTK_NOR_PRGDATA2_REG 0x28 > +#define MTK_NOR_PRGDATA3_REG 0x2c > +#define MTK_NOR_PRGDATA4_REG 0x30 > +#define MTK_NOR_PRGDATA5_REG 0x34 > +#define MTK_NOR_SHREG0_REG 0x38 > +#define MTK_NOR_SHREG1_REG 0x3c > +#define MTK_NOR_SHREG2_REG 0x40 > +#define MTK_NOR_SHREG3_REG 0x44 > +#define MTK_NOR_SHREG4_REG 0x48 > +#define MTK_NOR_SHREG5_REG 0x4c > +#define MTK_NOR_SHREG6_REG 0x50 > +#define MTK_NOR_SHREG7_REG 0x54 > +#define MTK_NOR_SHREG8_REG 0x58 > +#define MTK_NOR_SHREG9_REG 0x5c > +#define MTK_NOR_FLHCFG_REG 0x84 > +#define MTK_NOR_PP_DATA_REG 0x98 > +#define MTK_NOR_PREBUF_STUS_REG 0x9c > +#define MTK_NOR_INTRSTUS_REG 0xa8 > +#define MTK_NOR_INTREN_REG 0xac > +#define MTK_NOR_TIME_REG 0x94 > +#define MTK_NOR_CHKSUM_CTL_REG 0xb8 > +#define MTK_NOR_CHKSUM_REG 0xbc > +#define MTK_NOR_CMD2_REG 0xc0 > +#define MTK_NOR_WRPROT_REG 0xc4 > +#define MTK_NOR_RADR3_REG0xc8 > +#define MTK_NOR_DUAL_REG 0xcc > +#define MTK_NOR_DELSEL0_REG 0xa0 > +#define MTK_NOR_DELSEL1_REG 0xa4 > +#define MTK_NOR_DELSEL2_REG 0xd0 > +#define MTK_NOR_DELSEL3_REG 0xd4 > +#define MTK_NOR_DELSEL4_REG 0xd8 > +#define MTK_NOR_CFG1_REG 0x60 > +#define MTK_NOR_CFG2_REG 0x64 > +#define MTK_NOR_CFG3_REG 0x68 > +#define MTK_NOR_STATUS0_REG 0x70 > +#define MTK_NOR_STATUS1_REG 0x74 > +#define MTK_NOR_STATUS2_REG 0x78 > +#define MTK_NOR_STATUS3_REG 0x7c > +/* commands for mtk nor controller */ > +#define MTK_NOR_READ_CMD 0x0 > +#define MTK_NOR_RDSR_CMD 0x2 > +#define MTK_NOR_PRG_CMD 0x4 > +#define MTK_NOR_WR_CMD 0x10 > +#define MTK_NOR_WRSR_CMD 0x20 > +#define MTK_NOR_PIO_READ_CMD 0x81 > +#define MTK_NOR_WR_BUF_ENABLE
Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs
On 02-09-15, 13:58, Rob Herring wrote:
> What do you expect here? It is your job to close it. Ultimately, this
> will be your problem to deal with. If you have 10 different vendors
> doing selection of OPPs in 10 different ways you will not be able to
> change that easily later. Maybe if you can't come up with something
> common, then this should just not go into DT. You can always look at
> how to do this in a common way and move from the kernel to DT later.
After getting ranted a bit, here is an real attempt to solve the
problem in a generic way. I hope this can take care of the complexity
of both Qualcomm and ST Microelectronics SoCs.
@Lee and Stephen: Lemme know if this still wouldn't work :(
-8<-
From: Viresh Kumar
Date: Wed, 9 Sep 2015 11:47:37 +0530
Subject: [PATCH] PM / OPP: Add "opp-cuts" and "opp-supply-version" bindings
For many platforms it is unknown until runtime, about which OPPs should
be used or if used what should be voltage range for the supplies for a
particular frequency. And this mostly depends on the version of the
device or hardware, for which the OPPs are getting used.
This patch adds two new OPP bindings to get this solved.
1. "opp-cuts": The purpose of this binding is to allow the platform to
identify the valid OPPs based on the different levels of versions
with which the hardware is identified.
2. "opp-supply-name": The purpose of this binding is to allow the
platform to select the voltage range of the power supplies, for a
valid OPP.
Both of these can be used together, as well as independently.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 90 +++
1 file changed, 90 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index c56a6b1a44ef..def75f7a3614 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -98,6 +98,13 @@ This describes the OPPs belonging to a device. This node can
have following
information. But for multiple power-supplies, this must be set to pass
triplet style values.
+- opp-supply-version: One or more strings describing version of the supplies on
+ the platform. This is useful for the cases, where the platform wants to
select
+ the voltage range for supplies at runtime, based on the specific version of
+ the hardware. There should be one entry in opp-microvolt array, for each
+ string present here. OPPs for the device must be configured, only for a
single
+ version of the supplies.
+
- status: Marks the OPP table enabled/disabled.
@@ -144,6 +151,16 @@ properties.
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-cuts: Variable length field that contains versions/cuts/substrate of the
+ hardware for which the OPP is supported. Should contain entry per level of
+ version type. For example: a platform with three levels of versions (cuts
+ substrate pcode), this field should be like , where X corresponds to
+ different cuts, Y corresponds to different substrates and Z corresponds to
+ different pcodes the OPP supports. Each bit of the value corresponds to a
+ particular version of the level, and so we can have maximum 32 different
+ values of any level. A value of 0x means that all the versions of the
+ level are supported.
+
- status: Marks the node enabled/disabled.
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -491,3 +508,76 @@ Example 5: Multiple OPP tables
};
};
};
+
+Example 6: OPP selection based on hardware version
+(example: three levels of versions: cuts, substrate and pcode)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ cpu-supply = <&cpu_supply>
+ operating-points-v2 = <&cpu0_opp_table_slow>;
+ };
+ };
+
+ opp_table {
+ compatible = "operating-points-v2";
+ status = "okay";
+ opp-shared;
+
+ opp00 {
+ /*
+* Supports all substrate and pcode versions for 0xf
+* cuts, i.e. only first four cuts.
+*/
+ opp-cuts = <0xf 0x 0x>
+ opp-hz = /bits/ 64 <6>;
+ ...
+ };
+
+ opp01 {
+ /*
+* Supports all substrate and pcode versions for 0x20
+* cuts, i.e. only the 6th cut.
+*/
+ opp-cuts = <0x20 0x 0x>
+ opp-hz = /bits/ 64 <8>;
+ ...
+
[RFC v3 4/4] iio: chemical: add SGX VZ89x VOC sensor support
Add support for VZ89X sensors VOC and CO2 reporting channels in percentage which can be converted to part per million. Signed-off-by: Matt Ranostay --- .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ .../devicetree/bindings/i2c/trivial-devices.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/chemical/Makefile | 6 + drivers/iio/chemical/vz89x.c | 245 + 6 files changed, 284 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x create mode 100644 drivers/iio/chemical/Makefile create mode 100644 drivers/iio/chemical/vz89x.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x new file mode 100644 index 000..74f2a35 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x @@ -0,0 +1,30 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_CO2_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled, and no offset applied CO2 gas percentage + value. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the raw calibration VOC value from the sensor. + This value has little application outside of calibration. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_tVOC_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled, and no offset applied total VOC gas + percentage value. + +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the unscaled sensor resistance value. diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index d77d412..a550216 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sgx,vz89x SGX Sensortech VZ89X Sensors sii,s35390a2-wire CMOS real-time clock skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st-micro,24c256i2c serial eeprom (24cxx) diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 4011eff..9664e9c 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER source "drivers/iio/accel/Kconfig" source "drivers/iio/adc/Kconfig" source "drivers/iio/amplifiers/Kconfig" +source "drivers/iio/chemical/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/dac/Kconfig" source "drivers/iio/frequency/Kconfig" diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 698afc2..2288684 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o obj-y += accel/ obj-y += adc/ obj-y += amplifiers/ +obj-y += chemical/ obj-y += common/ obj-y += dac/ obj-y += gyro/ diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile new file mode 100644 index 000..7292f2d --- /dev/null +++ b/drivers/iio/chemical/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for IIO chemical sensors +# + +# When adding new entries keep the list in alphabetical order +obj-$(CONFIG_VZ89X)+= vz89x.o diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c new file mode 100644 index 000..847f853 --- /dev/null +++ b/drivers/iio/chemical/vz89x.c @@ -0,0 +1,245 @@ +/* + * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors + * + * Copyright (C) 2015 Matt Ranostay + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include + +#include +#include + +#define VZ89X_REG_MEASUREMENT 0
[RFC v3 3/4] devicetree: add SGX Sensortech vendor id
Signed-off-by: Matt Ranostay --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac5f0c3..281e8f0 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -191,6 +191,7 @@ sbs Smart Battery System schindler Schindler seagateSeagate Technology PLC semtechSemtech Corporation +sgxSGX Sensortech sharp Sharp Corporation silSilicon Image silabs Silicon Laboratories -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 0/4] iio: new chemical sensor framework and channel types
Changes from RFC v2: * Proper usage of IIO_CHAN_INFO_OFFSET values for VOC and CO2 channels * Return CO2 offset that combines the 400 ppm offset and -13 value correction Matt Ranostay (4): iio: chemical: Add IIO_CONCENTRATION channel type iio: resistance: add IIO_RESISTANCE channel type devicetree: add SGX Sensortech vendor id iio: chemical: add SGX VZ89x VOC sensor support Documentation/ABI/testing/sysfs-bus-iio| 14 ++ .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 30 +++ .../devicetree/bindings/i2c/trivial-devices.txt| 1 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/chemical/Makefile | 6 + drivers/iio/chemical/vz89x.c | 245 + drivers/iio/industrialio-core.c| 2 + include/uapi/linux/iio/types.h | 2 + 10 files changed, 303 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x create mode 100644 drivers/iio/chemical/Makefile create mode 100644 drivers/iio/chemical/vz89x.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 2/4] iio: resistance: add IIO_RESISTANCE channel type
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 7 +++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 48080b7..0f683ed 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1466,3 +1466,10 @@ KernelVersion: 4.3
Contact: linux-...@vger.kernel.org
Description:
Raw (unscaled no offset etc.) precentage reading of a substance.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) resistance reading in ohms.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 58a60a1..d61a363 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -76,6 +76,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
[IIO_CONCENTRATION] = "concentration",
+ [IIO_RESISTANCE] = "resistance",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index c5a0e3f..d58319c 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -36,6 +36,7 @@ enum iio_chan_type {
IIO_DISTANCE,
IIO_VELOCITY,
IIO_CONCENTRATION,
+ IIO_RESISTANCE,
};
enum iio_modifier {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 1/4] iio: chemical: Add IIO_CONCENTRATION channel type
There are air quality sensors that report data back in parts per million
of VOC (Volatile Organic Compounds) which are usually indexed from CO2
or another common pollutant.
This patchset adds an IIO_CONCENTRATION type that returns a percentage
of substance because no other channels types fit this use case.
Signed-off-by: Matt Ranostay
---
Documentation/ABI/testing/sysfs-bus-iio | 7 +++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio
b/Documentation/ABI/testing/sysfs-bus-iio
index 42d360f..48080b7 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1459,3 +1459,10 @@ Description:
measurements and return the average value as output data. Each
value resulted from [_name]_oversampling_ratio
measurements
is considered as one sample for
[_name]_sampling_frequency.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
+What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
+KernelVersion: 4.3
+Contact: linux-...@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) precentage reading of a substance.
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index b3fcc2c..58a60a1 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -75,6 +75,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_ENERGY] = "energy",
[IIO_DISTANCE] = "distance",
[IIO_VELOCITY] = "velocity",
+ [IIO_CONCENTRATION] = "concentration",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index 2f8b117..c5a0e3f 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -35,6 +35,7 @@ enum iio_chan_type {
IIO_ENERGY,
IIO_DISTANCE,
IIO_VELOCITY,
+ IIO_CONCENTRATION,
};
enum iio_modifier {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl
Hi, finally i'm able to continue to work on it.
Am 13.05.2015 um 13:00 schrieb Linus Walleij:
> On Tue, May 12, 2015 at 6:25 PM, Oleksij Rempel
> wrote:
>> Am 05.05.2015 um 17:12 schrieb Linus Walleij:
>
>>> Just reference the statically defined array by a pointer instead,
>>> this just takes up a lot o memory for no reason.
>>
>> This two arrays have different types this is why i convert it.
>> priv->pin_desc[i].name - here i copy pointer any ways, and
>> priv->pin_desc[i].number can be smaller then pointer.
>
> I probably do not understand what you're trying to do, sorry :(
>
> Why is it necessary for the driver to copy one description of
> the pin into another?
If i understand it correctly, pinctrl_pin_desc is essential part of
pinmux framework. Theoretically i should define just statical array of
this struct, but by this number of pins and functions it hard to keep it
readable and error free. So i decided to create asm9260_mux_table which
contains every thing i need. The side effect is higher memory usage
since i need to create pinctrl_pin_desc on fly.
May be i miss some thing?
>>> Mory copying. I don't see why this is necessary at all.
>>
>> I hadn't seen the point to define groups statically, especially because
>> they are used only to make curious user happy. So, memory will be used
>> only if you request the list over sysfs. Or miss some thing?
>
> pinctrl does not even use sysfs.
please read debugfs.
> The group names are usually there for matching with a function,
> it is part of the core functionality. The group name + function name
> matching is even more obvious in the dt case.
>
> They also make things easier to read in debugfs yes, but
> the core of the crux is to make it easy to config function+groups
> states with e.g. DT or board files.
>
+static struct pinmux_ops asm9260_pinmux_ops = {
+ .get_functions_count= asm9260_pinctrl_get_funcs_count,
+ .get_function_name = asm9260_pinctrl_get_func_name,
+ .get_function_groups= asm9260_pinctrl_get_func_groups,
+ .set_mux= asm9260_pinctrl_set_mux,
+ /* TODO: should we care about gpios here? gpio_request_enable? */
>>>
>>> I think you should, if you also have a matching GPIO driver.
>>
>> I fear it would cause unpredictable bugs. GPIO mode is just one of mux
>> modes. If some one will request gpio some busy or dangerous line it
>> would do more harm then use. So, i assume limiting this only to device
>> tree would be better.
>
> Device tree or not doesn't matter, .gpio_request_enable() is used
> as a shortcut to mux in GPIO pins.
>
> If the simultaneous use of a pin for a device and GPIO bothers
> you there is nowadays (linux-next or my devel branch) a .strict
> option in pinmux_ops that you can set to disallow simultaneous
> use by devices and GPIO of the same pin.
>
> Yours,
> Linus Walleij
>
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/3] doc: dt: add documentation for Mediatek spi-nor controller
On Tue, Sep 08, 2015 at 05:49:54PM +0800, Bayi Cheng wrote: > Add device tree binding documentation for serial flash with > Mediatek serial flash controller > > Signed-off-by: Bayi Cheng > --- > Documentation/devicetree/bindings/mtd/mtk_nor.txt | 25 > +++ > 1 file changed, 25 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/mtk_nor.txt > > diff --git a/Documentation/devicetree/bindings/mtd/mtk_nor.txt > b/Documentation/devicetree/bindings/mtd/mtk_nor.txt > new file mode 100644 > index 000..0eca0cd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/mtk_nor.txt > @@ -0,0 +1,25 @@ > +* MTD SPI nor driver for MTK MT81xx (and similar) serial flash controller > + > +MTK MT81xx serial flash controller is designed for serial Flash device. > +It supports one Flash device with signal mode, dual mode and quad mode. > + > +Required properties: > +- compatible: should be "mediatek,mt8173-nor"; > +- reg: physical base address and length of the controller's register > +- clocks: spi nor source clock > +- clock-names: "spi_clk", "axi_clk", "mux_clk", "sf_clk" Drop the _clk suffix. It's the clock-names property which already makes it clear that these are clock names. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
On 09/08/2015 08:09 AM, Linus Walleij wrote:
> On Fri, Aug 28, 2015 at 12:24 PM, Masahiro Yamada
> wrote:
>> 2015-08-26 22:39 GMT+09:00 Linus Walleij :
>
>>> cache-unified and cache-level are *not* optional and should be required.
>>
>> "cache-unified" is mentioned in "3.7.3 Internal (L1) Cache Properties"
>> (Table 3-8),
>> but it is not in "3.8 Multi-level and Shared Caches" (Table 3-9)
>>
>> Are the rules in Table 3-8 also applied for L2?
>
> Your guess is as good as mine unless someone involved in
> actually writing that spec says something :/
Maybe you'd have to be crazy to have Harvard cache for 2nd+ level. I've
got no clue. Doesn't hurt to have it.
>
>>> (I'm just assuming this cache is unified, anything else would be baffling.)
>>
>> In fact, unified/harvard is configurable thru a register of this cache
>> controller.
>
> Jesus Christ.
Hardware designers either hate software folks or ensure our job security.
>
>> It is usually used as a unified cached, though.
>
> I would, too.
>
>> So,I am planning to use the same compatible for L2 and L3, like this:
>>
>>
>>l2-cache@500c {
>>compatible = "socionext,uniphier-cache";
>>reg = <0x500c 0x2000>, <0x503c0100 0x8>,
>> <0x506c 0x400>;
>>cache-unified;
>>cache-level = <2>;
>>next-level-cache = <&L2>;
Next level of the L2 is the L2?
>>cache-size = <0x20>;
>>cache-sets = <256>;
>>cache-line-size = <128>;
>> };
>>
>>/* Not all of UniPhier SoCs have L3 cache */
>>l3-cache@500c8000 {
>>compatible = "socionext,uniphier-cache";
>>reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
>> <0x506c8000 0x400>;
>>cache-unified;
>>cache-level = <3>;
>>cache-size = <0x40>;
>>cache-sets = <256>;
>>cache-line-size = <256>;
>>};
>
> This LooksGoodToMe.
>
>> The Table 3-9 in ePAPR v1.1 says
>> the compatible should be "cache", but I do not think it makes sense here.
>
> Agree.
It could be useful for finding all cache nodes, but we've generally
failed to use it, so at this point it doesn't matter.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v5 4/5] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
On 08/26/2015 07:30 AM, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the driver of the Atmel QSPI
> controller embedded inside sama5d2x SoCs.
>
> Signed-off-by: Cyrille Pitchen
> Acked-by: Nicolas Ferre
> Acked-by: Marek Vasut
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/mtd/atmel-quadspi.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> new file mode 100644
> index ..0b8d545bb198
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
> @@ -0,0 +1,29 @@
> +* Atmel Quad Serial Peripheral Interface (QSPI)
> +
> +Required properties:
> +- compatible: should be "atmel,sama5d2-qspi"
> +- reg:the first contains the register location and length,
> + the second contains the memory mapping address and length
> +- interrupts: should contain the interrupt for the device
> +- clocks: the phandle of the clock needed by the QSPI controller
> +- #address-cells: should be <1>
> +- #size-cells:should be <0>
> +
> +Example:
> +
> +spi@f002 {
> + compatible = "atmel,sama5d2-qspi";
> + reg = <0xf002 0x100>,
> + <0xd000 0x800>;
> + interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
> + clocks = <&spi0_clk>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi0_default>;
> + status = "okay";
> +
> + m25p80@0 {
> + ...
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] devicetree: Add documentation for UPISEMI us5182d ALS and Proximity sensor
On 09/07/2015 08:59 AM, Adriana Reus wrote: > Thanks for your feedback, some comments inline. > > On 31.08.2015 18:38, Rob Herring wrote: >> On Thu, Aug 27, 2015 at 3:23 PM, Jonathan Cameron >> wrote: >>> On 20/08/15 11:12, Adriana Reus wrote: Added entries in i2c/vendor-prefixes for the us5182d als and proximity sensor. Also added a documentation file for this sensor's properties. Signed-off-by: Adriana Reus >>> This isn't that trivial so I'd like some device tree maintainer >>> input if possible. >> >> It seems fairly reasonable to me. Would other ALS or proximity sensors >> need similar properties? > The "glass-coef" is intended to compensate for the material (glass) that > may be covering the sensor if it's integrated in a phone, tablet etc. I > chose 1000 as resolution for this scaling factor (i'll add a more > detailed description). So possibly similar properties could be used for > other als sensors as well. Seems like amstaos,cover-comp-gain would be doing the same thing. But it is defined as an integer, so I'm not sure how that would work. > > The last 3 tuning parameters are specific to this particular sensor. >> >>> For now I've backed out the driver from my tree (given timing we have >>> loads of time to sort this out!) >>> >>> Anyhow, anyone device tree related able to take a look at this. >>> >>> Adriana, btw these should be cc'd to the device tree maintainers in >>> the first place (now added). >>> >>> Jonathan --- .../devicetree/bindings/iio/light/us5182d.txt | 23 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + 2 files changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt new file mode 100644 index 000..7785c56 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt @@ -0,0 +1,23 @@ +* UPISEMI us5182d I2C ALS and Proximity sensor + +Required properties: +- compatible: must be "upisemi,usd5182" +- reg: the I2C address of the device + +Optional properties: >> >> Do you expect certain defaults if not present? Some description of how >> all these values are determined would be useful. > Yes, if not present they will fall back to default values - the values > in the example. > - the glass-coef one is 1000 by default - so no glass compensation by > default (lux = lux * 1000/1000) > - the others were determined experimentally - by fine tuning starting > from the default values in those registers). So the default if the properties are not present is a default register value or a default in the driver? Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom
On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
> This patch documents the DT bindings for the Atmel Flexcom which will be
> introduced by sama5d2x SoCs. These bindings will be used by the actual
> Flexcom driver to be sent in another patch.
>
> Signed-off-by: Cyrille Pitchen
> Acked-by: Boris Brezillon
> Acked-by: Alexandre Belloni
A few comments, but in general looks fine.
> ---
> .../devicetree/bindings/mfd/atmel-flexcom.txt | 67
> ++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> new file mode 100644
> index ..fc3511e41542
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> @@ -0,0 +1,67 @@
> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
> +
> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
> +controller and an USART. Only one function can be used at a time and is
> chosen
> +at boot time according to the device tree.
Doesn't the board design choose (unless pins go to a header)?
> +
> +Required properties:
> +- compatible:Should be "atmel,sama5d2-flexcom"
> +- reg: Should be the offset/length value for Flexcom
> dedicated
> + I/O registers (without USART, TWI or SPI registers).
> +- clocks:Should be the Flexcom peripheral clock from PMC.
> +- #address-cells:Should be <1>
> +- #size-cells: Should be <1>
> +- ranges:Should be one range for the full I/O register region
> + (including USART, TWI and SPI registers).
> +- atmel,flexcom-mode:Should be one of the 3 following macros as
> defined in
> + include/dt-bindings/mfd/atmel-flexcom.h:
> + - ATMEL_FLEXCOM_MODE_USART for USART
> + - ATMEL_FLEXCOM_MODE_SPI for SPI
> + - ATMEL_FLEXCOM_MODE_TWI for I2C
> +
> +Required child:
> +a single child device of type matching the "atmel,flexcom-mode" property.
Okay, but why not allow all children and use "status"?
> +
> +The reg property of this child should be:
> +- <0x200 0x200> for USART
> +- <0x400 0x200> for SPI
> +- <0x600 0x200> for I2C
> +
> +The phandle provided by the clocks property of the child is the same as one
> for
> +the Flexcom parent.
> +
> +Other properties remain unchanged. See documentation of the respective
> device:
> +- ../serial/atmel-usart.txt
> +- ../spi/spi_atmel.txt
> +- ../i2c/i2c-at91.txt
> +
> +Example:
> +
> +flexcom@f8034000 {
> + compatible = "atmel,sama5d2-flexcom";
> + reg = <0xf8034000 0x200>;
> + clocks = <&flx0_clk>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0xf8034000 0x800>;
> + atmel,flexcom-mode = ;
> +
> + spi@400 {
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0x400 0x200>;
> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flx0_default>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&flx0_clk>;
> + clock-names = "spi_clk";
> + atmel,fifo-size = <32>;
> +
> + mtd_dataflash@0 {
> + compatible = "atmel,at25f512b";
> + reg = <0>;
> + spi-max-frequency = <2000>;
> + };
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
On 09/08/2015 01:17 AM, Chunfeng Yun wrote:
> add a DT binding documentation of usb3.0 phy for MT65xx
> SoCs from Mediatek.
>
> Signed-off-by: Chunfeng Yun
One comment, otherwise:
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69
> ++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> new file mode 100644
> index 000..5812d20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -0,0 +1,69 @@
> +mt65xx USB3.0 PHY binding
> +--
> +
> +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> +
> +Required properties (controller (parent) node):
> + - compatible: should be "mediatek,mt8173-u3phy"
> + - reg : offset and length of register for phy, exclude port's
> + register.
> + - clocks: a list of phandle + clock-specifier pairs, one for each
> + entry in clock-names
> + - clock-names : must contain
> + "u3phya_ref": for reference clock of usb3.0 analog phy.
> +
> +Required nodes : a sub-node is required for each port the controller
> + provides. Address range information including the usual
> + 'reg' property is used inside these nodes to describe
> + the controller's topology. These nodes are translated
> + by the driver's .xlate() function.
The last sentence is Linux specific. Please remove.
> +
> +Required properties (port (child) node):
> +- reg: address and length of the register set for the port.
> +- #phy-cells : should be 1 (See second example)
> + cell after port phandle is phy type from:
> + - PHY_TYPE_USB2
> + - PHY_TYPE_USB3
> +
> +Example:
> +
> +u3phy: usb-phy@1129 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x1129 0 0x800>;
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> + clock-names = "u3phya_ref";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "okay";
> +
> + phy_port0: port@11290800 {
> + reg = <0 0x11290800 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + phy_port1: port@11291000 {
> + reg = <0 0x11291000 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +};
> +
> +Specifying phy control of devices
> +-
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type;
> +phy-names for each port are optional.
> +
> +Example:
> +
> +#include
> +
> +usb30: usb@1127 {
> + ...
> + phys = <&phy_port0 PHY_TYPE_USB3>;
> + phy-names = "usb3-0";
> + ...
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 04/22] of: add function to allow probing a device from a OF node
On 09/07/2015 07:23 AM, Tomeu Vizoso wrote:
> Walks the OF tree up and finds the closest ancestor that has a struct
> device associated with it, probing it if isn't bound to a driver yet.
>
> The above should ensure that the dependency represented by the passed OF
> node is available, because probing a device should cause its descendants
> to be probed as well (when they get registered).
>
> Subsystems can use this when looking up resources for drivers, to reduce
> the chances of deferred probes because of the probing order of devices.
>
> Signed-off-by: Tomeu Vizoso
Looks pretty good to me. One comment below.
[...]
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index baf04d7249bd..f089d95ac961 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -269,6 +269,8 @@ static struct amba_device *of_amba_device_create(struct
> device_node *node,
> goto err_free;
> }
>
> + node->device = &dev->dev;
> +
This seems oddly placed. Can you move to patch 3?
> return dev;
>
> err_free:
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index cc7dd687a89d..da8d489e73ad 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -40,6 +40,7 @@ extern ssize_t of_device_get_modalias(struct device *dev,
>
> extern void of_device_uevent(struct device *dev, struct kobj_uevent_env
> *env);
> extern int of_device_uevent_modalias(struct device *dev, struct
> kobj_uevent_env *env);
> +extern void of_device_probe(struct device_node *np);
>
> static inline void of_device_node_put(struct device *dev)
> {
> @@ -84,6 +85,8 @@ static inline int of_device_uevent_modalias(struct device
> *dev,
> return -ENODEV;
> }
>
> +static inline void of_device_probe(struct device_node *np) { }
> +
> static inline void of_device_node_put(struct device *dev) { }
>
> static inline const struct of_device_id *__of_match_device(
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/22] On-demand device probing
On 09/08/2015 02:30 AM, Tomeu Vizoso wrote: > On 7 September 2015 at 22:50, Rob Herring wrote: >> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso >> wrote: >>> Hello, >>> >>> I have a problem with the panel on my Tegra Chromebook taking longer >>> than expected to be ready during boot (Stéphane Marchesin reported what >>> is basically the same issue in [0]), and have looked into ordered >>> probing as a better way of solving this than moving nodes around in the >>> DT or playing with initcall levels and linking order. >>> >>> While reading the thread [1] that Alexander Holler started with his >>> series to make probing order deterministic, it occurred to me that it >>> should be possible to achieve the same by probing devices as they are >>> referenced by other devices. >>> >>> This basically reuses the information that is already implicit in the >>> probe() implementations, saving us from refactoring existing drivers or >>> adding information to DTBs. >>> >>> During review of v1 of this series Linus Walleij suggested that it >>> should be the device driver core to make sure that dependencies are >>> ready before probing a device. I gave this idea a try [2] but Mark Brown >>> pointed out to the logic duplication between the resource acquisition >>> and dependency discovery code paths (though I think it's fairly minor). >>> >>> To address that code duplication I experimented with Arnd's devm_probe >>> [3] concept of having drivers declare their dependencies instead of >>> acquiring them during probe, and while it worked [4], I don't think we >>> end up winning anything when compared to just probing devices on-demand >>> from resource getters. >>> >>> One remaining objection is to the "sprinkling" of calls to >>> of_device_probe() in the resource getters of each subsystem, but I think >>> it's the right thing to do given that the storage of resources is >>> currently subsystem-specific. >>> >>> We could avoid the above by moving resource storage into the core, but I >>> don't think there's a compelling case for that. >>> >>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and >>> OMAP SoCs, and these patches were enough to eliminate all the deferred >>> probes (except one in PandaBoard because omap_dma_system doesn't have a >>> firmware node as of yet). >>> >>> Have submitted a branch [5] with only these patches on top of thursday's >>> linux-next to kernelci.org and I don't see any issues that could be >>> caused by them. For some reason it currently has more passes than the >>> version of -next it's based on! >>> >>> With this series I get the kernel to output to the panel in 0.5s, >>> instead of 2.8s. >>> >>> Regards, >>> >>> Tomeu >>> >>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html >>> >>> [1] https://lkml.org/lkml/2014/5/12/452 >>> >>> [2] https://lkml.org/lkml/2015/6/17/305 >>> >>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 >>> >>> [4] https://lkml.org/lkml/2015/7/21/441a >>> >>> [5] >>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 >>> >>> [6] >>> http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ >>> >>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ >>> >>> Changes in v4: >>> - Added bus.pre_probe callback so the probes of Primecell devices can be >>> deferred if their device IDs cannot be yet read because of the clock >>> driver not having probed when they are registered. Maybe this goes >>> overboard and the matching information should be in the DT if there is >>> one. >> >> Seems overboard to me or at least a separate problem. > > It's a separate problem but this was preventing the series from > working on a few boards. What is the failure? Not booting? Fixing not working would certainly not be overboard. > >> Most clocks have >> to be setup before the driver model simply because timers depend on >> clocks usually. > > Yes, but in this case the apb clocks for the primecell devices are > implemented in a normal platform driver (vexpress_osc_driver), instead > of using CLK_OF_DECLARE. Okay. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.
On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote: > Analogix Semiconductor develops analog and mixed-signal devices for digital > media and communications interconnect applications. > > Signed-off-by: Enric Balletbo i Serra Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ac5f0c3..e914a02 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -22,6 +22,7 @@ ampire Ampire Co., Ltd. > ams AMS AG > amstaos AMS-Taos Inc. > apm Applied Micro Circuits Corporation (APM) > +analogix Analogix Semiconductor, Inc. > aptina Aptina Imaging > arasan Arasan Chip Systems > arm ARM Ltd. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support
On 09/07/2015 06:18 AM, Vaibhav Hiremath wrote: > With support for pxa1928 family of devices , this patch > updates the binding document with compatible property > of "marvell,pxav3-1928-sdhci". > > Signed-off-by: Vaibhav Hiremath > --- > Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt > b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt > index 3d1b449..29edcf5 100644 > --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt > +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt > @@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 > drivers. > > Required properties: > - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or > - "marvell,armada-380-sdhci". > + "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci". v3 is implied by pxa1928. So I'd just do "marvell,pxa1928-sdhci" to better match the chip name. Rob > - reg: >* for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for > the SDHCI registers. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.
On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> You can add support to your board with current binding.
>
> Example:
>
> anx7814: anx7814@38 {
> compatible = "analogix,anx7814";
> reg = <0x38>;
> pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> };
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> .../devicetree/bindings/video/anx7814.txt | 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/anx7814.txt
>
> diff --git a/Documentation/devicetree/bindings/video/anx7814.txt
> b/Documentation/devicetree/bindings/video/anx7814.txt
> new file mode 100644
> index 000..a8cc746
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/anx7814.txt
> @@ -0,0 +1,22 @@
> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> +---
> +
> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> +designed for portable devices.
> +
> +Required properties:
> +
> + - compatible: "analogix,anx7814"
> + - reg : I2C address of the device
> + - pd-gpios : Which GPIO to use for power down
> + - reset-gpios : Which GPIO to use for reset
> +
> +Example:
> +
> + anx7814: anx7814@38 {
> + compatible = "analogix,anx7814";
> + reg = <0x38>;
> + pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
No ports needed for describing data connections?
Rob
> + };
> +
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm64: dts: mt8173: Add nor flash node
On 09/08/2015 10:18 AM, Ezequiel Garcia wrote:
> On 8 September 2015 at 08:53, Jagan Teki wrote:
>> On 8 September 2015 at 15:19, Bayi Cheng wrote:
>>> Add Mediatek nor flash node
>>>
>>> Signed-off-by: Bayi Cheng
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> index d18ee42..a14f005 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>> @@ -365,6 +365,16 @@
>>> status = "disabled";
>>> };
>>>
>>> + nor_flash: nor@1100d000 {
>>
>> Based on the comments from 1/3 - this notation needs to be change something
>> like
>> qspi0: quadspi@1100d000
>>
>
> Actually, to follow ePAPR recomendations it should be named as flash@1100d000.
> (See ePAPR, 2.2.2 Generic Names Recommendation).
The flash device node should, but this is the controller which should be
"spi" IMO even if this is not a general purpose controller.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller
On 09/08/2015 01:18 AM, Chunfeng Yun wrote:
> add a DT binding documentation of xHCI host controller for the
> MT8173 SoC from Mediatek.
>
> Signed-off-by: Chunfeng Yun
> ---
> .../devicetree/bindings/usb/mt8173-xhci.txt| 52
> ++
> 1 file changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> new file mode 100644
> index 000..d851bf1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> @@ -0,0 +1,52 @@
> +MT8173 xHCI
> +
> +The device node for Mediatek SOC USB3.0 host controller
> +
> +Required properties:
> + - compatible : should contain "mediatek,mt8173-xhci"
> + - reg : specifies physical base address and size of the registers,
> + the first one for MAC, the second for IPPC
> + - interrupts : interrupt used by the controller
> + - power-domains : a phandle to USB power domain node to control USB's
> + mtcmos
> + - vusb33-supply : regulator of USB avdd3.3v
> +
> + - clocks : a list of phandle + clock-specifier pairs, one for each
> + entry in clock-names
> + - clock-names : must contain
> + "sys_ck": for clock of xHCI MAC
> + "wakeup_deb_p0": for USB wakeup debounce clock of port0
> + "wakeup_deb_p0": for USB wakeup debounce clock of port1
> +
> + - phys : a list of phandle + phy specifier pairs
> + - usb3-lpm-capable : supports USB3.0 LPM
> + - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
> + control register
Wake-up should probably be done in some generic way. That said, I don't
have a specific suggestion other than make it optional.
> + - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
> + mode; Others means don't enable wakeup source of USB
This should be optional rather than any other value meaning disabled.
> +
> +Optional properties:
> + - vbus-supply : reference to the VBUS regulator;
> +
> +Example:
> +usb30: usb@1127 {
> + compatible = "mediatek,mt8173-xhci";
> + reg = <0 0x1127 0 0x1000>,
> + <0 0x11280700 0 0x0100>;
> + interrupts = ;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> + clocks = <&topckgen CLK_TOP_USB30_SEL>,
> + <&pericfg CLK_PERI_USB0>,
> + <&pericfg CLK_PERI_USB1>;
> + clock-names = "sys_ck",
> + "wakeup_deb_p0",
> + "wakeup_deb_p1";
> + phys = <&phy_port0 PHY_TYPE_USB3>,
> +<&phy_port1 PHY_TYPE_USB2>;
> + vusb33-supply = <&mt6397_vusb_reg>;
> + vbus-supply = <&usb_p1_vbus>;
> + usb3-lpm-capable;
> + mediatek,syscon-wakeup = <&pericfg>;
> + mediatek,wakeup-src = <1>;
> + status = "okay";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v9 1/3] mfd: atmel-flexcom: create include file with macros used by DT bindings
On 09/01/2015 09:46 AM, Cyrille Pitchen wrote: > This patch defines some macros to be used as value for the > "atmel,flexcom-mode" DT property. This value is then written into > the Operating Mode (OPMODE) bit field of the Flexcom Mode Register. > > Signed-off-by: Cyrille Pitchen Acked-by: Rob Herring In the future, you can combine headers with the binding doc as they are part of the binding. Rob > --- > include/dt-bindings/mfd/atmel-flexcom.h | 16 > 1 file changed, 16 insertions(+) > create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h > > diff --git a/include/dt-bindings/mfd/atmel-flexcom.h > b/include/dt-bindings/mfd/atmel-flexcom.h > new file mode 100644 > index ..6728f2851b4d > --- /dev/null > +++ b/include/dt-bindings/mfd/atmel-flexcom.h > @@ -0,0 +1,16 @@ > +/* > + * This header provides macros for Atmel Flexcom DT bindings. > + * > + * Copyright (C) 2015 Cyrille Pitchen > + * > + * GPLv2 only > + */ > + > +#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__ > +#define __DT_BINDINGS_ATMEL_FLEXCOM_H__ > + > +#define ATMEL_FLEXCOM_MODE_USART 1 > +#define ATMEL_FLEXCOM_MODE_SPI 2 > +#define ATMEL_FLEXCOM_MODE_TWI 3 > + > +#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */ > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] fbdev: ssd1307fb: add ssd1309 support
On 09/08/2015 02:19 PM, Olliver Schinagl wrote:
> The ssd1307fb driver supports a lot of chips from the ssd130xfb series.
> This patch adds the ssd1309 chip, a 128x64 OLED driver chip. It is very
> similar to the other chips and only has some definitions added to
> support it.
>
> Signed-off-by: Olliver Schinagl
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/video/ssd1307fb.txt | 3 ++-
> drivers/video/fbdev/ssd1307fb.c | 11 +++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> index d1be78d..eb31ed4 100644
> --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> @@ -2,7 +2,8 @@
>
> Required properties:
>- compatible: Should be "solomon,fb-". The only supported bus
> for
> -now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
> +now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and
> +ssd1309.
>- reg: Should contain address of the controller on the I2C bus. Most likely
> 0x3c or 0x3d
>- pwm: Should contain the pwm to use according to the OF device tree PWM
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 339615c..8fc7960 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -495,6 +495,12 @@ static struct ssd1307fb_deviceinfo
> ssd1307fb_ssd1307_deviceinfo = {
> .need_pwm = 1,
> };
>
> +static struct ssd1307fb_deviceinfo ssd1307fb_ssd1309_deviceinfo = {
> + .default_vcomh = 0x34,
> + .default_dclk_div = 1,
> + .default_dclk_frq = 10,
> +};
> +
> static const struct of_device_id ssd1307fb_of_match[] = {
> {
> .compatible = "solomon,ssd1305fb-i2c",
> @@ -508,6 +514,10 @@ static const struct of_device_id ssd1307fb_of_match[] = {
> .compatible = "solomon,ssd1307fb-i2c",
> .data = (void *)&ssd1307fb_ssd1307_deviceinfo,
> },
> + {
> + .compatible = "solomon,ssd1309fb-i2c",
> + .data = (void *)&ssd1307fb_ssd1309_deviceinfo,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> @@ -708,6 +718,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
> { "ssd1305fb", 0 },
> { "ssd1306fb", 0 },
> { "ssd1307fb", 0 },
> + { "ssd1309fb", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] watchdog: bcm7038: add device tree binding documentation
On 09/08/2015 12:45 PM, Justin Chen wrote:
> Add device tree binding documentation for the watchdog hardware block
> on bcm7038 and newer SoCs.
>
> Signed-off-by: Justin Chen
> Acked-by: Guenter Roeck
Some minor comments, otherwise:
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> new file mode 100644
> index 000..39e5cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> @@ -0,0 +1,19 @@
> +BCM7038 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm7038-wdt"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Optional properties:
> +
> +- clocks: The clock running the watchdog. If no clock is found the
> + driver will default to 2700 HZ.
s/HZ/Hz/
> +
> +Example:
> +
> +watchdog {
This should have a unit address (watchdog@f040a7e8).
> + compatible = "brcm,bcm7038-wdt";
> + clocks = <&upg_fixed>;
> + reg = <0xf040a7e8 0x16>;
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices
On 09.09.2015 11:48, Andreas Dannenberg wrote:
> On Wed, Sep 09, 2015 at 09:27:06AM +0900, Krzysztof Kozlowski wrote:
>> On 09.09.2015 09:12, Andreas Dannenberg wrote:
>>> Extend the bq2425x charger's device tree documentation to cover the
>>> bq24250 and bq24257 devices as well as recent feature additions.
>>>
>>> Signed-off-by: Andreas Dannenberg
>>
>> Hi,
>>
>> Thanks for updates. Everything pointed previous looks good. After
>> looking at Ramakrishna Pallala's (Cc-ed) patch ("power: bq24261_charger:
>> Add support for TI BQ24261 charger") I have only one comment below.
>
> Thanks for all your efforts and time checking those patches!
>
>>
>>> ---
>>> .../devicetree/bindings/power/bq24257.txt | 21 ---
>>> .../devicetree/bindings/power/bq2425x.txt | 70
>>> ++
>>> 2 files changed, 70 insertions(+), 21 deletions(-)
>>> delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt
>>> create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/bq24257.txt
>>> b/Documentation/devicetree/bindings/power/bq24257.txt
>>> deleted file mode 100644
>>> index 5c9d394..000
>>> --- a/Documentation/devicetree/bindings/power/bq24257.txt
>>> +++ /dev/null
>>> @@ -1,21 +0,0 @@
>>> -Binding for TI bq24257 Li-Ion Charger
>>> -
>>> -Required properties:
>>> -- compatible: Should contain one of the following:
>>> - * "ti,bq24257"
>>> -- reg:integer, i2c address of the device.
>>> -- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
>>> -- ti,charge-current: integer, maximum charging current in uA.
>>> -- ti,termination-current: integer, charge will be terminated when current
>>> in
>>> - constant-voltage phase drops below this value (in
>>> uA).
>>> -
>>> -Example:
>>> -
>>> -bq24257 {
>>> - compatible = "ti,bq24257";
>>> - reg = <0x6a>;
>>> -
>>> - ti,battery-regulation-voltage = <420>;
>>> - ti,charge-current = <100>;
>>> - ti,termination-current = <5>;
>>> -};
>>> diff --git a/Documentation/devicetree/bindings/power/bq2425x.txt
>>> b/Documentation/devicetree/bindings/power/bq2425x.txt
>>> new file mode 100644
>>> index 000..3e171c3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/bq2425x.txt
>>> @@ -0,0 +1,70 @@
>>> +Binding for TI bq2425x Li-Ion Charger
>>> +
>>> +Required properties:
>>> +- compatible: Should contain one of the following:
>>> + * "ti,bq24250"
>>> + * "ti,bq24251"
>>> + * "ti,bq24257"
>>> +- reg: integer, i2c address of the device.
>>> +- stat-gpios: GPIO used for the devices STAT_IN pin. Alternatively the pin
>>> can
>>> +also be defined through the standard interrupt definition properties
>>> (see
>>> +optional properties section below). Only use one method.
>>> +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
>>> +- ti,charge-current: integer, maximum charging current in uA.
>>> +- ti,termination-current: integer, charge will be terminated when current
>>> in
>>> +constant-voltage phase drops below this value (in uA).
>>> +
>>> +Optional properties:
>>> +- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good)
>>> pin.
>>> +This pin is not available on all devices however it should be used if
>>> +possible as this is the recommended way to obtain the charger's input
>>> PG
>>> +state. If this pin is not specified a software-based approach for PG
>>> +detection is used.
>>> +- ti,current-limit: The maximum current to be drawn from the charger's
>>> input
>>> +(in uA). If this property is not specified a USB D+/D- signal based
>>> charger
>>> +type detection is used (if available) and the input limit current is
>>> set
>>> +accordingly. If the D+/D- based detection is not available on a given
>>> device
>>> +a default of 500,000 is used (=500mA).
>>
>> I understand this is different property than "ti,charge-current:
>> integer, default charging current (in mA)" from bq24261_charger patch?
>
> Correct this is what "ti,current-limit" is for. And I borrowed that
> definition from bq2415x_charger.c where it's used in the same context.
> The reason for this property to exist is for systems where the external
> power supply does more than just charging the battery, such as supplying
> the system while it's charging or after it has finished charging. All
> this only makes sense of course if the "ti,current-limit" is larger than
> "ti,charge-current".
>
> And if you see a few lines above the bq24257 driver also has a
> "ti,charge-current" property. And yes this is what actually controls how
> much current is delivered to the battery.
Right, I missed that one. Everything is clear now.
So we have different bindings. Existing ones:
bq2415x.txt - ti,charge-current - maximum charging current in mA
bq24257.txt - ti,charge-current - maximum charging current in uA
bq2
Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger
On 09.09.2015 11:26, Andreas Dannenberg wrote: > On Mon, Sep 07, 2015 at 12:57:56PM +0900, Krzysztof Kozlowski wrote: >> 2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala >> : >>> >>> Add new charger driver support for BQ24261 charger IC. >>> >>> BQ24261 charger driver relies on extcon notifications to get the >>> charger cable type and based on that it will set the charging parameters. >>> >>> Signed-off-by: Ramakrishna Pallala >>> Signed-off-by: Jennt TC >>> --- >>> .../devicetree/bindings/power/bq24261.txt | 37 + >>> drivers/power/Kconfig |6 + >>> drivers/power/Makefile |1 + >>> drivers/power/bq24261_charger.c| 1208 >>> >>> include/linux/power/bq24261_charger.h | 27 + >>> 5 files changed, 1279 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt >>> create mode 100644 drivers/power/bq24261_charger.c >>> create mode 100644 include/linux/power/bq24261_charger.h >>> >>> diff --git a/Documentation/devicetree/bindings/power/bq24261.txt >>> b/Documentation/devicetree/bindings/power/bq24261.txt >>> new file mode 100644 >>> index 000..25fc5c4 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/power/bq24261.txt >>> @@ -0,0 +1,37 @@ >>> +Binding for TI bq24261 Li-Ion Charger >> >> Please split the bindings into separate patch (the first patch in patchset). >> >>> + >>> +Required properties: >>> +- compatible: Should contain one of the following: >>> +* "ti,bq24261" >>> +- reg: integer, i2c address of the device. >>> +- ti,charge-current: integer, default charging current (in mA); >>> +- ti,charge-voltage: integer, default charging voltage (in mV); >>> +- ti,termination-current: integer, charge will be terminated when current >>> in >>> +constant-voltage phase drops below this value (in mA); >>> +- ti,max-charge-current: integer, maximum charging current (in mA); >>> +- ti,max-charge-voltage: integer, maximum charging voltage (in mV); >>> +- ti,min-charge-temperature: integer, minimum charging temperature (in >>> DegC); >>> +- ti,max-charge-temperature: integer, maximum charging temperature (in >>> DegC). >> >> Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover >> additional devices" >> http://www.spinics.net/lists/devicetree/msg92134.html >> >> could you and Andreas figure out common bindings? Look at this: >> >> +- ti,charge-current: integer, maximum charging current in uA. >> +- ti,charge-current: integer, default charging current (in mA); >> >> Different meaning and different units. This is madness! :) >> >> In the same time you are adding TI-common bindings (not device >> specific, there is no prefix) so I would expect exactly the same >> bindings if it is possible. > > Krzysztof, good observation! In bq2425x_charger.c (formerly known as > bq24257_charger.c :) that I worked on the unit used was uA. At that time > I did a quick check and there didn't seem to be a clear standard whether > to use the "micro" or "milli" units - different drivers use different > units. However there seems to be a tendency for the TI drivers to prefer > "milli" (bq2415x_charger.c, bq24735-charger.c) > > Personally I think "milli" units are more appropriate for chargers since > they provide sufficient granularity and the numbers don't become too big > (try typing a voltage in the Volt-range in uV, it's very easy to get the > number of 0s wrong). However since the driver was already there I left > that aspect alone to preserve compatibility. I am fine with both units but milli indeed seems easier to judge by fast looking and less error-prone. Whatever you choose - choose the same one. :) >>> + >>> +Optional properties: >>> +- ti,thermal-sensing: boolean, if present thermal regulation will be >>> enabled; >> >> What is the requirement for thermal-sensing? Can it be enabled always? >> If yes, then this is not really a hardware property. >> >>> +- ti,enable-user-write: boolean, if present driver will allow the user >>> space >>> +to control the charging current and voltage through sysfs; >> >> This is not DT property. It does not describe hardware. > > I take responsibility for this one :) In an earlier thread we were > discussing that it will be better to prevent sysfs write access to > "dangerous" charger parameters (charge voltage, current, ...) but I > argued that such access might still be desirable during development and > debug, and that a DT property could be used to allow such write access > (with the default being the charger properties being made read-only) - > this way giving the best of both worlds. However then when I updated the > bq24157_charger.c driver I ended up not really needing and implementing > this feature. > > Out of curiosity, if it against best-practice to expose non hardware > properties, how would one best address the above use case? Compile time > switch? A sysfs property that a
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
On 09/08/2015 08:58 PM, Greg KH wrote: On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote: Hi Emilio, On 09/08/2015 05:51 PM, Emilio López wrote: Hi Greg & Guenter, [ ... ] Unless I am missing something, this is not explained anywhere, but it is not entirely trivial to understand. I think it should be documented. I agree. I couldn't find any mention of what this int was supposed to be by looking at Documentation/ (is_visible is not even mentioned :/) or include/linux/sysfs.h. Once we settle on something I'll document it before sending a v2. In the include file ? No strong preference, though. By the way, I wrote a quick coccinelle script to match is_visible() users which reference the index (included below), and it found references to drivers which do not seem to use any binary attributes, so I believe changing the index meaning shouldn't be an issue. Good. I agree, make i the number of the bin attribute and that should solve this issue. No, that would conflict with the "normal" use of is_visible for non-binary attributes, and make the index all but useless, since the is_visible function would have to search through all the attributes anyway to figure out which one is being checked. Yeah, using the same indexes would be somewhat pointless, although not many seem to be using it anyway (only 14 files matched). Others seem to be comparing the attr* instead. An alternative would be to use negative indexes for binary attributes and positive indexes for normal attributes. ... and I probably wrote or reviewed a significant percentage of those ;-). Using negative numbers for binary attributes is an interesting idea. Kind of unusual, though. Greg, any thoughts on that ? Ick, no, that's a mess, maybe we just could drop the index alltogether? No, please don't. Having to manually compare dozens of index pointers would be even more of a mess. Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: add vendor prefix for Socionext Inc.
Hi Lee, Rob, 2015-08-25 0:11 GMT+09:00 Rob Herring : > On Mon, Aug 24, 2015 at 1:57 AM, Lee Jones wrote: >> On Wed, 29 Jul 2015, Masahiro Yamada wrote: >> >>> Signed-off-by: Masahiro Yamada >>> --- >>> >>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >>> 1 file changed, 1 insertion(+) >> >> Patch has been around for nearly a month and is pretty trivial, so I'm >> just going to go ahead an apply it. > > Okay. I just added it now going thru my backlog, but will drop it. > > Rob > So, where has this patch gone? I've not seen it anywhere. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote: > Hi Emilio, > > On 09/08/2015 05:51 PM, Emilio López wrote: > >Hi Greg & Guenter, > > > [ ... ] > > Unless I am missing something, this is not explained anywhere, but it is > not entirely trivial to understand. I think it should be documented. > > > >I agree. I couldn't find any mention of what this int was supposed to be by > >looking at Documentation/ (is_visible is not even mentioned :/) or > >include/linux/sysfs.h. Once we settle on something I'll document it before > >sending a v2. > > > In the include file ? No strong preference, though. > > >By the way, I wrote a quick coccinelle script to match is_visible() users > >which reference the index (included below), and it found references to > >drivers which do not seem to use any binary attributes, so I believe > >changing the index meaning shouldn't be an issue. > > > Good. > > >>>I agree, make i the number of the bin attribute and that should solve > >>>this issue. > >>> > >>No, that would conflict with the "normal" use of is_visible for non-binary > >>attributes, and make the index all but useless, since the is_visible > >>function > >>would have to search through all the attributes anyway to figure out which > >>one > >>is being checked. > > > >Yeah, using the same indexes would be somewhat pointless, although not many > >seem to be using it anyway (only 14 files matched). Others seem to be > >comparing the attr* instead. An alternative would be to use negative indexes > >for binary attributes and positive indexes for normal attributes. > > > ... and I probably wrote or reviewed a significant percentage of those ;-). > > Using negative numbers for binary attributes is an interesting idea. > Kind of unusual, though. Greg, any thoughts on that ? Ick, no, that's a mess, maybe we just could drop the index alltogether? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote: On 9/8/2015 00:25, Mark Brown wrote: Sure, there's no problem at all having that structure in software but it should be possible to do this without having to represent this structure in DT. It should be possible to register the card at the same time as the rest of the components rather than needing the separate device in the DT. Do you mean using a single entry in the DT for the whole classD system and instantiate ASoC components from it. For now, there are two entry, they could be combined to one entry. Yes, exactly. Accept. the two entries will be combined to one entry. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code
On 9/8/2015 20:23, Mark Brown wrote: On Tue, Sep 08, 2015 at 05:36:01PM +0800, Wu, Songjun wrote: On 9/8/2015 00:23, Mark Brown wrote: OK, so that's not actually what the code was doing - it had separate enums for bass, mid and treble. If you make this a single enum with all the above options in it that seems like the best way of handling things. A single enum seems not very friendly to user, there are tree EQs, bass, medium and treble. So I create tree enum controls to control three EQs. The 'get' function is replaced by 'classd_get_eq_enum', if user operates one of the tree EQ controls, the other two EQs will show 0 dB. If you want to have three controls you need to write code so that the user can only change one of them from 0dB at once, returning an error otherwise. That was why it looked like they were three separate controls. If user operates two or tree controls at the same time, for my understanding, these operations are serial actually in kernel, not parallel, and the last operation will be effective. I only write the function 'classd_get_eq_enum' to get the enumeration value, if user changes one of controls, the other controls will get 0dB. Is my understanding correct? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger
On Sun, Sep 6, 2015 at 2:23 PM, Ramakrishna Pallala
wrote:
> + chip->psy_usb = power_supply_register(&client->dev,
> + &bq24261_charger_desc, &charger_cfg);
> + if (IS_ERR(chip->psy_usb)) {
> + dev_err(&client->dev,
> + "power supply registration failed(%d)\n", ret);
> + return ret;
You should not print and return ret here.
You should print and return IS_ERR(chip->psy_usb) instead.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices
On Wed, Sep 09, 2015 at 09:27:06AM +0900, Krzysztof Kozlowski wrote:
> On 09.09.2015 09:12, Andreas Dannenberg wrote:
> > Extend the bq2425x charger's device tree documentation to cover the
> > bq24250 and bq24257 devices as well as recent feature additions.
> >
> > Signed-off-by: Andreas Dannenberg
>
> Hi,
>
> Thanks for updates. Everything pointed previous looks good. After
> looking at Ramakrishna Pallala's (Cc-ed) patch ("power: bq24261_charger:
> Add support for TI BQ24261 charger") I have only one comment below.
Thanks for all your efforts and time checking those patches!
>
> > ---
> > .../devicetree/bindings/power/bq24257.txt | 21 ---
> > .../devicetree/bindings/power/bq2425x.txt | 70
> > ++
> > 2 files changed, 70 insertions(+), 21 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt
> > create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt
> >
> > diff --git a/Documentation/devicetree/bindings/power/bq24257.txt
> > b/Documentation/devicetree/bindings/power/bq24257.txt
> > deleted file mode 100644
> > index 5c9d394..000
> > --- a/Documentation/devicetree/bindings/power/bq24257.txt
> > +++ /dev/null
> > @@ -1,21 +0,0 @@
> > -Binding for TI bq24257 Li-Ion Charger
> > -
> > -Required properties:
> > -- compatible: Should contain one of the following:
> > - * "ti,bq24257"
> > -- reg:integer, i2c address of the device.
> > -- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> > -- ti,charge-current: integer, maximum charging current in uA.
> > -- ti,termination-current: integer, charge will be terminated when current
> > in
> > - constant-voltage phase drops below this value (in
> > uA).
> > -
> > -Example:
> > -
> > -bq24257 {
> > - compatible = "ti,bq24257";
> > - reg = <0x6a>;
> > -
> > - ti,battery-regulation-voltage = <420>;
> > - ti,charge-current = <100>;
> > - ti,termination-current = <5>;
> > -};
> > diff --git a/Documentation/devicetree/bindings/power/bq2425x.txt
> > b/Documentation/devicetree/bindings/power/bq2425x.txt
> > new file mode 100644
> > index 000..3e171c3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/bq2425x.txt
> > @@ -0,0 +1,70 @@
> > +Binding for TI bq2425x Li-Ion Charger
> > +
> > +Required properties:
> > +- compatible: Should contain one of the following:
> > + * "ti,bq24250"
> > + * "ti,bq24251"
> > + * "ti,bq24257"
> > +- reg: integer, i2c address of the device.
> > +- stat-gpios: GPIO used for the devices STAT_IN pin. Alternatively the pin
> > can
> > +also be defined through the standard interrupt definition properties
> > (see
> > +optional properties section below). Only use one method.
> > +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> > +- ti,charge-current: integer, maximum charging current in uA.
> > +- ti,termination-current: integer, charge will be terminated when current
> > in
> > +constant-voltage phase drops below this value (in uA).
> > +
> > +Optional properties:
> > +- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good)
> > pin.
> > +This pin is not available on all devices however it should be used if
> > +possible as this is the recommended way to obtain the charger's input
> > PG
> > +state. If this pin is not specified a software-based approach for PG
> > +detection is used.
> > +- ti,current-limit: The maximum current to be drawn from the charger's
> > input
> > +(in uA). If this property is not specified a USB D+/D- signal based
> > charger
> > +type detection is used (if available) and the input limit current is
> > set
> > +accordingly. If the D+/D- based detection is not available on a given
> > device
> > +a default of 500,000 is used (=500mA).
>
> I understand this is different property than "ti,charge-current:
> integer, default charging current (in mA)" from bq24261_charger patch?
Correct this is what "ti,current-limit" is for. And I borrowed that
definition from bq2415x_charger.c where it's used in the same context.
The reason for this property to exist is for systems where the external
power supply does more than just charging the battery, such as supplying
the system while it's charging or after it has finished charging. All
this only makes sense of course if the "ti,current-limit" is larger than
"ti,charge-current".
And if you see a few lines above the bq24257 driver also has a
"ti,charge-current" property. And yes this is what actually controls how
much current is delivered to the battery.
> This one is for setting limit on current drawn from the charger and the
> bq24261's is to limit current delivered to battery?
The bq24261 driver only exposes a "ti,charge-current" property which is
used in accordance with how other drivers use it. And it also supports
setting the input current limit but only au
Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger
On Mon, Sep 07, 2015 at 12:57:56PM +0900, Krzysztof Kozlowski wrote:
> 2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala :
> >
> > Add new charger driver support for BQ24261 charger IC.
> >
> > BQ24261 charger driver relies on extcon notifications to get the
> > charger cable type and based on that it will set the charging parameters.
> >
> > Signed-off-by: Ramakrishna Pallala
> > Signed-off-by: Jennt TC
> > ---
> > .../devicetree/bindings/power/bq24261.txt | 37 +
> > drivers/power/Kconfig |6 +
> > drivers/power/Makefile |1 +
> > drivers/power/bq24261_charger.c| 1208
> >
> > include/linux/power/bq24261_charger.h | 27 +
> > 5 files changed, 1279 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt
> > create mode 100644 drivers/power/bq24261_charger.c
> > create mode 100644 include/linux/power/bq24261_charger.h
> >
> > diff --git a/Documentation/devicetree/bindings/power/bq24261.txt
> > b/Documentation/devicetree/bindings/power/bq24261.txt
> > new file mode 100644
> > index 000..25fc5c4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/bq24261.txt
> > @@ -0,0 +1,37 @@
> > +Binding for TI bq24261 Li-Ion Charger
>
> Please split the bindings into separate patch (the first patch in patchset).
>
> > +
> > +Required properties:
> > +- compatible: Should contain one of the following:
> > +* "ti,bq24261"
> > +- reg: integer, i2c address of the device.
> > +- ti,charge-current: integer, default charging current (in mA);
> > +- ti,charge-voltage: integer, default charging voltage (in mV);
> > +- ti,termination-current: integer, charge will be terminated when current
> > in
> > +constant-voltage phase drops below this value (in mA);
> > +- ti,max-charge-current: integer, maximum charging current (in mA);
> > +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);
> > +- ti,min-charge-temperature: integer, minimum charging temperature (in
> > DegC);
> > +- ti,max-charge-temperature: integer, maximum charging temperature (in
> > DegC).
>
> Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover
> additional devices"
> http://www.spinics.net/lists/devicetree/msg92134.html
>
> could you and Andreas figure out common bindings? Look at this:
>
> +- ti,charge-current: integer, maximum charging current in uA.
> +- ti,charge-current: integer, default charging current (in mA);
>
> Different meaning and different units. This is madness! :)
>
> In the same time you are adding TI-common bindings (not device
> specific, there is no prefix) so I would expect exactly the same
> bindings if it is possible.
Krzysztof, good observation! In bq2425x_charger.c (formerly known as
bq24257_charger.c :) that I worked on the unit used was uA. At that time
I did a quick check and there didn't seem to be a clear standard whether
to use the "micro" or "milli" units - different drivers use different
units. However there seems to be a tendency for the TI drivers to prefer
"milli" (bq2415x_charger.c, bq24735-charger.c)
Personally I think "milli" units are more appropriate for chargers since
they provide sufficient granularity and the numbers don't become too big
(try typing a voltage in the Volt-range in uV, it's very easy to get the
number of 0s wrong). However since the driver was already there I left
that aspect alone to preserve compatibility.
> > +
> > +Optional properties:
> > +- ti,thermal-sensing: boolean, if present thermal regulation will be
> > enabled;
>
> What is the requirement for thermal-sensing? Can it be enabled always?
> If yes, then this is not really a hardware property.
>
> > +- ti,enable-user-write: boolean, if present driver will allow the user
> > space
> > +to control the charging current and voltage through sysfs;
>
> This is not DT property. It does not describe hardware.
I take responsibility for this one :) In an earlier thread we were
discussing that it will be better to prevent sysfs write access to
"dangerous" charger parameters (charge voltage, current, ...) but I
argued that such access might still be desirable during development and
debug, and that a DT property could be used to allow such write access
(with the default being the charger properties being made read-only) -
this way giving the best of both worlds. However then when I updated the
bq24157_charger.c driver I ended up not really needing and implementing
this feature.
Out of curiosity, if it against best-practice to expose non hardware
properties, how would one best address the above use case? Compile time
switch? A sysfs property that allows write-enabling the other sysfs
properties (doesn't sound right). Or...?
--
Andreas Dannenberg
Texas Instruments Inc
> Best regards,
> Krzysztof
>
> > +
> > +Example:
> > +
> > +bq25890 {
> > +compatible = "ti,bq24261
> > +reg = <0x6b>;
> > +
> > +
Re: [PATCH v5 4/6] spi: bcm2835: new driver implementing auxiliar spi1/spi2 on the bcm2835 soc
ker...@martin.sperl.org writes:
> From: Martin Sperl
>
> Implements spi master driver for the 2 auxiliar spi devices
> supported by the bcm2835 SOC.
>
> The driver does not implement native chip-selects but uses
> framework provided aribtrary GPIO-chip-selects.
>
> Requires soc-bcm2835-aux enable api to enable/disable HW blocks.
>
> Signed-off-by: Martin Sperl
> ---
> drivers/spi/Kconfig | 12 +
> drivers/spi/Makefile |1 +
> drivers/spi/spi-bcm2835aux.c | 514
> ++
> 3 files changed, 527 insertions(+)
> create mode 100644 drivers/spi/spi-bcm2835aux.c
>
> Changelog:
> v4->v5: added error-handling and deferred probing support
> moved change to default-config to a separate patch
> fixed Kconfig to add the correct dependency
Review comments as a diff, so you can git-am and squash them in if you
like. If you take them all, you can add "Acked-by: Eric Anholt
".
I didn't know anything about SPI before tonight, but I've looked through
what you did and it looks solid when compared to the hardware docs I've
got. The only functional comment I had that's not in my diff is that
you could probably reduce the transfer overhead by knowing that there
are 4 dwords in the transfer and receive FIFOs, so I think you could
write more before checking if you had to stop.
From e082c3b5ea32d3eb1a40b7f9b5a822ba307cf886 Mon Sep 17 00:00:00 2001
From: Eric Anholt
Date: Tue, 8 Sep 2015 17:51:08 -0700
Subject: [PATCH] spi: Changes for Martin's aux spi driver.
The intention is for these to be review fixes squashed into his commit of the
driver.
- Reset has to happen before the clock gate is disabled, since
register writes wouldn't take effect.
- Typo fixes.
- Dropped unnecessary regs/defines.
- Dropped custom clock enable/disable, assuming we use the aux clock
driver instead.
Signed-off-by: Eric Anholt
---
drivers/spi/Kconfig | 5 ++---
drivers/spi/spi-bcm2835aux.c | 45 ++--
2 files changed, 8 insertions(+), 42 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index cdb3dba..20854d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -89,16 +89,15 @@ config SPI_BCM2835
not supported.
config SPI_BCM2835AUX
- tristate "BCM2835 SPI auxiliar controller"
+ tristate "BCM2835 SPI auxiliary controller"
depends on ARCH_BCM2835 || COMPILE_TEST
depends on GPIOLIB
- select SOC_BCM2835_AUX
help
This selects a driver for the Broadcom BCM2835 SPI aux master.
The BCM2835 contains two types of SPI master controller; the
"universal SPI master", and the regular SPI controller.
- This driver is for the universal/auxiliar SPI controller.
+ This driver is for the universal/auxiliary SPI controller.
config SPI_BFIN5XX
tristate "SPI controller driver for ADI Blackfin5xx"
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index d968647..3451ecb 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -1,5 +1,5 @@
/*
- * Driver for Broadcom BCM2835 SPI Controllers
+ * Driver for Broadcom BCM2835 auxiliary SPI Controllers
*
* the driver does not rely on the native chipselects at all
* but only uses the gpio type chipselects
@@ -26,7 +26,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -38,27 +37,10 @@
#include
/*
- * shared aux registers between spi1/spi2 and uart1
- *
- * these defines could go to a separate module if needed
- * so that it can also get used with the uart1 implementation
- * when it materializes.
- */
-
-/* the AUX register offsets */
-#define BCM2835_AUX_IRQ0x00
-#define BCM2835_AUX_ENABLE 0x04
-
-/* the AUX Bitfield identical for both register */
-#define BCM2835_AUX_BIT_UART 0x0001
-#define BCM2835_AUX_BIT_SPI1 0x0002
-#define BCM2835_AUX_BIT_SPI2 0x0004
-
-/*
* spi register defines
*
* note there is garbage in the "official" documentation,
- * so somedata taken from the file:
+ * so some data is taken from the file:
* brcm_usrlib/dag/vmcsx/vcinclude/bcm2708_chip/aux_io.h
* inside of:
*
http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz
@@ -113,9 +95,6 @@
#define BCM2835_AUX_SPI_MODE_BITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH \
| SPI_NO_CS)
-#define DRV_NAME "spi-bcm2835aux"
-#define ENABLE_PROPERTY "brcm,aux-enable"
-
struct bcm2835aux_spi {
void __iomem *regs;
struct clk *clk;
@@ -450,26 +429,17 @@ static int bcm2835aux_spi_probe(struct platform_device
*pdev)
goto out_clk_disable;
}
- /* enable HW block */
- err = bcm2835aux_enable(&pdev->dev, ENABLE_PROPERTY);
- if (err) {
- dev_err(&pdev->dev, "could not enable aux: %d\n", err);
-
Re: [PATCH v5 0/6] bcm2835: auxiliar device support for spi
ker...@martin.sperl.org writes: > From: Martin Sperl > > The BCM2835 contains 3 auxiliar devices: > * spi1 > * spi2 > * uart1 > > All of those 3 devices are enabled/disabled via a shared register, > which is set by default to be disabled. > > Access to this register needs to get serialized. > > So after several iterations of discussions with the following ideas: > * syscon - device tree should describe HW not drivers to use - >'compatiblity = "brcm,bcm2835-aux-enable", "syscon";' >is not acceptable > * regulator - it is not necessarily a regulator or a power gate > that is implemented in HW, so it is not valid to use > this framework > > The recommendation was made to create a new minimal API in soc > just for access to this shared enable/disable register. > > This patch-series implements: > * the bcm2835-auxiliar device enable/disable api in soc. > * the bcm2835-auxiliar spi device driver > > The uart1 device driver (ns16550 based) is not implemented so far > but would be using the same API. > > Both spi and uart drivers can run with shared interrupts, > so there is no need for an interrupt-controller to get implemented. I finally had a chance to sit down and look at what the hardware's doing with the enable bit (also, I've read a whole lot more of the hardware now, so I'm a lot faster at answering questions like this). The enable bits are a clock gate off of the VPU clock. I knocked together the enable bits as a clock gate driver, since I'd just written very similar code for the audio domain clock driver (and I assume you are grumpy about how much time you've spent on this one stupid register). It's up at https://github.com/anholt/linux/tree/bcm2835-clock-aux and I can submit it if you like the result. I've compile tested it only, but I'm hoping you could just drop your aux SPI driver on top of it and have things work. signature.asc Description: PGP signature
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
Hi Emilio, On 09/08/2015 05:51 PM, Emilio López wrote: Hi Greg & Guenter, [ ... ] Unless I am missing something, this is not explained anywhere, but it is not entirely trivial to understand. I think it should be documented. I agree. I couldn't find any mention of what this int was supposed to be by looking at Documentation/ (is_visible is not even mentioned :/) or include/linux/sysfs.h. Once we settle on something I'll document it before sending a v2. In the include file ? No strong preference, though. By the way, I wrote a quick coccinelle script to match is_visible() users which reference the index (included below), and it found references to drivers which do not seem to use any binary attributes, so I believe changing the index meaning shouldn't be an issue. Good. I agree, make i the number of the bin attribute and that should solve this issue. No, that would conflict with the "normal" use of is_visible for non-binary attributes, and make the index all but useless, since the is_visible function would have to search through all the attributes anyway to figure out which one is being checked. Yeah, using the same indexes would be somewhat pointless, although not many seem to be using it anyway (only 14 files matched). Others seem to be comparing the attr* instead. An alternative would be to use negative indexes for binary attributes and positive indexes for normal attributes. ... and I probably wrote or reviewed a significant percentage of those ;-). Using negative numbers for binary attributes is an interesting idea. Kind of unusual, though. Greg, any thoughts on that ? Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
Hi Greg & Guenter,
On 08/09/15 16:30, Guenter Roeck wrote:
On Tue, Sep 08, 2015 at 12:10:02PM -0700, Greg KH wrote:
On Tue, Sep 08, 2015 at 08:30:13AM -0700, Guenter Roeck wrote:
Emilio,
On Tue, Sep 08, 2015 at 09:07:44AM -0300, Emilio López wrote:
According to the sysfs header file:
"The returned value will replace static permissions defined in
struct attribute or struct bin_attribute."
but this isn't the case, as is_visible is only called on
struct attribute only. This patch adds the code paths required
to support is_visible() on binary attributes.
Signed-off-by: Emilio López
---
fs/sysfs/group.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 39a0199..eb6996a 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -37,10 +37,10 @@ static int create_files(struct kernfs_node *parent, struct
kobject *kobj,
{
struct attribute *const *attr;
struct bin_attribute *const *bin_attr;
- int error = 0, i;
+ int error = 0, i = 0;
if (grp->attrs) {
- for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
+ for (attr = grp->attrs; *attr && !error; i++, attr++) {
umode_t mode = (*attr)->mode;
/*
@@ -73,13 +73,27 @@ static int create_files(struct kernfs_node *parent, struct
kobject *kobj,
}
if (grp->bin_attrs) {
- for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
+ for (bin_attr = grp->bin_attrs; *bin_attr; i++, bin_attr++) {
+ umode_t mode = (*bin_attr)->attr.mode;
+
if (update)
kernfs_remove_by_name(parent,
(*bin_attr)->attr.name);
+ if (grp->is_visible) {
+ mode = grp->is_visible(kobj,
+ &(*bin_attr)->attr, i);
With this, if 'n' is the number of non-binary attributes,
for i < n:
The index passed to is_visible points to a non-binary attribute.
for i >= n:
The index passed to is_visible points to the (index - n)th binary
attribute.
Unless I am missing something, this is not explained anywhere, but it is
not entirely trivial to understand. I think it should be documented.
I agree. I couldn't find any mention of what this int was supposed to be
by looking at Documentation/ (is_visible is not even mentioned :/) or
include/linux/sysfs.h. Once we settle on something I'll document it
before sending a v2.
By the way, I wrote a quick coccinelle script to match is_visible()
users which reference the index (included below), and it found
references to drivers which do not seem to use any binary attributes, so
I believe changing the index meaning shouldn't be an issue.
I agree, make i the number of the bin attribute and that should solve
this issue.
No, that would conflict with the "normal" use of is_visible for non-binary
attributes, and make the index all but useless, since the is_visible function
would have to search through all the attributes anyway to figure out which one
is being checked.
Yeah, using the same indexes would be somewhat pointless, although not
many seem to be using it anyway (only 14 files matched). Others seem to
be comparing the attr* instead. An alternative would be to use negative
indexes for binary attributes and positive indexes for normal attributes.
Cheers,
Emilio
>8
// Find out is_visible() users which reference the index
// somehow
virtual report
@ func @
identifier visiblefun, i, j, n;
@@
visiblefun(struct kobject *i, struct attribute *j, int n)
{
<+...n...+>
}
@ attrib depends on func @
identifier aops;
identifier func.visiblefun;
position p0;
@@
struct attribute_group aops@p0 = {
...,
.is_visible = visiblefun,
...,
};
@script:python b_report depends on report@
p0 << attrib.p0;
@@
msg = "Suspicious is_visible(), please check."
coccilib.report.print_report(p0[0], msg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: qcom: add memory node to IPQ806x/AP148
On 08/18, Mathieu Olivari wrote: > On recent bootloaders, the bootloader patches the DT blob with memory > information. However, with old bootloader, this operation doesn't > happen, which leads the board to freeze in the early init code. > > This patch adds the memory node to the AP148 dts explicitly to cover all > boot cases. > > Signed-off-by: Mathieu Olivari Does the old bootloader pass atags? If so we can just enable CONFIG_ARM_ATAG_DTB_COMPAT and then we don't need to add anything to dts files. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices
On 09.09.2015 09:12, Andreas Dannenberg wrote:
> Extend the bq2425x charger's device tree documentation to cover the
> bq24250 and bq24257 devices as well as recent feature additions.
>
> Signed-off-by: Andreas Dannenberg
Hi,
Thanks for updates. Everything pointed previous looks good. After
looking at Ramakrishna Pallala's (Cc-ed) patch ("power: bq24261_charger:
Add support for TI BQ24261 charger") I have only one comment below.
> ---
> .../devicetree/bindings/power/bq24257.txt | 21 ---
> .../devicetree/bindings/power/bq2425x.txt | 70
> ++
> 2 files changed, 70 insertions(+), 21 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt
> create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt
>
> diff --git a/Documentation/devicetree/bindings/power/bq24257.txt
> b/Documentation/devicetree/bindings/power/bq24257.txt
> deleted file mode 100644
> index 5c9d394..000
> --- a/Documentation/devicetree/bindings/power/bq24257.txt
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -Binding for TI bq24257 Li-Ion Charger
> -
> -Required properties:
> -- compatible: Should contain one of the following:
> - * "ti,bq24257"
> -- reg: integer, i2c address of the device.
> -- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> -- ti,charge-current:integer, maximum charging current in uA.
> -- ti,termination-current: integer, charge will be terminated when current in
> -constant-voltage phase drops below this value (in
> uA).
> -
> -Example:
> -
> -bq24257 {
> - compatible = "ti,bq24257";
> - reg = <0x6a>;
> -
> - ti,battery-regulation-voltage = <420>;
> - ti,charge-current = <100>;
> - ti,termination-current = <5>;
> -};
> diff --git a/Documentation/devicetree/bindings/power/bq2425x.txt
> b/Documentation/devicetree/bindings/power/bq2425x.txt
> new file mode 100644
> index 000..3e171c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/bq2425x.txt
> @@ -0,0 +1,70 @@
> +Binding for TI bq2425x Li-Ion Charger
> +
> +Required properties:
> +- compatible: Should contain one of the following:
> + * "ti,bq24250"
> + * "ti,bq24251"
> + * "ti,bq24257"
> +- reg: integer, i2c address of the device.
> +- stat-gpios: GPIO used for the devices STAT_IN pin. Alternatively the pin
> can
> +also be defined through the standard interrupt definition properties (see
> +optional properties section below). Only use one method.
> +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> +- ti,charge-current: integer, maximum charging current in uA.
> +- ti,termination-current: integer, charge will be terminated when current in
> +constant-voltage phase drops below this value (in uA).
> +
> +Optional properties:
> +- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) pin.
> +This pin is not available on all devices however it should be used if
> +possible as this is the recommended way to obtain the charger's input PG
> +state. If this pin is not specified a software-based approach for PG
> +detection is used.
> +- ti,current-limit: The maximum current to be drawn from the charger's input
> +(in uA). If this property is not specified a USB D+/D- signal based
> charger
> +type detection is used (if available) and the input limit current is set
> +accordingly. If the D+/D- based detection is not available on a given
> device
> +a default of 500,000 is used (=500mA).
I understand this is different property than "ti,charge-current:
integer, default charging current (in mA)" from bq24261_charger patch?
This one is for setting limit on current drawn from the charger and the
bq24261's is to limit current delivered to battery?
Best regards,
Krzysztof
> +- ti,ovp-voltage: Configures the over voltage protection voltage (in uV). If
> +not specified a default of 6,5000,000 (=6.5V) is used.
> +- ti,in-dpm-voltage: Configures the threshold input voltage for the dynamic
> +power path management (in uV). If not specified a default of 4,360,000
> +(=4.36V) is used.
> +- ti,safety-timer-2x-enable: If this property is set to 1 the device's safety
> +timer is extended (slowed down) by a factor of two. Setting this property
> +to 0 or not providing it will leave the safety timer at its default
> +setting.
> +- interrupt-parent: Should be the phandle for the interrupt controller. Use
> in
> +conjunction with "interrupts" and only in case "stat-gpios" is not used.
> +- interrupts: Interrupt mapping for GPIO IRQ (configure for both edges). Use
> in
> +conjunction with "interrupt-parent" and only in case "stat-gpios" is not
> +used.
> +
> +Example:
> +
> +bq24257 {
> + compatible = "ti,bq24257";
> + reg = <0x6a>;
> + stat-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
> + pg-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> +
> + ti,batt
[PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices
Extend the bq2425x charger's device tree documentation to cover the
bq24250 and bq24257 devices as well as recent feature additions.
Signed-off-by: Andreas Dannenberg
---
.../devicetree/bindings/power/bq24257.txt | 21 ---
.../devicetree/bindings/power/bq2425x.txt | 70 ++
2 files changed, 70 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt
create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt
diff --git a/Documentation/devicetree/bindings/power/bq24257.txt
b/Documentation/devicetree/bindings/power/bq24257.txt
deleted file mode 100644
index 5c9d394..000
--- a/Documentation/devicetree/bindings/power/bq24257.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Binding for TI bq24257 Li-Ion Charger
-
-Required properties:
-- compatible: Should contain one of the following:
- * "ti,bq24257"
-- reg:integer, i2c address of the device.
-- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
-- ti,charge-current: integer, maximum charging current in uA.
-- ti,termination-current: integer, charge will be terminated when current in
- constant-voltage phase drops below this value (in
uA).
-
-Example:
-
-bq24257 {
- compatible = "ti,bq24257";
- reg = <0x6a>;
-
- ti,battery-regulation-voltage = <420>;
- ti,charge-current = <100>;
- ti,termination-current = <5>;
-};
diff --git a/Documentation/devicetree/bindings/power/bq2425x.txt
b/Documentation/devicetree/bindings/power/bq2425x.txt
new file mode 100644
index 000..3e171c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/bq2425x.txt
@@ -0,0 +1,70 @@
+Binding for TI bq2425x Li-Ion Charger
+
+Required properties:
+- compatible: Should contain one of the following:
+ * "ti,bq24250"
+ * "ti,bq24251"
+ * "ti,bq24257"
+- reg: integer, i2c address of the device.
+- stat-gpios: GPIO used for the devices STAT_IN pin. Alternatively the pin can
+also be defined through the standard interrupt definition properties (see
+optional properties section below). Only use one method.
+- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
+- ti,charge-current: integer, maximum charging current in uA.
+- ti,termination-current: integer, charge will be terminated when current in
+constant-voltage phase drops below this value (in uA).
+
+Optional properties:
+- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) pin.
+This pin is not available on all devices however it should be used if
+possible as this is the recommended way to obtain the charger's input PG
+state. If this pin is not specified a software-based approach for PG
+detection is used.
+- ti,current-limit: The maximum current to be drawn from the charger's input
+(in uA). If this property is not specified a USB D+/D- signal based charger
+type detection is used (if available) and the input limit current is set
+accordingly. If the D+/D- based detection is not available on a given
device
+a default of 500,000 is used (=500mA).
+- ti,ovp-voltage: Configures the over voltage protection voltage (in uV). If
+not specified a default of 6,5000,000 (=6.5V) is used.
+- ti,in-dpm-voltage: Configures the threshold input voltage for the dynamic
+power path management (in uV). If not specified a default of 4,360,000
+(=4.36V) is used.
+- ti,safety-timer-2x-enable: If this property is set to 1 the device's safety
+timer is extended (slowed down) by a factor of two. Setting this property
+to 0 or not providing it will leave the safety timer at its default
+setting.
+- interrupt-parent: Should be the phandle for the interrupt controller. Use in
+conjunction with "interrupts" and only in case "stat-gpios" is not used.
+- interrupts: Interrupt mapping for GPIO IRQ (configure for both edges). Use in
+conjunction with "interrupt-parent" and only in case "stat-gpios" is not
+used.
+
+Example:
+
+bq24257 {
+ compatible = "ti,bq24257";
+ reg = <0x6a>;
+ stat-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+ pg-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+
+ ti,battery-regulation-voltage = <420>;
+ ti,charge-current = <100>;
+ ti,termination-current = <5>;
+};
+
+Example:
+
+bq24250 {
+ compatible = "ti,bq24250";
+ reg = <0x6a>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <16 IRQ_TYPE_EDGE_BOTH>;
+
+ ti,battery-regulation-voltage = <420>;
+ ti,charge-current = <50>;
+ ti,termination-current = <5>;
+ ti,current-limit = <90>;
+ ti,ovp-voltage = <950>;
+ ti,in-dpm-voltage = <444>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/13] power: bq24257: Renaming for consistency
Rename files and refactor definitions, function names, etc as well as
the driver name itself to reflect that this driver supports multiple
devices and not just the bq24257.
Signed-off-by: Andreas Dannenberg
---
drivers/power/Kconfig | 2 +-
drivers/power/Makefile | 2 +-
.../power/{bq24257_charger.c => bq2425x_charger.c} | 532 ++---
.../power/{bq24257_charger.h => bq2425x_charger.h} | 8 +-
4 files changed, 272 insertions(+), 272 deletions(-)
rename drivers/power/{bq24257_charger.c => bq2425x_charger.c} (64%)
rename include/linux/power/{bq24257_charger.h => bq2425x_charger.h} (85%)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index fa9b1d1..07112b1 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -395,7 +395,7 @@ config CHARGER_BQ24190
help
Say Y to enable support for the TI BQ24190 battery charger.
-config CHARGER_BQ24257
+config CHARGER_BQ2425X
tristate "TI BQ2425x battery charger driver"
depends on I2C && GPIOLIB
depends on REGMAP_I2C
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 5752ce8..4aa9048 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -59,7 +59,7 @@ obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o
-obj-$(CONFIG_CHARGER_BQ24257) += bq24257_charger.o
+obj-$(CONFIG_CHARGER_BQ2425X) += bq2425x_charger.o
obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
obj-$(CONFIG_POWER_AVS)+= avs/
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq2425x_charger.c
similarity index 64%
rename from drivers/power/bq24257_charger.c
rename to drivers/power/bq2425x_charger.c
index b5e82ed..3bf30d4 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq2425x_charger.c
@@ -1,5 +1,5 @@
/*
- * TI BQ24257 charger driver
+ * TI BQ2425x charger driver
*
* Copyright (C) 2015 Intel Corporation
*
@@ -32,21 +32,21 @@
#include
#include
-#include
+#include
-#define BQ24257_REG_1 0x00
-#define BQ24257_REG_2 0x01
-#define BQ24257_REG_3 0x02
-#define BQ24257_REG_4 0x03
-#define BQ24257_REG_5 0x04
-#define BQ24257_REG_6 0x05
-#define BQ24257_REG_7 0x06
+#define BQ2425X_REG_1 0x00
+#define BQ2425X_REG_2 0x01
+#define BQ2425X_REG_3 0x02
+#define BQ2425X_REG_4 0x03
+#define BQ2425X_REG_5 0x04
+#define BQ2425X_REG_6 0x05
+#define BQ2425X_REG_7 0x06
-#define BQ24257_MANUFACTURER "Texas Instruments"
-#define BQ24257_STAT_IRQ "stat"
-#define BQ24257_PG_GPIO"pg"
+#define BQ2425X_MANUFACTURER "Texas Instruments"
+#define BQ2425X_STAT_IRQ "stat"
+#define BQ2425X_PG_GPIO"pg"
-#define BQ24257_ILIM_SET_DELAY 1000/* msec */
+#define BQ2425X_ILIM_SET_DELAY 1000/* msec */
enum bq2425x_chip {
BQ24250,
@@ -60,7 +60,7 @@ static const char *bq2425x_chip_name[] = {
"bq24257",
};
-enum bq24257_fields {
+enum bq2425x_fields {
F_WD_FAULT, F_WD_EN, F_STAT, F_FAULT, /* REG 1 */
F_RESET, F_IILIMIT, F_EN_STAT, F_EN_TERM, F_CE, F_HZ_MODE, /* REG 2 */
F_VBAT, F_USB_DET, /* REG 3 */
@@ -73,7 +73,7 @@ enum bq24257_fields {
};
/* initial field values, converted from uV/uA */
-struct bq24257_init_data {
+struct bq2425x_init_data {
u8 ichg;/* charge current */
u8 vbat;/* regulation voltage */
u8 iterm; /* termination current */
@@ -83,13 +83,13 @@ struct bq24257_init_data {
bool timer2x_enable;/* slow down safety timer by 2x */
};
-struct bq24257_state {
+struct bq2425x_state {
u8 status;
u8 fault;
bool power_good;
};
-struct bq24257_device {
+struct bq2425x_device {
struct i2c_client *client;
struct device *dev;
struct power_supply *charger;
@@ -103,8 +103,8 @@ struct bq24257_device {
struct delayed_work iilimit_setup_work;
- struct bq24257_init_data init_data;
- struct bq24257_state state;
+ struct bq2425x_init_data init_data;
+ struct bq2425x_state state;
struct mutex lock; /* protect device access and state data */
@@ -112,11 +112,11 @@ struct bq24257_device {
bool pg_gpio_disable;
};
-static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
+static bool bq2425x_is_volatile_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
[PATCH v2 00/13] power: bq24257: Add support for bq24250/bq24251
This patch series extends the driver to also support bq24250/bq24251. The bq24250/251/257 devices have a very similar feature set and are virtually identical from a control register point of view so it made sense to extend the existing driver rather than submitting a new driver. In addition to the new device support the driver is also extended to allow access to some device features previously hidden. Basic and potentially dangerous charger config parameters affecting the actual charging of the Li-Ion battery are only configurable through firmware rather than sysfs properties. However some newly introduced properties are exposed through sysfs properties as access to them may be desired from userspace. For example, it is now possible to manually configure the maximum current drawn from the input source to accommodate different chargers (0.5A, 1.5A, 2.0A and so on) based on system knowledge a userspace application may have rather than rely on the auto-detection mechanism that may not work in all possible scenarios. Note that most patches have dependencies on other patches in the series. v2: - Aligned DT bindings better with existing "ti,*" charger bindings - Dropped patch that improperly reported a missing battery as a dead battery - Fixed (hopefully, that is -- still waiting for my test platform) issue with how the private ACPI driver_data used to identify which bq2425x device to use - Removed boolean DT/ACPI properties mostly by replacing them with more intelligent handling in the driver - Rework/clarification of DT bindings doc - Renamed/refactored filenames/symbols from bq24257 to bq2425x to better reflect that multiple devices are covered. Despite initial hesitation I feel this is a good opportunity for some clean-up as the driver is still very new in the Kernel so the change should be low risk. This also addresses one of Andrew Davis' feedback items. Plus, it makes for a nice alignment with the existing bq2415x_charger driver. v1: - Initial submission Andreas Dannenberg (13): power: bq24257: Add bit definition for temp sense enable power: bq24257: Add basic support for bq24250/bq24251 power: bq24257: Allow manual setting of input current limit power: bq24257: Add SW-based approach for Power Good determination power: bq24257: Add over voltage protection setting support power: bq24257: Add input DPM voltage threshold setting support power: bq24257: Extend scope of mutex protection power: bq24257: Add charge type setting support power: bq24257: Allow input current limit sysfs access power: bq24257: Add various device-specific sysfs properties power: bq24257: Add platform data based initialization power: bq24257: Renaming for consistency dt: power: bq2425x-charger: Cover additional devices .../devicetree/bindings/power/bq24257.txt | 21 - .../devicetree/bindings/power/bq2425x.txt | 70 + drivers/power/Kconfig |7 +- drivers/power/Makefile |2 +- drivers/power/bq24257_charger.c| 858 drivers/power/bq2425x_charger.c| 1404 include/linux/power/bq2425x_charger.h | 30 + 7 files changed, 1509 insertions(+), 883 deletions(-) delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt delete mode 100644 drivers/power/bq24257_charger.c create mode 100644 drivers/power/bq2425x_charger.c create mode 100644 include/linux/power/bq2425x_charger.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/13] power: bq24257: Allow manual setting of input current limit
A new optional device property called "ti,current-limit" is introduced
to allow disabling the D+/D- USB signal-based charger type auto-
detection algorithm used to set the input current limit and instead to
use a fixed input current limit.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 100 +++-
1 file changed, 79 insertions(+), 21 deletions(-)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 670ca57..d83898f 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -74,6 +74,7 @@ struct bq24257_init_data {
u8 ichg;/* charge current */
u8 vbat;/* regulation voltage */
u8 iterm; /* termination current */
+ u8 in_ilimit; /* input current limit */
};
struct bq24257_state {
@@ -100,6 +101,8 @@ struct bq24257_device {
struct bq24257_state state;
struct mutex lock; /* protect state data */
+
+ bool in_ilimit_autoset_disable;
};
static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
@@ -188,6 +191,12 @@ static const u32 bq24257_iterm_map[] = {
#define BQ24257_ITERM_MAP_SIZE ARRAY_SIZE(bq24257_iterm_map)
+static const u32 bq24257_iilimit_map[] = {
+ 10, 15, 50, 90, 150, 200
+};
+
+#define BQ24257_IILIMIT_MAP_SIZE ARRAY_SIZE(bq24257_iilimit_map)
+
static int bq24257_field_read(struct bq24257_device *bq,
enum bq24257_fields field_id)
{
@@ -479,24 +488,35 @@ static void bq24257_handle_state_change(struct
bq24257_device *bq,
old_state = bq->state;
mutex_unlock(&bq->lock);
- if (!new_state->power_good) {/* power removed */
- cancel_delayed_work_sync(&bq->iilimit_setup_work);
-
- /* activate D+/D- port detection algorithm */
- ret = bq24257_field_write(bq, F_DPDM_EN, 1);
- if (ret < 0)
- goto error;
+ /*
+* Handle BQ2425x state changes observing whether the D+/D- based input
+* current limit autoset functionality is enabled.
+*/
+ if (!new_state->power_good) {
+ dev_dbg(bq->dev, "Power removed\n");
+ if (!bq->in_ilimit_autoset_disable) {
+ cancel_delayed_work_sync(&bq->iilimit_setup_work);
- reset_iilimit = true;
- } else if (!old_state.power_good) { /* power inserted */
- config_iilimit = true;
- } else if (new_state->fault == FAULT_NO_BAT) { /* battery removed */
- cancel_delayed_work_sync(&bq->iilimit_setup_work);
+ /* activate D+/D- port detection algorithm */
+ ret = bq24257_field_write(bq, F_DPDM_EN, 1);
+ if (ret < 0)
+ goto error;
- reset_iilimit = true;
- } else if (old_state.fault == FAULT_NO_BAT) {/* battery connected */
- config_iilimit = true;
- } else if (new_state->fault == FAULT_TIMER) { /* safety timer expired */
+ reset_iilimit = true;
+ }
+ } else if (!old_state.power_good) {
+ dev_dbg(bq->dev, "Power inserted\n");
+ config_iilimit = !bq->in_ilimit_autoset_disable;
+ } else if (new_state->fault == FAULT_NO_BAT) {
+ dev_warn(bq->dev, "Battery removed\n");
+ if (!bq->in_ilimit_autoset_disable) {
+ cancel_delayed_work_sync(&bq->iilimit_setup_work);
+ reset_iilimit = true;
+ }
+ } else if (old_state.fault == FAULT_NO_BAT) {
+ dev_warn(bq->dev, "Battery connected\n");
+ config_iilimit = !bq->in_ilimit_autoset_disable;
+ } else if (new_state->fault == FAULT_TIMER) {
dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
}
@@ -581,7 +601,16 @@ static int bq24257_hw_init(struct bq24257_device *bq)
bq->state = state;
mutex_unlock(&bq->lock);
- if (!state.power_good)
+ if (bq->in_ilimit_autoset_disable) {
+ dev_dbg(bq->dev, "manually setting iilimit = %d\n",
+ bq->init_data.in_ilimit);
+
+ /* program fixed input current limit */
+ ret = bq24257_field_write(bq, F_IILIMIT,
+ bq->init_data.in_ilimit);
+ if (ret < 0)
+ return ret;
+ } else if (!state.power_good)
/* activate D+/D- detection algorithm */
ret = bq24257_field_write(bq, F_DPDM_EN, 1);
else if (state.fault != FAULT_NO_BAT)
@@ -659,6 +688,7 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
int ret;
u32 property;
+ /* Required properties */
[PATCH v2 11/13] power: bq24257: Add platform data based initialization
The patch adds a way to setup and initialize the device through the use
of platform data with configuration options equivalent to when using
device firmware (DT or ACPI) for systems where this is not available.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 95 +--
include/linux/power/bq24257_charger.h | 30 +++
2 files changed, 120 insertions(+), 5 deletions(-)
create mode 100644 include/linux/power/bq24257_charger.h
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 9a4a7a0..b5e82ed 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -27,10 +27,13 @@
#include
#include
#include
+#include
#include
#include
+#include
+
#define BQ24257_REG_1 0x00
#define BQ24257_REG_2 0x01
#define BQ24257_REG_3 0x02
@@ -958,28 +961,102 @@ static int bq24257_power_supply_init(struct
bq24257_device *bq)
static int bq24257_irq_probe(struct bq24257_device *bq)
{
+ struct bq24257_platform_data *pdata = bq->client->dev.platform_data;
struct gpio_desc *stat_irq;
+ int ret;
+
+ if (!pdata)
+ stat_irq = devm_gpiod_get_index(bq->dev, BQ24257_STAT_IRQ, 0,
+ GPIOD_IN);
+ else {
+ if (!gpio_is_valid(pdata->stat_gpio)) {
+ dev_err(bq->dev, "invalid stat_irq pin\n");
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(bq->dev, pdata->stat_gpio,
+ GPIOD_IN, BQ24257_STAT_IRQ);
+ if (ret) {
+ dev_err(bq->dev, "stat_irq pin request failed\n");
+ return ret;
+ }
+
+ stat_irq = gpio_to_desc(pdata->stat_gpio);
+ }
- stat_irq = devm_gpiod_get_index(bq->dev, BQ24257_STAT_IRQ, 0, GPIOD_IN);
if (IS_ERR(stat_irq)) {
dev_err(bq->dev, "could not probe stat_irq pin\n");
return PTR_ERR(stat_irq);
}
+ dev_dbg(bq->dev, "probed stat_irq pin = %d", desc_to_gpio(stat_irq));
+
return gpiod_to_irq(stat_irq);
}
static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
{
- bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
+ struct bq24257_platform_data *pdata = bq->client->dev.platform_data;
+ int ret;
+
+ if (!pdata)
+ bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0,
+ GPIOD_IN);
+ else {
+ if (!gpio_is_valid(pdata->pg_gpio)) {
+ dev_err(bq->dev, "invalid PG pin\n");
+ return -EINVAL;
+ }
+
+ ret = devm_gpio_request_one(bq->dev, pdata->pg_gpio,
+ GPIOD_IN, BQ24257_PG_GPIO);
+
+ if (ret) {
+ dev_err(bq->dev, "PG pin request failed\n");
+ return ret;
+ }
+
+ bq->pg = gpio_to_desc(pdata->pg_gpio);
+ }
+
if (IS_ERR(bq->pg)) {
dev_info(bq->dev, "could not probe PG pin\n");
return PTR_ERR(bq->pg);
}
+ dev_dbg(bq->dev, "probed PG pin = %d", desc_to_gpio(bq->pg));
+
return 0;
}
+static void bq24257_pdata_probe(struct bq24257_device *bq,
+ struct bq24257_platform_data *pdata)
+{
+ bq->init_data.ichg = bq24257_find_idx(pdata->ichg,
+ bq24257_ichg_map, BQ24257_ICHG_MAP_SIZE);
+
+ bq->init_data.vbat = bq24257_find_idx(pdata->vbat,
+ bq24257_vbat_map, BQ24257_VBAT_MAP_SIZE);
+
+ bq->init_data.iterm = bq24257_find_idx(pdata->iterm,
+ bq24257_iterm_map, BQ24257_ITERM_MAP_SIZE);
+
+ bq->init_data.in_ilimit = bq24257_find_idx(pdata->in_ilimit,
+ bq24257_iilimit_map, BQ24257_IILIMIT_MAP_SIZE);
+
+ bq->init_data.vovp = bq24257_find_idx(pdata->vovp, bq24257_vovp_map,
+ BQ24257_VOVP_MAP_SIZE);
+
+ bq->init_data.vindpm = bq24257_find_idx(pdata->vindpm,
+ bq24257_vindpm_map, BQ24257_VINDPM_MAP_SIZE);
+
+ bq->init_data.timer2x_enable = pdata->timer2x_enable;
+
+ bq->in_ilimit_autoset_disable = pdata->in_ilimit_autoset_disable;
+
+ bq->pg_gpio_disable = pdata->pg_gpio_disable;
+}
+
static int bq24257_fw_probe(struct bq24257_device *bq)
{
int ret;
@@ -1057,6 +1134,7 @@ static int bq24257_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
const struct acpi_device_id *acpi_id;
+ struct bq24257_platform_data *pdata = client->dev.platform_data;
struct bq24257_device *bq;
int ret;
int i;
@@ -1106,14 +1184,15
[PATCH v2 10/13] power: bq24257: Add various device-specific sysfs properties
This patch adds support to enable/disable some device specific features
through device properties at boot time or sysfs properties at runtime
depending on whether they should be accessible during runtime or not.
The use of those features is be optional however they might be helpful
in certain scenarios:
* High-impedance mode enable/disable (through sysfs r/w)
* Sysoff enable/disable (through sysfs r/w)
* 2X Timer enable/disable (through "ti,safety-timer-2x-enable" dev
property)
If not explicitly modified those settings are left at their device-
specific power-on defaults. Refer to the respectice device datasheets
for more information:
http://www.ti.com/product/bq24250
http://www.ti.com/product/bq24251
http://www.ti.com/product/bq24257
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 75 +
1 file changed, 75 insertions(+)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index f0602b3..9a4a7a0 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -77,6 +77,7 @@ struct bq24257_init_data {
u8 in_ilimit; /* input current limit */
u8 vovp;/* over voltage protection voltage */
u8 vindpm; /* VDMP input threshold voltage */
+ bool timer2x_enable;/* slow down safety timer by 2x */
};
struct bq24257_state {
@@ -766,6 +767,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
{F_ITERM, bq->init_data.iterm},
{F_VOVP, bq->init_data.vovp},
{F_VINDPM, bq->init_data.vindpm},
+ {F_X2_TMR_EN, bq->init_data.timer2x_enable},
};
/*
@@ -860,12 +862,78 @@ static ssize_t bq24257_show_in_dpm_voltage(struct device
*dev,
bq24257_vindpm_map[bq->init_data.vindpm]);
}
+static ssize_t bq24257_sysfs_show_enable(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq24257_device *bq = power_supply_get_drvdata(psy);
+ int ret;
+
+ mutex_lock(&bq->lock);
+
+ if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+ ret = bq24257_field_read(bq, F_HZ_MODE);
+ else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+ ret = bq24257_field_read(bq, F_SYSOFF);
+ else if (strcmp(attr->attr.name, "timer2x_enable") == 0)
+ ret = bq->init_data.timer2x_enable;
+ else
+ ret = -EINVAL;
+
+ mutex_unlock(&bq->lock);
+
+ if (ret < 0)
+ return ret;
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
+}
+
+static ssize_t bq24257_sysfs_set_enable(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq24257_device *bq = power_supply_get_drvdata(psy);
+ long val;
+ int ret;
+
+ if (kstrtol(buf, 10, &val) < 0)
+ return -EINVAL;
+
+ mutex_lock(&bq->lock);
+
+ if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+ ret = bq24257_field_write(bq, F_HZ_MODE, val);
+ else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+ ret = bq24257_field_write(bq, F_SYSOFF, val);
+ else
+ ret = -EINVAL;
+
+ mutex_unlock(&bq->lock);
+
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
+static DEVICE_ATTR(high_impedance_enable, S_IWUSR | S_IRUGO,
+ bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
+static DEVICE_ATTR(sysoff_enable, S_IWUSR | S_IRUGO,
+ bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
+static DEVICE_ATTR(timer2x_enable, S_IRUGO,
+ bq24257_sysfs_show_enable, NULL);
static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
&dev_attr_in_dpm_voltage.attr,
+ &dev_attr_high_impedance_enable.attr,
+ &dev_attr_sysoff_enable.attr,
+ &dev_attr_timer2x_enable.attr,
NULL,
};
@@ -973,6 +1041,13 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
bq->init_data.vindpm = bq24257_find_idx(property,
bq24257_vindpm_map, BQ24257_VINDPM_MAP_SIZE);
+ ret = device_property_read_u32(bq->dev, "ti,safety-timer-2x-enable",
+ &property);
+ if (ret < 0)
+ bq->init_data.timer2x_enable = false;
+ else
+ bq->init_data.timer2x_enable = property;
+
re
[PATCH v2 09/13] power: bq24257: Allow input current limit sysfs access
This patch allows reading (and writing, if the D+/D- USB signal-based
charger type detection is disabled) of the input current limit through
the POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT sysfs property. This allows
userspace to see what charger was detected and to re-configure the
maximum current drawn from the external supply at runtime based on
system-level knowledge or user input.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 44 +
1 file changed, 44 insertions(+)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 886040c..f0602b3 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -315,6 +315,41 @@ static int bq24257_set_charge_type(struct bq24257_device
*bq,
return bq24257_field_write(bq, F_CE, 0);
}
+static int bq24257_get_input_current_limit(struct bq24257_device *bq,
+ union power_supply_propval *val)
+{
+ int ret;
+
+ ret = bq24257_field_read(bq, F_IILIMIT);
+ if (ret < 0)
+ return ret;
+
+ /*
+* The "External ILIM" and "Production & Test" modes are not exposed
+* through this driver and not being covered by the lookup table.
+* Should such a mode have become active let's return an error rather
+* than exceeding the bounds of the lookup table and returning
+* garbage.
+*/
+ if (ret >= BQ24257_IILIMIT_MAP_SIZE)
+ return -ENODATA;
+
+ val->intval = bq24257_iilimit_map[ret];
+
+ return 0;
+}
+
+static int bq24257_set_input_current_limit(struct bq24257_device *bq,
+ const union power_supply_propval *val)
+{
+ if (!bq->in_ilimit_autoset_disable)
+ return -EPERM;
+
+ return bq24257_field_write(bq, F_IILIMIT, bq24257_find_idx(
+ val->intval, bq24257_iilimit_map,
+ BQ24257_IILIMIT_MAP_SIZE));
+}
+
static int bq24257_power_supply_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -403,6 +438,10 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
val->intval = bq24257_iterm_map[bq->init_data.iterm];
break;
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ ret = bq24257_get_input_current_limit(bq, val);
+ break;
+
default:
ret = -EINVAL;
}
@@ -425,6 +464,9 @@ static int bq24257_power_supply_set_property(struct
power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_TYPE:
ret = bq24257_set_charge_type(bq, val);
break;
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ ret = bq24257_set_input_current_limit(bq, val);
+ break;
default:
ret = -EINVAL;
}
@@ -439,6 +481,7 @@ static int
bq24257_power_supply_property_is_writeable(struct power_supply *psy,
{
switch (psp) {
case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
return true;
default:
return false;
@@ -778,6 +821,7 @@ static enum power_supply_property
bq24257_power_supply_props[] = {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
};
static char *bq24257_charger_supplied_to[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/13] power: bq24257: Add SW-based approach for Power Good determination
A software-based approach for determining the charger's input voltage
"Power Good" state is introduced for devices like the bq24250 which
don't have a dedicated hardware pin for that purpose. This SW-based
approach is also used for other devices (with dedicated PG pin) as a
fall back solution if that pin is not configured to be used through
"pg-gpios".
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 49 -
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index d83898f..e309ae8 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -103,6 +103,7 @@ struct bq24257_device {
struct mutex lock; /* protect state data */
bool in_ilimit_autoset_disable;
+ bool pg_gpio_disable;
};
static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
@@ -356,7 +357,26 @@ static int bq24257_get_chip_state(struct bq24257_device
*bq,
state->fault = ret;
- state->power_good = !gpiod_get_value_cansleep(bq->pg);
+ if (bq->pg_gpio_disable)
+ /*
+* If we have a chip without a dedicated power-good GPIO or
+* some other explicit bit that would provide this information
+* assume the power is good if there is no supply related
+* fault - and not good otherwise. There is a possibility for
+* other errors to mask that power in fact is not good but this
+* is probably the best we can do here.
+*/
+ switch (state->fault) {
+ case FAULT_INPUT_OVP:
+ case FAULT_INPUT_UVLO:
+ case FAULT_INPUT_LDO_LOW:
+ state->power_good = false;
+ break;
+ default:
+ state->power_good = true;
+ }
+ else
+ state->power_good = !gpiod_get_value_cansleep(bq->pg);
return 0;
}
@@ -676,7 +696,7 @@ static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
{
bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
if (IS_ERR(bq->pg)) {
- dev_err(bq->dev, "could not probe PG pin\n");
+ dev_info(bq->dev, "could not probe PG pin\n");
return PTR_ERR(bq->pg);
}
@@ -808,10 +828,27 @@ static int bq24257_probe(struct i2c_client *client,
INIT_DELAYED_WORK(&bq->iilimit_setup_work,
bq24257_iilimit_setup_work);
- /* we can only check Power Good status by probing the PG pin */
- ret = bq24257_pg_gpio_probe(bq);
- if (ret < 0)
- return ret;
+ /*
+* The BQ24250 doesn't have a dedicated Power Good (PG) pin so we
+* explicitly disable this feature for this device and instead use
+* a SW-based approach to determine the PG state.
+*/
+ if (bq->chip == BQ24250)
+ bq->pg_gpio_disable = true;
+
+ /*
+* For devices that do have a dedicated PG pin go ahead and probe it,
+* using the SW-based approach as a fall back solution. Note that the
+* use of the dedicated pin is preferred.
+*/
+ if (!bq->pg_gpio_disable) {
+ ret = bq24257_pg_gpio_probe(bq);
+ if (ret < 0) {
+ dev_info(bq->dev,
+ "using SW-based power-good detection\n");
+ bq->pg_gpio_disable = true;
+ }
+ }
/* reset all registers to defaults */
ret = bq24257_field_write(bq, F_RESET, 1);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/13] power: bq24257: Add charge type setting support
The bq2425x devices support charging with a configurable charge current
i_chg or a specific fixed low-current in what's called Low Charge mode.
This patch exposes access to the Low Charge mode through a POWER_
SUPPLY_PROP_CHARGE_TYPE sysfs property value of POWER_SUPPLY_CHARGE_
TYPE_TRICKLE. It also allows to completely disable charging if desired
by setting the property to POWER_SUPPLY_CHARGE_TYPE_NONE. Normal
charging with the configured i_chg current is activated through
POWER_SUPPLY_CHARGE_TYPE_FAST (default).
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 90 +
1 file changed, 90 insertions(+)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index f0d4307..886040c 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -265,6 +265,56 @@ enum bq24257_fault {
FAULT_INPUT_LDO_LOW,
};
+static int bq24257_get_charge_type(struct bq24257_device *bq,
+ union power_supply_propval *val)
+{
+ int ret;
+
+ ret = bq24257_field_read(bq, F_CE);
+ if (ret < 0)
+ return ret;
+
+ /* Charge Enable is active-low */
+ if (ret) {
+ val->intval = POWER_SUPPLY_CHARGE_TYPE_NONE;
+ return 0;
+ }
+
+ /* Low Charge means a fixed low-current is used instead of i_chg */
+ ret = bq24257_field_read(bq, F_LOW_CHG);
+ if (ret < 0)
+ return ret;
+
+ val->intval = ret ? POWER_SUPPLY_CHARGE_TYPE_TRICKLE :
+ POWER_SUPPLY_CHARGE_TYPE_FAST;
+
+ return 0;
+}
+
+static int bq24257_set_charge_type(struct bq24257_device *bq,
+ const union power_supply_propval *val)
+{
+ int ret;
+
+ switch (val->intval) {
+ case POWER_SUPPLY_CHARGE_TYPE_NONE:
+ return bq24257_field_write(bq, F_CE, 1);
+ case POWER_SUPPLY_CHARGE_TYPE_TRICKLE:
+ ret = bq24257_field_write(bq, F_LOW_CHG, 1);
+ break;
+ case POWER_SUPPLY_CHARGE_TYPE_FAST:
+ ret = bq24257_field_write(bq, F_LOW_CHG, 0);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ return bq24257_field_write(bq, F_CE, 0);
+}
+
static int bq24257_power_supply_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -290,6 +340,10 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
break;
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ ret = bq24257_get_charge_type(bq, val);
+ break;
+
case POWER_SUPPLY_PROP_MANUFACTURER:
val->strval = BQ24257_MANUFACTURER;
break;
@@ -358,6 +412,39 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
return ret;
}
+static int bq24257_power_supply_set_property(struct power_supply *psy,
+ enum power_supply_property prop,
+ const union power_supply_propval *val)
+{
+ struct bq24257_device *bq = power_supply_get_drvdata(psy);
+ int ret;
+
+ mutex_lock(&bq->lock);
+
+ switch (prop) {
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ ret = bq24257_set_charge_type(bq, val);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ mutex_unlock(&bq->lock);
+
+ return ret;
+}
+
+static int bq24257_power_supply_property_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ return true;
+ default:
+ return false;
+ }
+}
+
static int bq24257_get_chip_state(struct bq24257_device *bq,
struct bq24257_state *state)
{
@@ -683,6 +770,7 @@ static enum power_supply_property
bq24257_power_supply_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
@@ -702,6 +790,8 @@ static const struct power_supply_desc
bq24257_power_supply_desc = {
.properties = bq24257_power_supply_props,
.num_properties = ARRAY_SIZE(bq24257_power_supply_props),
.get_property = bq24257_power_supply_get_property,
+ .set_property = bq24257_power_supply_set_property,
+ .property_is_writeable = bq24257_power_supply_property_is_writeable
};
static ssize_t bq24257_show_ovp_voltage(struct device *dev,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe de
[PATCH v2 05/13] power: bq24257: Add over voltage protection setting support
A new optional device property called "ti,ovp-voltage" is introduced to
allow configuring the input over voltage protection setting.
This commit also adds the basic sysfs support for custom properties
which is being used to allow userspace to read the current ovp-voltage
setting.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 66 +++--
1 file changed, 63 insertions(+), 3 deletions(-)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index e309ae8..917609b 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -75,6 +75,7 @@ struct bq24257_init_data {
u8 vbat;/* regulation voltage */
u8 iterm; /* termination current */
u8 in_ilimit; /* input current limit */
+ u8 vovp;/* over voltage protection voltage */
};
struct bq24257_state {
@@ -198,6 +199,13 @@ static const u32 bq24257_iilimit_map[] = {
#define BQ24257_IILIMIT_MAP_SIZE ARRAY_SIZE(bq24257_iilimit_map)
+static const u32 bq24257_vovp_map[] = {
+ 600, 650, 700, 800, 900, 950, 1000,
+ 1050
+};
+
+#define BQ24257_VOVP_MAP_SIZE ARRAY_SIZE(bq24257_vovp_map)
+
static int bq24257_field_read(struct bq24257_device *bq,
enum bq24257_fields field_id)
{
@@ -413,6 +421,17 @@ enum bq24257_in_ilimit {
IILIMIT_NONE,
};
+enum bq24257_vovp {
+ VOVP_6000,
+ VOVP_6500,
+ VOVP_7000,
+ VOVP_8000,
+ VOVP_9000,
+ VOVP_9500,
+ VOVP_1,
+ VOVP_10500
+};
+
enum bq24257_port_type {
PORT_TYPE_DCP, /* Dedicated Charging Port */
PORT_TYPE_CDP, /* Charging Downstream Port */
@@ -594,7 +613,8 @@ static int bq24257_hw_init(struct bq24257_device *bq)
} init_data[] = {
{F_ICHG, bq->init_data.ichg},
{F_VBAT, bq->init_data.vbat},
- {F_ITERM, bq->init_data.iterm}
+ {F_ITERM, bq->init_data.iterm},
+ {F_VOVP, bq->init_data.vovp},
};
/*
@@ -664,6 +684,28 @@ static const struct power_supply_desc
bq24257_power_supply_desc = {
.get_property = bq24257_power_supply_get_property,
};
+static ssize_t bq24257_show_ovp_voltage(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n",
+ bq24257_vovp_map[bq->init_data.vovp]);
+}
+
+static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+
+static struct attribute *bq24257_charger_attr[] = {
+ &dev_attr_ovp_voltage.attr,
+ NULL,
+};
+
+static const struct attribute_group bq24257_attr_group = {
+ .attrs = bq24257_charger_attr,
+};
+
static int bq24257_power_supply_init(struct bq24257_device *bq)
{
struct power_supply_config psy_cfg = { .drv_data = bq, };
@@ -748,6 +790,14 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
bq24257_iilimit_map, BQ24257_IILIMIT_MAP_SIZE);
}
+ ret = device_property_read_u32(bq->dev, "ti,ovp-voltage",
+ &property);
+ if (ret < 0)
+ bq->init_data.vovp = VOVP_6500;
+ else
+ bq->init_data.vovp = bq24257_find_idx(property,
+ bq24257_vovp_map, BQ24257_VOVP_MAP_SIZE);
+
return 0;
}
@@ -887,10 +937,18 @@ static int bq24257_probe(struct i2c_client *client,
return ret;
ret = bq24257_power_supply_init(bq);
- if (ret < 0)
+ if (ret < 0) {
dev_err(dev, "Failed to register power supply\n");
+ return ret;
+ }
- return ret;
+ ret = sysfs_create_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+ if (ret < 0) {
+ dev_err(dev, "Can't create sysfs entries\n");
+ return ret;
+ }
+
+ return 0;
}
static int bq24257_remove(struct i2c_client *client)
@@ -900,6 +958,8 @@ static int bq24257_remove(struct i2c_client *client)
if (!bq->in_ilimit_autoset_disable)
cancel_delayed_work_sync(&bq->iilimit_setup_work);
+ sysfs_remove_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+
power_supply_unregister(bq->charger);
bq24257_field_write(bq, F_RESET, 1); /* reset to defaults */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/13] power: bq24257: Add bit definition for temp sense enable
Adding a missing bit definition for the sake of consistency device model
vs. bit field representation. No change in functionality.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 5859bc7..db81356 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -47,7 +47,7 @@ enum bq24257_fields {
F_VBAT, F_USB_DET, /* REG 3 */
F_ICHG, F_ITERM,/* REG 4 */
F_LOOP_STATUS, F_LOW_CHG, F_DPDM_EN, F_CE_STATUS, F_VINDPM, /* REG 5 */
- F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_STAT,/* REG 6 */
+ F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_EN, F_TS_STAT, /* REG 6 */
F_VOVP, F_CLR_VDP, F_FORCE_BATDET, F_FORCE_PTM, /* REG 7 */
F_MAX_FIELDS
@@ -135,6 +135,7 @@ static const struct reg_field bq24257_reg_fields[] = {
[F_X2_TMR_EN] = REG_FIELD(BQ24257_REG_6, 7, 7),
[F_TMR] = REG_FIELD(BQ24257_REG_6, 5, 6),
[F_SYSOFF] = REG_FIELD(BQ24257_REG_6, 4, 4),
+ [F_TS_EN] = REG_FIELD(BQ24257_REG_6, 3, 3),
[F_TS_STAT] = REG_FIELD(BQ24257_REG_6, 0, 2),
/* REG 7 */
[F_VOVP]= REG_FIELD(BQ24257_REG_7, 5, 7),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/13] power: bq24257: Extend scope of mutex protection
This commit extends the use of the existing mutex to pave the way for
using direct device access inside sysfs getter/setter routines in a
way that the access during interrupts and timer routines does not
interfere with device access by the CPU or between multiple cores.
This also addresses a potential race condition that could be caused
by bq24257_irq_handler_thread() and bq24257_iilimit_autoset() accessing
the device simultaneously.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 60 -
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index c160fde..f0d4307 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -102,7 +102,7 @@ struct bq24257_device {
struct bq24257_init_data init_data;
struct bq24257_state state;
- struct mutex lock; /* protect state data */
+ struct mutex lock; /* protect device access and state data */
bool in_ilimit_autoset_disable;
bool pg_gpio_disable;
@@ -271,10 +271,10 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
{
struct bq24257_device *bq = power_supply_get_drvdata(psy);
struct bq24257_state state;
+ int ret = 0;
mutex_lock(&bq->lock);
state = bq->state;
- mutex_unlock(&bq->lock);
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
@@ -350,10 +350,12 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
break;
default:
- return -EINVAL;
+ ret = -EINVAL;
}
- return 0;
+ mutex_unlock(&bq->lock);
+
+ return ret;
}
static int bq24257_get_chip_state(struct bq24257_device *bq,
@@ -400,15 +402,9 @@ static int bq24257_get_chip_state(struct bq24257_device
*bq,
static bool bq24257_state_changed(struct bq24257_device *bq,
struct bq24257_state *new_state)
{
- int ret;
-
- mutex_lock(&bq->lock);
- ret = (bq->state.status != new_state->status ||
- bq->state.fault != new_state->fault ||
- bq->state.power_good != new_state->power_good);
- mutex_unlock(&bq->lock);
-
- return ret;
+ return bq->state.status != new_state->status ||
+ bq->state.fault != new_state->fault ||
+ bq->state.power_good != new_state->power_good;
}
enum bq24257_loop_status {
@@ -531,7 +527,9 @@ static void bq24257_iilimit_setup_work(struct work_struct
*work)
struct bq24257_device *bq = container_of(work, struct bq24257_device,
iilimit_setup_work.work);
+ mutex_lock(&bq->lock);
bq24257_iilimit_autoset(bq);
+ mutex_unlock(&bq->lock);
}
static void bq24257_handle_state_change(struct bq24257_device *bq,
@@ -542,9 +540,7 @@ static void bq24257_handle_state_change(struct
bq24257_device *bq,
bool reset_iilimit = false;
bool config_iilimit = false;
- mutex_lock(&bq->lock);
old_state = bq->state;
- mutex_unlock(&bq->lock);
/*
* Handle BQ2425x state changes observing whether the D+/D- based input
@@ -599,25 +595,30 @@ static irqreturn_t bq24257_irq_handler_thread(int irq,
void *private)
struct bq24257_device *bq = private;
struct bq24257_state state;
+ mutex_lock(&bq->lock);
+
ret = bq24257_get_chip_state(bq, &state);
if (ret < 0)
- return IRQ_HANDLED;
+ goto out;
if (!bq24257_state_changed(bq, &state))
- return IRQ_HANDLED;
+ goto out;
dev_dbg(bq->dev, "irq(state changed): status/fault/pg = %d/%d/%d\n",
state.status, state.fault, state.power_good);
bq24257_handle_state_change(bq, &state);
-
- mutex_lock(&bq->lock);
bq->state = state;
+
mutex_unlock(&bq->lock);
power_supply_changed(bq->charger);
return IRQ_HANDLED;
+
+out:
+ mutex_unlock(&bq->lock);
+ return IRQ_HANDLED;
}
static int bq24257_hw_init(struct bq24257_device *bq)
@@ -657,9 +658,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
if (ret < 0)
return ret;
- mutex_lock(&bq->lock);
bq->state = state;
- mutex_unlock(&bq->lock);
if (bq->in_ilimit_autoset_disable) {
dev_dbg(bq->dev, "manually setting iilimit = %d\n",
@@ -1018,11 +1017,15 @@ static int bq24257_suspend(struct device *dev)
if (!bq->in_ilimit_autoset_disable)
cancel_delayed_work_sync(&bq->iilimit_setup_work);
+ mutex_lock(&bq->lock);
+
/* reset all registers to default (and activate standalone mode) */
ret = bq24257_field_write(bq, F_RESET, 1);
if (ret < 0)
dev_err(bq->dev
[PATCH v2 06/13] power: bq24257: Add input DPM voltage threshold setting support
A new optional device property called "ti,in-dpm-voltage" is introduced
to allow configuring the input voltage threshold for the devices'
dynamic power path management (DPM) feature. In short, it can be used to
prevent the input voltage from dropping below a certain value as current
is drawn to charge the battery or supply the system.
Signed-off-by: Andreas Dannenberg
---
drivers/power/bq24257_charger.c | 42 +
1 file changed, 42 insertions(+)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 917609b..c160fde 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -76,6 +76,7 @@ struct bq24257_init_data {
u8 iterm; /* termination current */
u8 in_ilimit; /* input current limit */
u8 vovp;/* over voltage protection voltage */
+ u8 vindpm; /* VDMP input threshold voltage */
};
struct bq24257_state {
@@ -206,6 +207,13 @@ static const u32 bq24257_vovp_map[] = {
#define BQ24257_VOVP_MAP_SIZE ARRAY_SIZE(bq24257_vovp_map)
+static const u32 bq24257_vindpm_map[] = {
+ 420, 428, 436, 444, 452, 460, 468,
+ 476
+};
+
+#define BQ24257_VINDPM_MAP_SIZEARRAY_SIZE(bq24257_vindpm_map)
+
static int bq24257_field_read(struct bq24257_device *bq,
enum bq24257_fields field_id)
{
@@ -432,6 +440,17 @@ enum bq24257_vovp {
VOVP_10500
};
+enum bq24257_vindpm {
+ VINDPM_4200,
+ VINDPM_4280,
+ VINDPM_4360,
+ VINDPM_4440,
+ VINDPM_4520,
+ VINDPM_4600,
+ VINDPM_4680,
+ VINDPM_4760
+};
+
enum bq24257_port_type {
PORT_TYPE_DCP, /* Dedicated Charging Port */
PORT_TYPE_CDP, /* Charging Downstream Port */
@@ -615,6 +634,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
{F_VBAT, bq->init_data.vbat},
{F_ITERM, bq->init_data.iterm},
{F_VOVP, bq->init_data.vovp},
+ {F_VINDPM, bq->init_data.vindpm},
};
/*
@@ -648,6 +668,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
/* program fixed input current limit */
ret = bq24257_field_write(bq, F_IILIMIT,
bq->init_data.in_ilimit);
+
if (ret < 0)
return ret;
} else if (!state.power_good)
@@ -695,10 +716,23 @@ static ssize_t bq24257_show_ovp_voltage(struct device
*dev,
bq24257_vovp_map[bq->init_data.vovp]);
}
+static ssize_t bq24257_show_in_dpm_voltage(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct power_supply *psy = dev_get_drvdata(dev);
+ struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n",
+ bq24257_vindpm_map[bq->init_data.vindpm]);
+}
+
static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
+ &dev_attr_in_dpm_voltage.attr,
NULL,
};
@@ -798,6 +832,14 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
bq->init_data.vovp = bq24257_find_idx(property,
bq24257_vovp_map, BQ24257_VOVP_MAP_SIZE);
+ ret = device_property_read_u32(bq->dev, "ti,in-dpm-voltage",
+ &property);
+ if (ret < 0)
+ bq->init_data.vindpm = VINDPM_4360;
+ else
+ bq->init_data.vindpm = bq24257_find_idx(property,
+ bq24257_vindpm_map, BQ24257_VINDPM_MAP_SIZE);
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/13] power: bq24257: Add basic support for bq24250/bq24251
This patch adds basic support for bq24250 and bq24251 which are very
similar to the bq24257 the driver was originally written for. Basic
support means the ability to select a device through Kconfig, DT and
ACPI, an instance variable allowing to check which chip is active, and
the reporting back of the selected device through the
POWER_SUPPLY_PROP_MODEL_NAME power supply sysfs property.
This patch by itself is not sufficient to actually use those two added
devices in a real-world setting due to some feature differences which
are addressed by other patches in this series.
Signed-off-by: Andreas Dannenberg
---
drivers/power/Kconfig | 5 +++--
drivers/power/bq24257_charger.c | 50 ++---
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 08beeed..fa9b1d1 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -396,11 +396,12 @@ config CHARGER_BQ24190
Say Y to enable support for the TI BQ24190 battery charger.
config CHARGER_BQ24257
- tristate "TI BQ24257 battery charger driver"
+ tristate "TI BQ2425x battery charger driver"
depends on I2C && GPIOLIB
depends on REGMAP_I2C
help
- Say Y to enable support for the TI BQ24257 battery charger.
+ Say Y to enable support for the TI BQ24250, BQ24251, and BQ24257
battery
+ chargers.
config CHARGER_BQ24735
tristate "TI BQ24735 battery charger support"
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index db81356..670ca57 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -13,6 +13,10 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
+ * Datasheets:
+ * http://www.ti.com/product/bq24250
+ * http://www.ti.com/product/bq24251
+ * http://www.ti.com/product/bq24257
*/
#include
@@ -41,6 +45,18 @@
#define BQ24257_ILIM_SET_DELAY 1000/* msec */
+enum bq2425x_chip {
+ BQ24250,
+ BQ24251,
+ BQ24257,
+};
+
+static const char *bq2425x_chip_name[] = {
+ "bq24250",
+ "bq24251",
+ "bq24257",
+};
+
enum bq24257_fields {
F_WD_FAULT, F_WD_EN, F_STAT, F_FAULT, /* REG 1 */
F_RESET, F_IILIMIT, F_EN_STAT, F_EN_TERM, F_CE, F_HZ_MODE, /* REG 2 */
@@ -71,6 +87,8 @@ struct bq24257_device {
struct device *dev;
struct power_supply *charger;
+ enum bq2425x_chip chip;
+
struct regmap *rmap;
struct regmap_field *rmap_fields[F_MAX_FIELDS];
@@ -250,6 +268,10 @@ static int bq24257_power_supply_get_property(struct
power_supply *psy,
val->strval = BQ24257_MANUFACTURER;
break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = bq2425x_chip_name[bq->chip];
+ break;
+
case POWER_SUPPLY_PROP_ONLINE:
val->intval = state.power_good;
break;
@@ -570,6 +592,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
static enum power_supply_property bq24257_power_supply_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_HEALTH,
@@ -667,6 +690,7 @@ static int bq24257_probe(struct i2c_client *client,
{
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
+ const struct acpi_device_id *acpi_id;
struct bq24257_device *bq;
int ret;
int i;
@@ -683,6 +707,18 @@ static int bq24257_probe(struct i2c_client *client,
bq->client = client;
bq->dev = dev;
+ if (ACPI_HANDLE(dev)) {
+ acpi_id = acpi_match_device(dev->driver->acpi_match_table,
+ &client->dev);
+ if (!acpi_id) {
+ dev_err(dev, "Failed to match ACPI device\n");
+ return -ENODEV;
+ }
+ bq->chip = (enum bq2425x_chip)acpi_id->driver_data;
+ } else {
+ bq->chip = (enum bq2425x_chip)id->driver_data;
+ }
+
mutex_init(&bq->lock);
bq->rmap = devm_regmap_init_i2c(client, &bq24257_regmap_config);
@@ -824,19 +860,27 @@ static const struct dev_pm_ops bq24257_pm = {
};
static const struct i2c_device_id bq24257_i2c_ids[] = {
- { "bq24257", 0 },
+ { "bq24250", BQ24250 },
+ { "bq24251", BQ24251 },
+ { "bq24257", BQ24257 },
{},
};
MODULE_DEVICE_TABLE(i2c, bq24257_i2c_ids);
static const struct of_device_id bq24257_of_match[] = {
- { .compatible = "ti,bq24257", },
+ {
+ .compatible = "ti,bq24250",
+ .compatible = "ti,bq24251",
+ .compatible = "ti,bq24257",
+ },
{ },
};
MO
[PATCH net-next 2/2] dtb: xgene: Add 2nd 10GbE node
Adding the second 10GbE dt node for APM X-Gene SoC device tree
Signed-off-by: Iyappan Subramanian
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index d831bc2..d483e7e 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -207,6 +207,17 @@
clock-output-names = "xge0clk";
};
+ xge1clk: xge1clk@1f62c000 {
+ compatible = "apm,xgene-device-clock";
+ status = "disabled";
+ #clock-cells = <1>;
+ clocks = <&socplldiv2 0>;
+ reg = <0x0 0x1f62c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ csr-mask = <0x3>;
+ clock-output-names = "xge1clk";
+ };
+
sataphy1clk: sataphy1clk@1f21c000 {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
@@ -816,6 +827,23 @@
phy-connection-type = "xgmii";
};
+ xgenet1: ethernet@1f62 {
+ compatible = "apm,xgene1-xgenet";
+ status = "disabled";
+ reg = <0x0 0x1f62 0x0 0xd100>,
+ <0x0 0x1f60 0x0 0Xc300>,
+ <0x0 0x1800 0x0 0X8000>;
+ reg-names = "enet_csr", "ring_csr", "ring_cmd";
+ interrupts = <0x0 0x6C 0x4>,
+<0x0 0x6D 0x4>;
+ port-id = <1>;
+ dma-coherent;
+ clocks = <&xge1clk 0>;
+ /* mac address will be overwritten by the bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-connection-type = "xgmii";
+ };
+
rng: rng@1052 {
compatible = "apm,xgene-rng";
reg = <0x0 0x1052 0x0 0x100>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] driver: net: xgene: Add support for 2nd 10GbE port
Adding support for the second 10GbE port on APM X-Gene SoC
Signed-off-by: Iyappan Subramanian
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 ++-
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 16
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 5 +
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index cfa3704..21749f0 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -107,7 +107,8 @@ static void xgene_enet_set_ring_state(struct
xgene_enet_desc_ring *ring)
{
xgene_enet_ring_set_type(ring);
- if (xgene_enet_ring_owner(ring->id) == RING_OWNER_ETH0)
+ if (xgene_enet_ring_owner(ring->id) == RING_OWNER_ETH0 ||
+ xgene_enet_ring_owner(ring->id) == RING_OWNER_ETH1)
xgene_enet_ring_set_recombbuf(ring);
xgene_enet_ring_init(ring);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index e47298f..6b1846d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1305,10 +1305,17 @@ static void xgene_enet_setup_ops(struct
xgene_enet_pdata *pdata)
pdata->ring_num = START_RING_NUM_0;
break;
case 1:
- pdata->cpu_bufnum = START_CPU_BUFNUM_1;
- pdata->eth_bufnum = START_ETH_BUFNUM_1;
- pdata->bp_bufnum = START_BP_BUFNUM_1;
- pdata->ring_num = START_RING_NUM_1;
+ if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+ pdata->cpu_bufnum = XG_START_CPU_BUFNUM_1;
+ pdata->eth_bufnum = XG_START_ETH_BUFNUM_1;
+ pdata->bp_bufnum = XG_START_BP_BUFNUM_1;
+ pdata->ring_num = XG_START_RING_NUM_1;
+ } else {
+ pdata->cpu_bufnum = START_CPU_BUFNUM_1;
+ pdata->eth_bufnum = START_ETH_BUFNUM_1;
+ pdata->bp_bufnum = START_BP_BUFNUM_1;
+ pdata->ring_num = START_RING_NUM_1;
+ }
break;
default:
break;
@@ -1478,6 +1485,7 @@ static const struct acpi_device_id
xgene_enet_acpi_match[] = {
{ "APMC0D05", XGENE_ENET1},
{ "APMC0D30", XGENE_ENET1},
{ "APMC0D31", XGENE_ENET1},
+ { "APMC0D3F", XGENE_ENET1},
{ "APMC0D26", XGENE_ENET2},
{ "APMC0D25", XGENE_ENET2},
{ }
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 50f92c3..ff89a5d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -56,6 +56,11 @@
#define START_BP_BUFNUM_1 0x2A
#define START_RING_NUM_1 264
+#define XG_START_CPU_BUFNUM_1 12
+#define XG_START_ETH_BUFNUM_1 2
+#define XG_START_BP_BUFNUM_1 0x22
+#define XG_START_RING_NUM_1264
+
#define X2_START_CPU_BUFNUM_0 0
#define X2_START_ETH_BUFNUM_0 0
#define X2_START_BP_BUFNUM_0 0x20
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] driver: net: xgene: Enable 2nd 10GbE port on APM X-Gene SoC
This patch adds support for 2nd 10GbE on APM X-Gene SoC --- Iyappan Subramanian (2): driver: net: xgene: Add support for 2nd 10GbE port dtb: xgene: Add 2nd 10GbE node arch/arm64/boot/dts/apm/apm-storm.dtsi | 28 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 ++- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 16 ++ drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 5 + 4 files changed, 47 insertions(+), 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Tue 08 Sep 05:20 PDT 2015, Linus Walleij wrote: > On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson > wrote: > > Let's discuss this a bit, looping in Mark Brown. > > > As some of these states on some platforms are passed as physical signals > > instead, the two drivers are modelled as gpio- and interrupt-controllers - > > providing a nice abstraction both in device tree sense and Linux > > implementation > > sense. > > I have unfortunately repeatedly encountered an argument of the type > "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so > we can use that nice infrastructure". > I guess that's what you get for maintaining a subsystem with "general purpose" in the name ;) Sorry for adding one more item to your list. > I'm not pleased with something that is not really general purpose > input/output being called GPIO. It fits badly with the GPIO subsystem > when we support things like open drain and cross-mappings to > the pin control subsystem that will never be applicable to these > new users. It's more like "special purpose input/output" or > something. > Right, this doesn't match at all with the electrical properties. What it does give is the nice symmetry with the irq bits and existing apis for poking and peeking. > This happened with syscon LEDs for example, and was the reason > I implemented syscon-leds. The original proposal was to say the LEDs > register was "a kind of GPIO" on top of regmap and then use gpio-leds > on top of that. Instead I insisted it was a syscon/regmap and the > LEDs go directly to that, bypassing one layer of abstraction. > > I also imagine creating syscon-keys.c for input from arbitrary keys > in a syscon register actually. Just didn't get around to that yet. > The difference with those two cases is that the pieces didn't fit together, so we tried to use the gpio framework as an adaptor to make it work. I picked the gpio framework because: * the DT nicely represent the structure of the memory and relationship between the individual components. * the implementation needs to be able to set and clear individual bits, as well as register handlers for state changes. * I'm told the SMP2P entries are on some platform (I've never seen) actual gpio lines. > I also see some of the stuff GPIO does out-of-the-box being useful, > for example in MFD: some of these are interrupt controllers and > basically duplicate the kind of code I have in gpiolib for > GPIOLIB_IRQCHIP. > I do learn about new helper functions every time I touch these things. > So we need to figure out what is really needed. > > While sparsely documented: what about regmap (maybe in the > form of syscon) and drivers/base/regmap/regmap-irq.c for the > interrupt handling? > regmap-irq looks good and reasonable. The problem is that for SMSM I need custom masking operations and on SMP2P I have multiple regmaps sharing one incoming IRQ. So it doesn't look applicable for my use cases. > I cannot claim to understand regmap-irq.c, but I just intuitively > think it deserves consideration, such that drivers who need one > of these misc registers can read/write their bits with regmap > accessors and also get IRQs by way of regmap-irq. > I was expecting some push back from you, but as it was the cleanest abstraction I would come up with I gave it a shot :) I'll rewrite the outgoing part based on regmaps instead. Thanks for reviewing. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] Documentation: add Device tree bindings for hwmon/nct7802
Add sensors' types configuration.
---
Changed on v4:
- Removed registers initialization by names
- Added properties nuvoton,sensor*-type
Changed in v3:
- Fixed vendor prefix
- Added short registers description,
full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/
Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names
Introduced in v1:
- nct7802,reg-init
Signed-off-by: Constantine Shulyupin
---
.../devicetree/bindings/hwmon/nct7802.txt | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
diff --git a/Documentation/devicetree/bindings/hwmon/nct7802.txt
b/Documentation/devicetree/bindings/hwmon/nct7802.txt
new file mode 100644
index 000..20461f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nct7802.txt
@@ -0,0 +1,31 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+
+Optional string properties:
+
+ - nuvoton,sensor1-type
+ - nuvoton,sensor2-type
+ - nuvoton,sensor3-type
+
+Allowed values for nuvoton,sensor*-type:
+ - "disabled"
+ - "thermal diode"
+ - "thermistor"
+ - "voltage"
+
+Except "nuvoton,sensor3-type" can't be "thermal diode".
+
+Example nct7802 node:
+
+nct7802 {
+ compatible = "nuvoton,nct7802";
+ reg = <0x2a>;
+ nuvoton,start = <0x01>;
+ nuvoton,moensor1-type = "thermistor";
+ nuvoton,moensor2-type = "disabled";
+ nuvoton,moensor3-type = "voltage";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: sun5i: Add sun5i-q8-common.dtsi
Hi, On 09/08/2015 04:33 PM, Maxime Ripard wrote: On Sat, Sep 05, 2015 at 04:55:52PM +0200, Hans de Goede wrote: This is the sun5i / a13 version of sun8i-q8-common.dtsi for use in dts files for a13 q8 based tablets. Compared to sun8i this uses uart1 for the serial console, and PG0 for card-detect for mmc0. This also adds pmic and otg support, which both use the same config on all known q8 a13 devices. This is not present in sun5i-q8-common.dtsi because pmic / otg support for sun8i has not yet been merged. Signed-off-by: Hans de Goede Are we going to have any user but the one you posted in the patch 3 planned? Depends on what I can get my hands on / what is in the post atm. One difference in fex files of different 18 variants is how the usb wifi is powered, either via a gpio or via ldo3. Also there are differences in which accelerometer is used, so eventually I expect there to be several users of this dtsi. I've bought several second hand q8 formfactor tablets on the internet lately, when they arrive and I get around to work on them a second user may show up soon. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] ARM: dts: imx6dql-nitrogen6x: add touchscreen support
On Tue, Sep 08, 2015 at 04:49:20PM +0200, Philipp Zabel wrote:
> Am Dienstag, den 08.09.2015, 16:34 +0200 schrieb Gary Bisson:
> > This patch adds the different touchscreens that can be connected using
> > the displays available for this board.
> > http://boundarydevices.com/product-category/displays/
> >
> > Signed-off-by: Gary Bisson
> > ---
> > arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > index ad16dce..24b667d 100644
> > --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> > @@ -284,6 +284,22 @@
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_i2c3>;
> > status = "okay";
> > +
> > + egalax_ts@04 {
>
> I'd prefer to use generic names for the nodes, such as "touchscreen@04",
> and "touchscreen@38" below.
ePAPR actually says that the node name should be the general class of
the device, and recommending that it should be generic:
2.2.1.1 Node Name Requirements
...
The node-name shall start with a lower or uppercase character and should
describe the general class of device.
2.2.2 Generic Names Recommendation
The name of a node should be somewhat generic, reflecting the function of
the device and not its precise programming model. If appropriate, the name
should be one of the following choices: ...
It would be nice if more bindings followed this.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A
On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann wrote: > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote: >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis >> Designware PCIe IP >> and thus inherits all the common properties defined in designware-pcie.txt. >> >> Required properties: >> -- compatible: should contain the platform identifier such as >> "fsl,ls1021a-pcie" >> +- compatible: should contain the platform identifier such as >> "fsl,ls1021a-pcie", >> + "fsl,ls2080a-pcie". >> - reg: base addresses and lengths of the PCIe controller >> - interrupts: A list of interrupt outputs of the controller. Must contain an >>entry for each entry in the interrupt-names property. >> > > Are the two PCIe hosts mutually compatible? If they are, you should mandate > one of the strings as the base model for identification, with the additional > model being optional for identification of the specific SoC. It seems that controllers on these chips are not exactly the same. They will get different driver data by matching the compatible strings. Probably we could define a more generic compatible string, such as "fsl,layerscape-pcie" or "fsl,ls-pcie". > > It would also be good to add a string with the specific version number of the > designware PCIe block that is being used there. The binding has mentioned to reference the designware-pcie.txt. But it might be more clear to mention the designware compatible string "snps,dw-pcie" again in the compatible part. Currently there is no version number defined in the designware-pcie binding. It might be hard to get this information for some SoCs. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH v3] drivers: net: cpsw: Add support to drive gpios for ethernet to be functional
* Mugunthan V N [150907 02:50]:
> In DRA72x EVM, by default slave 1 is connected to the onboard
> phy, but slave 2 pins are also muxed with video input module
> which is controlled by pcf857x gpio and currently to select slave
> 0 to connect to phy gpio hogging is used, but with
> omap2plus_defconfig the pcf857x gpio is built as module. So when
> using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
> not set proper gpio state to connect slave 0 to phy as it is
> built as module and you do not see any errors for not setting
> gpio and just mentions dhcp reply not got.
>
> To solve this issue, introducing "mode-gpios" in DT when gpio
> based muxing is required. This will throw a warning when gpio
> get fails and returns probe defer. When gpio-pcf857x module is
> installed, cpsw probes again and ethernet becomes functional.
> Verified this on DRA72x with pcf as module and ramdisk.
>
> Signed-off-by: Mugunthan V N
Acked-by: Tony Lindgren
> ---
>
> Changes from v2:
> * Used mode-gpios, so that the driver is generic enough to handle
> multiple gpios
>
> This patch is tested on DRA72x, Logs [1] and pushed a branch [2]
>
> [1]: http://pastebin.ubuntu.com/12306224/
> [2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git
> cpsw-gpio-optional-v3
>
> ---
> Documentation/devicetree/bindings/net/cpsw.txt | 7 +++
> drivers/net/ethernet/ti/cpsw.c | 9 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
> b/Documentation/devicetree/bindings/net/cpsw.txt
> index a9df21a..676ecf6 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -30,6 +30,13 @@ Optional properties:
> - dual_emac : Specifies Switch to act as Dual EMAC
> - syscon : Phandle to the system control device node, which is
> the control module device of the am33x
> +- mode-gpios : Should be added if one/multiple gpio lines are
> + required to be driven so that cpsw data lines
> + can be connected to the phy via selective mux.
> + For example in dra72x-evm, pcf gpio has to be
> + driven low so that cpsw slave 0 and phy data
> + lines are connected via mux.
> +
>
> Slave Properties:
> Required properties:
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 8fc90f1..c670317 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
> void __iomem*ss_regs;
> struct resource *res, *ss_res;
> const struct of_device_id *of_id;
> + struct gpio_descs *mode;
> u32 slave_offset, sliver_offset, slave_size;
> int ret = 0, i;
> int irq;
> @@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev)
> goto clean_ndev_ret;
> }
>
> + mode = devm_gpiod_get_array_optional(&pdev->dev, "mode", GPIOD_OUT_LOW);
> + if (IS_ERR(mode)) {
> + ret = PTR_ERR(mode);
> + dev_err(&pdev->dev, "gpio request failed, ret %d\n", ret);
> + goto clean_ndev_ret;
> + }
> +
> /*
>* This may be required here for child devices.
>*/
> --
> 2.6.0.rc0.24.gec371ff
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 8, 2015 at 9:36 AM, Matt Porter wrote: > On Tue, Sep 01, 2015 at 01:24:17PM -0500, Rob Herring wrote: >> On Tue, Sep 1, 2015 at 1:03 PM, Tim Bird wrote: >> > On Tue, Sep 1, 2015 at 10:35 AM, Frank Rowand >> > wrote: >> >> On 9/1/2015 10:14 AM, Tim Bird wrote: >> >>> On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter >> >>> wrote: >> >> >> >> < snip > >> >> >> >> But to answer your question, if we get a format I'll do >> conversions and hope I'm not alone. >> >>> >> >>> I'm sure others will help out. I will, and I'm pretty sure we can get >> >>> some conversion sprints set up at conferences (I know I can set aside >> >>> some time or resources at ELC in the spring - it might be too late for >> >>> ELCE in October to set up a scheduled block of time, but we can start >> >>> getting the word out.) As I said in my other e-mail, one doesn't have >> >>> to be a kernel coder to do this, and the conversions should be pretty >> >>> straight-forward. >> >>> -- Tim >> >>> >> >> >> >> A conversion sprint at ELCE sounds like a good idea if we can find a >> >> good time to schedule it. I can help, so there will be at least two >> >> of us who can help people as they encounter issues. >> > >> > Even if we don't find a block of time, we can do something like >> > announce a "contest", ask people to do something in their spare time, >> > and find some way to get them a raffle ticket if they submit a patch >> > with a conversion. Then hold an extra prize drawing during the >> > closing session, with just those raffle tickets, and give someone a >> > nice award for contributing. Of course, there's always the adage that >> > you should be careful what you measure and reward... We don't want a >> > flood of crappy conversions, with a time constraint on the review. >> > I'll think some more about this. An alternative would be to have a >> > contest announced ahead of the event, with enough time for people to >> > submit and get reviewed. >> >> Sounds like a review nightmare. That's another reason why as much >> automated conversion we can do, the better. > > I don't want to discount the value of interested people getting together > f2f to review these and potentially clean them up for submission. That > depends on what we thinking is the minimal "in progress" conversion > that can be place upstream. i.e. is it simply compatible strings > autoconverted to tags and the entire current document in comments? That is sufficient for me (I reserve the right to change my mind). Logistically, it needs to be a script that can be run before/during the merge window and perhaps again after. I'd guess the long pole here is how we validate the .yaml files. >> > By the way - I presume the new docs will replace the existing ones, >> > but I could imagine wanting to have them live side-by-side >> > temporarily. Any thoughts on this? Will file name or location >> > changes be allowed during the conversion? >> >> I proposed some ideas earlier in the thread. Either we can have both >> side by side or do a mass conversion to YAML making the existing doc a >> comment (add # prefix). >> > > Were you thinking that this automated conversion would be sufficient > for an initial commit? I'm not sure if I misunderstood in your separate > comments and was looking at this as something that would be hand edited > to move the existing doc (# prefix) into description tags where > appropriate. Yes, I think it is more important to have infrastructure in place to enable others than how much is converted initially. Certainly any changes based on existing docs will have to be manual, but we may be able to do multiple passes of automated conversions. Sharing any conversion scripts is important to enable others for that as well. >> Any renames/moving should be separate (there's some clean-up I'd like >> to there as well). Exact rules depend on the approach, but we need to >> be able to tell which bindings conversions are not started, in >> progress, or complete. > > If we add .yaml in place we can identify what's in progress by the fact > that a .yaml exists with the same filename and then based on which > tags have been populated (such as type: and constraints: not yet > populated) then we know the state. You mean keeping the .txt and .yaml until done? If we are copying in the current doc, then I'd rather not do that. I don't think looking at the tags will work as it would be hard to distinguish incomplete from done. However, we could simply have an "in-progress" tag that is removed when done (might as well take advantage of our new found structured docs). Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/16] mtd: mtdcore: fix initcall level
Am 04.09.2015 um 06:00 schrieb Alexander Holler: Am 02.09.2015 um 07:34 schrieb Alexander Holler: Am 01.09.2015 um 23:19 schrieb Brian Norris: Hi Alexander, No judgment here for the rest of this series, but for this patch: On Wed, Aug 26, 2015 at 02:28:27PM +0200, Alexander Holler wrote: The mtd-core has to be initialized before other dependent mtd-drivers, otherwise a crash might occur. Currently mtd_init() is called in the initcall-level device, which is the same level where most mtd-drivers will end up. By luck this seemed to have been called most of the time before other mtd-drivers without having been explicitly enforced. I can't really speak for the original authors, but it does not appear to be entirely "by luck." Link order was one of the de facto ways to get this ordering (though it's not really a great one), and mtdcore was always linked first within the drivers/mtd/ directory structure. But that's just background, I think this is worth fixing anyway. It could, for instance, become a problem if drivers are located outside drivers/mtd/; I see random board files in arch/ that register with MTD, and I'm actually not sure how they have never tripped on this. As I've just had a look at my patches in order to clean up the patch for parallel initialization (to post it here too): drivers/mtd/ofparts.c has the same problem. In order to let the NAND-driver see the partitions defined in the DT I had to move this into another initcall level (fs sync) too. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
On Tue, Sep 08, 2015 at 12:10:02PM -0700, Greg KH wrote:
> On Tue, Sep 08, 2015 at 08:30:13AM -0700, Guenter Roeck wrote:
> > Emilio,
> >
> > On Tue, Sep 08, 2015 at 09:07:44AM -0300, Emilio López wrote:
> > > According to the sysfs header file:
> > >
> > > "The returned value will replace static permissions defined in
> > > struct attribute or struct bin_attribute."
> > >
> > > but this isn't the case, as is_visible is only called on
> > > struct attribute only. This patch adds the code paths required
> > > to support is_visible() on binary attributes.
> > >
> > > Signed-off-by: Emilio López
> > > ---
> > > fs/sysfs/group.c | 22 ++
> > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > > index 39a0199..eb6996a 100644
> > > --- a/fs/sysfs/group.c
> > > +++ b/fs/sysfs/group.c
> > > @@ -37,10 +37,10 @@ static int create_files(struct kernfs_node *parent,
> > > struct kobject *kobj,
> > > {
> > > struct attribute *const *attr;
> > > struct bin_attribute *const *bin_attr;
> > > - int error = 0, i;
> > > + int error = 0, i = 0;
> > >
> > > if (grp->attrs) {
> > > - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> > > + for (attr = grp->attrs; *attr && !error; i++, attr++) {
> > > umode_t mode = (*attr)->mode;
> > >
> > > /*
> > > @@ -73,13 +73,27 @@ static int create_files(struct kernfs_node *parent,
> > > struct kobject *kobj,
> > > }
> > >
> > > if (grp->bin_attrs) {
> > > - for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
> > > + for (bin_attr = grp->bin_attrs; *bin_attr; i++, bin_attr++) {
> > > + umode_t mode = (*bin_attr)->attr.mode;
> > > +
> > > if (update)
> > > kernfs_remove_by_name(parent,
> > > (*bin_attr)->attr.name);
> > > + if (grp->is_visible) {
> > > + mode = grp->is_visible(kobj,
> > > +&(*bin_attr)->attr, i);
> >
> > With this, if 'n' is the number of non-binary attributes,
> >
> > for i < n:
> > The index passed to is_visible points to a non-binary attribute.
> > for i >= n:
> > The index passed to is_visible points to the (index - n)th binary
> > attribute.
> >
> > Unless I am missing something, this is not explained anywhere, but it is
> > not entirely trivial to understand. I think it should be documented.
>
> I agree, make i the number of the bin attribute and that should solve
> this issue.
>
No, that would conflict with the "normal" use of is_visible for non-binary
attributes, and make the index all but useless, since the is_visible function
would have to search through all the attributes anyway to figure out which one
is being checked.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] clk: bcm2835: Move under bcm/ with other Broadcom SoC clk drivers.
On 09/07, Lee Jones wrote: > On Sun, 06 Sep 2015, Eric Anholt wrote: > > > clk-bcm2835.c predates the drivers under bcm/, but all the new BCM > > drivers are going in there so let's follow them. > > > > Signed-off-by: Eric Anholt > > --- > > drivers/clk/Makefile | 1 - > > drivers/clk/bcm/Makefile | 1 + > > drivers/clk/bcm/clk-bcm2835.c | 60 > > +++ > > drivers/clk/clk-bcm2835.c | 60 > > --- > > You need to resubmit this with `git format-patch -M`. You don't have to. It would have been nice if it was formatted with -M so that review is easier, but we can always apply the patch and then check the result to make sure things look the same. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] fbdev: ssd1307fb: alphabetize headers
From: Olliver Schinagl This patch sorts the headers on ssd1307fb driver. Signed-off-by: Olliver Schinagl --- drivers/video/fbdev/ssd1307fb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c index 3e153c0..339615c 100644 --- a/drivers/video/fbdev/ssd1307fb.c +++ b/drivers/video/fbdev/ssd1307fb.c @@ -6,16 +6,16 @@ * Licensed under the GPLv2 or later. */ -#include #include -#include -#include +#include #include -#include +#include +#include +#include #include #include #include -#include +#include #define SSD1307FB_DATA 0x40 #define SSD1307FB_COMMAND 0x80 -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] fbdev: ssd1307fb: add ssd1309 support
The ssd1307fb driver supports a lot of chips from the ssd130xfb series.
This patch adds the ssd1309 chip, a 128x64 OLED driver chip. It is very
similar to the other chips and only has some definitions added to
support it.
Signed-off-by: Olliver Schinagl
---
Documentation/devicetree/bindings/video/ssd1307fb.txt | 3 ++-
drivers/video/fbdev/ssd1307fb.c | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt
b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index d1be78d..eb31ed4 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -2,7 +2,8 @@
Required properties:
- compatible: Should be "solomon,fb-". The only supported bus for
-now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
+now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and
+ssd1309.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 339615c..8fc7960 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -495,6 +495,12 @@ static struct ssd1307fb_deviceinfo
ssd1307fb_ssd1307_deviceinfo = {
.need_pwm = 1,
};
+static struct ssd1307fb_deviceinfo ssd1307fb_ssd1309_deviceinfo = {
+ .default_vcomh = 0x34,
+ .default_dclk_div = 1,
+ .default_dclk_frq = 10,
+};
+
static const struct of_device_id ssd1307fb_of_match[] = {
{
.compatible = "solomon,ssd1305fb-i2c",
@@ -508,6 +514,10 @@ static const struct of_device_id ssd1307fb_of_match[] = {
.compatible = "solomon,ssd1307fb-i2c",
.data = (void *)&ssd1307fb_ssd1307_deviceinfo,
},
+ {
+ .compatible = "solomon,ssd1309fb-i2c",
+ .data = (void *)&ssd1307fb_ssd1309_deviceinfo,
+ },
{},
};
MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
@@ -708,6 +718,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
{ "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
+ { "ssd1309fb", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] SSD1307fb updates
Having a few ssd1309 128x64 OLED displays laying around, I added support for it
to the existing 1307fb driver. While doing this I noticed the headers where out
of order so I fixed those as well.
For this specific display, the following can be used in a i2c node for example.
ssd1309: oled@3c {
compatible = "solomon,ssd1309fb-i2c";
pinctrl-names = "default";
pinctrl-0 = <&oled_pins>;
reg = <0x3c>;
reset-gpios = <&pio 8 13 GPIO_ACTIVE_HIGH>;
solomon,width = <128>;
solomon,height = <64>;
solomon,com-invdir;
solomon,page-offset = <0>;
solomon,prechargep1 = <2>;
solomon,prechargep2 = <8>;
};
Olliver Schinagl (2):
fbdev: ssd1307fb: alphabetize headers
fbdev: ssd1307fb: add ssd1309 support
.../devicetree/bindings/video/ssd1307fb.txt | 3 ++-
drivers/video/fbdev/ssd1307fb.c | 21 -
2 files changed, 18 insertions(+), 6 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes
On Tue, Sep 08, 2015 at 08:30:13AM -0700, Guenter Roeck wrote:
> Emilio,
>
> On Tue, Sep 08, 2015 at 09:07:44AM -0300, Emilio López wrote:
> > According to the sysfs header file:
> >
> > "The returned value will replace static permissions defined in
> > struct attribute or struct bin_attribute."
> >
> > but this isn't the case, as is_visible is only called on
> > struct attribute only. This patch adds the code paths required
> > to support is_visible() on binary attributes.
> >
> > Signed-off-by: Emilio López
> > ---
> > fs/sysfs/group.c | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> > index 39a0199..eb6996a 100644
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@ -37,10 +37,10 @@ static int create_files(struct kernfs_node *parent,
> > struct kobject *kobj,
> > {
> > struct attribute *const *attr;
> > struct bin_attribute *const *bin_attr;
> > - int error = 0, i;
> > + int error = 0, i = 0;
> >
> > if (grp->attrs) {
> > - for (i = 0, attr = grp->attrs; *attr && !error; i++, attr++) {
> > + for (attr = grp->attrs; *attr && !error; i++, attr++) {
> > umode_t mode = (*attr)->mode;
> >
> > /*
> > @@ -73,13 +73,27 @@ static int create_files(struct kernfs_node *parent,
> > struct kobject *kobj,
> > }
> >
> > if (grp->bin_attrs) {
> > - for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
> > + for (bin_attr = grp->bin_attrs; *bin_attr; i++, bin_attr++) {
> > + umode_t mode = (*bin_attr)->attr.mode;
> > +
> > if (update)
> > kernfs_remove_by_name(parent,
> > (*bin_attr)->attr.name);
> > + if (grp->is_visible) {
> > + mode = grp->is_visible(kobj,
> > + &(*bin_attr)->attr, i);
>
> With this, if 'n' is the number of non-binary attributes,
>
> for i < n:
> The index passed to is_visible points to a non-binary attribute.
> for i >= n:
> The index passed to is_visible points to the (index - n)th binary
> attribute.
>
> Unless I am missing something, this is not explained anywhere, but it is
> not entirely trivial to understand. I think it should be documented.
I agree, make i the number of the bin attribute and that should solve
this issue.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.
From: David Daney
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.
Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
messages by moving the printing code into of_irq_parse_pci(), and only
emitting the message for cases where PCI_INTERRUPT_PIN == 0 is not the
cause for an early exit.
Signed-off-by: David Daney
---
Changes in v2: Move the print function in to of_irq_parse_pci() at a
common error exit point (as suggested by Frank Rowand).
drivers/of/of_pci_irq.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 1710d9d..0be8b65 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -38,8 +38,8 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct
of_phandle_args *out_irq
*/
rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
if (rc != 0)
- return rc;
- /* No pin, exit */
+ goto err;
+ /* No pin, exit with no error message. */
if (pin == 0)
return -ENODEV;
@@ -53,8 +53,10 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct
of_phandle_args *out_irq
ppnode = pci_bus_to_OF_node(pdev->bus);
/* No node for host bridge ? give up */
- if (ppnode == NULL)
- return -EINVAL;
+ if (ppnode == NULL) {
+ rc = -EINVAL;
+ goto err;
+ }
} else {
/* We found a P2P bridge, check if it has a node */
ppnode = pci_device_to_OF_node(ppdev);
@@ -87,6 +89,9 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct
of_phandle_args *out_irq
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);
return of_irq_parse_raw(laddr, out_irq);
+err:
+ dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
+ return rc;
}
EXPORT_SYMBOL_GPL(of_irq_parse_pci);
@@ -105,10 +110,8 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8
slot, u8 pin)
int ret;
ret = of_irq_parse_pci(dev, &oirq);
- if (ret) {
- dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n",
ret);
+ if (ret)
return 0; /* Proper return code 0 == NO_IRQ */
- }
return irq_create_of_mapping(&oirq);
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote:
> > > */
> > > - if (!buf || !buf[0])
> > > - if (IS_ENABLED(CONFIG_OF_FLATTREE))
> > > + if (!buf || !buf[0]) {
> > > + if (!acpi_disabled)
> >
> > How do we know for sure that "acpi" has been parsed before "earlycon"?
>
> Because "arch" comes before "drivers" in kernel image link order.
> *twitch*
> Yes, not the best argument ever.
>
I don't think that matters. Things are parsed in order they are
found on cmdline (except for early vs late distinction).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2 v3 ] watchdog: driver for BCM7038 and newer chips.
This driver is for a watchdog block contained in all Broadcom Set-top Box chips since BCM7038. BCM7038 was made public during the 2004 CES, and since then, many chips use this watchdog block including some cable modem chips. Changes since v2: Added clk_disable_unprepare if watchdog fails to register. Changes since v1: Removed clock-frequency because it brought unnecessary complexity to the driver. Renamed a few variables. Patch 1: watchdog device tree binding documentation Patch 2: watchdog driver Justin Chen (2): watchdog: bcm7038: add device tree binding documentation watchdog: Watchdog driver for Broadcom Set-Top Box .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 ++ drivers/watchdog/Kconfig | 8 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bcm7038_wdt.c | 237 + 4 files changed, 265 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt create mode 100644 drivers/watchdog/bcm7038_wdt.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v3] watchdog: Watchdog driver for Broadcom Set-Top Box
Watchdog driver for Broadcom 7038 and newer chips.
Signed-off-by: Justin Chen
Reviewed-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 8 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bcm7038_wdt.c | 237 +
3 files changed, 246 insertions(+)
create mode 100644 drivers/watchdog/bcm7038_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 55c4b5b..b9b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1292,6 +1292,14 @@ config BCM_KONA_WDT_DEBUG
If in doubt, say 'N'.
+config BCM7038_WDT
+ tristate "BCM7038 Watchdog"
+ select WATCHDOG_CORE
+ help
+Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
+
+Say 'Y or 'M' here to enable the driver.
+
config IMGPDC_WDT
tristate "Imagination Technologies PDC Watchdog Timer"
depends on HAS_IOMEM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 59ea9a1..65d4169 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
+obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
new file mode 100644
index 000..4245b65
--- /dev/null
+++ b/drivers/watchdog/bcm7038_wdt.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define WDT_START_10xff00
+#define WDT_START_20x00ff
+#define WDT_STOP_1 0xee00
+#define WDT_STOP_2 0x00ee
+
+#define WDT_TIMEOUT_REG0x0
+#define WDT_CMD_REG0x4
+
+#define WDT_MIN_TIMEOUT1 /* seconds */
+#define WDT_DEFAULT_TIMEOUT30 /* seconds */
+#define WDT_DEFAULT_RATE 2700
+
+struct bcm7038_watchdog {
+ void __iomem*base;
+ struct watchdog_device wdd;
+ u32 rate;
+ struct clk *clk;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 timeout;
+
+ timeout = wdt->rate * wdog->timeout;
+
+ writel(timeout, wdt->base + WDT_TIMEOUT_REG);
+}
+
+static int bcm7038_wdt_ping(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_START_1, wdt->base + WDT_CMD_REG);
+ writel(WDT_START_2, wdt->base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_start(struct watchdog_device *wdog)
+{
+ bcm7038_wdt_set_timeout_reg(wdog);
+ bcm7038_wdt_ping(wdog);
+
+ return 0;
+}
+
+static int bcm7038_wdt_stop(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+
+ writel(WDT_STOP_1, wdt->base + WDT_CMD_REG);
+ writel(WDT_STOP_2, wdt->base + WDT_CMD_REG);
+
+ return 0;
+}
+
+static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int t)
+{
+ /* Can't modify timeout value if watchdog timer is running */
+ bcm7038_wdt_stop(wdog);
+ wdog->timeout = t;
+ bcm7038_wdt_start(wdog);
+
+ return 0;
+}
+
+static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
+{
+ struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
+ u32 time_left;
+
+ time_left = readl(wdt->base + WDT_CMD_REG);
+
+ return time_left / wdt->rate;
+}
+
+static struct watchdog_info bcm7038_wdt_info = {
+ .identity = "Broadcom BCM7038 Watchdog Timer",
+ .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
+ WDIOF_MAGICCLOSE
+};
+
+static struct watchdog_ops bcm7038_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = bcm7038_wdt_start,
+ .stop = bcm7038_wdt_stop,
+ .set_timeout= bcm7038_wdt_set_timeout,
+ .get_timeleft = bcm7038_wdt_get_timeleft,
+};
+
+static int bcm7038_wdt_probe(struct platform_device *p
[PATCH 1/2 v3] watchdog: bcm7038: add device tree binding documentation
Add device tree binding documentation for the watchdog hardware block
on bcm7038 and newer SoCs.
Signed-off-by: Justin Chen
Acked-by: Guenter Roeck
---
.../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
new file mode 100644
index 000..39e5cf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
@@ -0,0 +1,19 @@
+BCM7038 Watchdog timer
+
+Required properties:
+
+- compatible : should be "brcm,bcm7038-wdt"
+- reg : Specifies base physical address and size of the registers.
+
+Optional properties:
+
+- clocks: The clock running the watchdog. If no clock is found the
+ driver will default to 2700 HZ.
+
+Example:
+
+watchdog {
+ compatible = "brcm,bcm7038-wdt";
+ clocks = <&upg_fixed>;
+ reg = <0xf040a7e8 0x16>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote:
> On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote:
> > On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote:
> > > The ACPI DBG2 table defines a debug console. Add support for parsing it
> > > and using it to select earlycon destination when no arguments provided.
> > >
> > > Signed-off-by: Leif Lindholm
> > > ---
> > > arch/arm64/kernel/acpi.c | 2 +
> > > drivers/acpi/Makefile | 1 +
> > > drivers/acpi/console.c| 103
> > > ++
> > > drivers/of/fdt.c | 2 +-
> > > drivers/tty/serial/earlycon.c | 16 ---
> > > include/linux/acpi.h | 4 ++
> > > include/linux/serial_core.h | 9 ++--
> > > 7 files changed, 126 insertions(+), 11 deletions(-)
> > > create mode 100644 drivers/acpi/console.c
> > >
> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > index b9a5623..be7600a 100644
> > > --- a/arch/arm64/kernel/acpi.c
> > > +++ b/arch/arm64/kernel/acpi.c
> > > @@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
> > > if (!param_acpi_force)
> > > disable_acpi();
> > > }
> > > +
> > > + acpi_early_console_probe();
> > > }
> > >
> > > void __init acpi_gic_init(void)
> > > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > > index b5e7cd8..a89587d 100644
> > > --- a/drivers/acpi/Makefile
> > > +++ b/drivers/acpi/Makefile
> > > @@ -10,6 +10,7 @@ ccflags-$(CONFIG_ACPI_DEBUG)+= -DACPI_DEBUG_OUTPUT
> > > #
> > > obj-y+= tables.o
> > > obj-$(CONFIG_X86)+= blacklist.o
> > > +obj-y+= console.o
> >
> > obj-$(CONFIG_SERIAL_EARLYCON) += console.o
> >
> > to eliminate whole-file #ifdef
>
> Yes, that makes more sense for this patch standalone, but I felt it
> would be a bit weird to add the conditionality here only to delete it
> in the subsequent patch. I don't feel strongly about it.
OIC. I didn't read ahead far enough.
>
> > >
> > > #
> > > # ACPI Core Subsystem (Interpreter)
> > > diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> > > new file mode 100644
> > > index 000..a985890
> > > --- /dev/null
> > > +++ b/drivers/acpi/console.c
> > > @@ -0,0 +1,103 @@
> > > +/*
> > > + * Copyright (c) 2012, Intel Corporation
> > > + * Copyright (c) 2015, Linaro Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + *
> > > + */
> > > +
> > > +#define DEBUG
> > > +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
> > > +
> > > +#ifdef CONFIG_SERIAL_EARLYCON
> > > +static int use_earlycon __initdata;
> > > +static int __init setup_acpi_earlycon(char *buf)
> > > +{
> > > + if (!buf)
> > > + use_earlycon = 1;
> > > +
> > > + return 0;
> > > +}
> > > +early_param("earlycon", setup_acpi_earlycon);
> > > +
> > > +extern struct earlycon_id __earlycon_table[];
> > > +
> > > +static __initdata struct {
> > > + int id;
> > > + const char *name;
> > > +} subtypes[] = {
> > > + {0, "uart8250"},
> > > + {1, "uart8250"},
> > > + {2, NULL},
> > > + {3, "pl011"},
> > > +};
> >
> > Instead of having a table here, why not have an ACPI_EARLYCON_DECLARE()
> > where individual drivers can provide an id similar to OF_EARLYCON_DECLARE()
> > providing compatible strings?
>
> The IDs are defined by the DBG2 specification, so it felt more
> natural to encapsulate it here. However, a comment to that effect
> would be useful. Or would you still prefer
> ACPI_EARLYCON_DECLARE(0, uart8250)
> ACPI_EARLYCON_DECLARE(1, uart8250)
> ...
> ?
The idea is that the driver itself is only place that needs to handle
a new uart type being supported rather than two places.
>
> > > +
> > > +static int __init acpi_setup_earlycon(unsigned long addr, const char
> > > *driver)
> > > +{
> > > + const struct earlycon_id *match;
> > > +
> > > + for (match = __earlycon_table; match->name[0]; match++)
> > > + if (strcmp(driver, match->name) == 0)
> > > + return setup_earlycon_driver(addr, match->setup);
> > > +
> > > + return -ENODEV;
> > > +}
> > > +
> > > +static int __init acpi_parse_dbg2(struct acpi_table_header *table)
> > > +{
> > > + struct acpi_table_dbg2 *dbg2;
> > > + struct acpi_dbg2_device *entry;
> > > + void *tbl_end;
> > > +
> > > + dbg2 = (struct acpi_table_dbg2 *)table;
> > > + if (!dbg2) {
> > > + pr_debug("DBG2 not present.\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + tbl_end = (void *)table + table->length;
> > > +
> > > + entry = (struct acpi_dbg2_device *)((void *)dbg2 + dbg2->info_offset);
> > > +
> > > + while (((void *)entry) + sizeof(struct acpi_dbg2_device)
Re: [RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
On Sun, Aug 30, 2015 at 03:04:33PM -0700, Frank Rowand wrote: > On 8/27/2015 10:23 PM, Matt Porter wrote: > > Documentation explaining the syntax and format of the YAML-based DT binding > > documentation. > > > > Signed-off-by: Matt Porter > > --- > > .../devicetree/bindings/dt-binding-format.txt | 106 > > + > > 1 file changed, 106 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt > > > > diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt > > b/Documentation/devicetree/bindings/dt-binding-format.txt > > new file mode 100644 > > index 000..f9acc22 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dt-binding-format.txt > > @@ -0,0 +1,106 @@ > > +-- > > +Device Tree Binding Format > > +-- > > + > > +Background > > +-- > > + > > +DT bindings historically were written as text in prose format which > > +led to issues in usability of that source documentation. Some of > > +these issues include the need to programmatically process binding > > +source documentation to do DTS validation, perform mass updates to > > +format/style, and to generate publishable documentation in HTML or > > +PDF form. > > + > > +Overview > > + > > + > > +The DT binding format is based on the YAML text markup language. > > +Although there are many text markup options available, YAML > > +fulfills all requirements considered for a DT binding source format > > +which include: > > + > > +1) Must be human readable > > +2) Must be easily translated to other data formats (XML, JSON, etc). > > +3) Must have sufficient tools and libraries to enable developers to > > + build new tools for DT binding processing > > +4) Must have a complete spec to refer to syntax > > + > > +YAML is documentated in the specification found at > > +http://www.yaml.org/spec/1.2/spec.html > > + > > +The required YAML DT binding tag format and syntax are defined in > > +the following sections. > > + > > +YAML DT Binding Syntax > > +-- > > + > > +* Lines starting with "#" are comments and not part of the binding itself > > +* "%YAML 1.2" starts a file, indicating the version of YAML in use > > +* "---" starts a binding document > > +* "..." ends a binding document > > +* Multiple binding documents may exist in a single file > > +* Tabs are not permitted > > +* Scope is denoted by indentation of two spaces > > +* Key value pairs are denoted by "key: value" > > +* Sequences are denoted by "- " > > +* Scalar values may convert newlines to spaces and preserve blank > > + lines for long description formatting using ">" > > +* Scalar values may escape all reserved characters and preserve > > + newlines by using "|" to denote literal style > > + > > +For additional information on YAML syntax, refer to the specification > > +at http://www.yaml.org/spec/1.2/spec.html > > + > > +YAML DT Binding Format > > +-- > > + > > +The following YAML types are supported in the DT binding format: > > + > > +* [R] id: unique identifier in property form (e.g. skel-device) > > + > > +* [R] title: title of the binding > > + > > +* [O] maintainer: sequence of maintainers > > + [R] name: name and email of maintainer or mailing list in RFC822 > > +form. > > + > > +* [O] description: full description of the binding > > + > > +* [O] compatible: sequence of valid compatible descriptors > > + [R] name: the compatible string surrounded in double quotes > > + [O] deprecated: a deprecated compatible string surrounded in > > + double quotes > > + [O] description: description of the compatible string > > + > > +* [O] required: sequence of required properties: > > + [R] name: name of the property surrounded in double quotes > > + [R] description: description of the property > > + [O] reference: optional reference to a binding id > > + > > +* [O] optional: sequence of optional properties: > > + [R] name: name of the property surrounded in double quotes > > + [R] description: description of the property > > + [O] reference: optional reference to a binding id > > + > > +* [O] deprecated: sequence of deprecated properties: > > + [R] name: name of the property surrounded in double quotes > > + [R] description: description of the property > > + [O] reference: optional reference to a binding id > > I commented in reply to patch 0 that we should think through how > this structure will support adding new features as the next step > after converting existing bindings. > > The specific case I started thinking about was the distinction between > required, optional, required-if, and optional-if. A property might > be required in all cases, optional in all cases, required in some > specified cases, and/or optional in some specified cases. So a > property could be both "required-if" and "optional-if". Or it
Re: _DSD standardization note (WAS: Re: [PATCH 2/2] net, thunder, bgx: Add support for ACPI binding.)
On 09/05/2015 01:00 PM, Jon Masters wrote:
Following up on this thread after finally seeing it...figured I would
send something just for the archive mainly (we discussed this in person
recently at a few different events and I think are aligned already).
On 08/07/2015 08:28 PM, Rafael J. Wysocki wrote:
Hi David,
On Sat, Aug 8, 2015 at 2:11 AM, David Daney wrote:
On 08/07/2015 05:05 PM, Rafael J. Wysocki wrote:
[cut]
It is actually useful to people as far as I can say.
Also, if somebody is going to use properties with ACPI, why whould
they use a different set of properties with DT?
Generally speaking, if there's a net new thing to handle, there is of
course no particular problem with using DT as an inspiration, but we
need to be conscious of the fact that Linux isn't the only Operating
System that may need to support these bindings, so the correct thing (as
stated by many of you, and below, and in person also recently - so we
are aligned) is to get this (the MAC address binding for _DSD in ACPI)
standardized properly through UEFI where everyone who has a vest OS
interest beyond Linux can also have their own involvement as well. As
discussed, that doesn't make it part of ACPI6.0, just a binding.
FWIW I made a decision on the Red Hat end that in our guidelines to
partners for ARM RHEL(SA - Server for ARM) builds we would not generally
endorse any use of _DSD, with the exception of the MAC address binding
being discussed here. In that case, I realized I had not been fully
prescriptive enough with the vendors building early hw in that I should
have realized this would happen and have required that they do this the
right way. MAC IP should be more sophisticated such that it can handle
being reset even after the firmware has loaded its MAC address(es).
Platform flash storage separate from UEFI variable storage (which is
being abused to contain too much now that DXE drivers then load into the
ACPI tables prior to exiting Boot Services, etc.) should contain the
actual MAC address(es), as it is done on other arches, and it should not
be necessary to communicate this via ACPI tables to begin with (that's a
cost saving embedded concept that should not happen on server systems in
the general case). I have already had several unannounced future designs
adjusted in light of this _DSD usage.
In the case of providing MAC address information (only) by _DSD, I
connected the initial ARMv8 SoC silicon vendors who needed to use such a
hack to ensure they were using the same properties, and will followup
off list to ensure Cavium are looped into that. But, we do need to get
the _DSD property for MAC address provision standardized through UEFI
properly as an official binding rather than just a link on the website,
and then we need to be extremely careful not to grow any further
dependence upon _DSD elsewhere. Generally, if you're using that approach
on a server system (other than for this MAC case), your firmware or
design (or both) need to be modified to not use _DSD.
I think we need to be cognizant of the fact that ARMv8 SoCs do contain,
and in the future will still contain, many different hardware bus
interface devices. These include I2C, MDIO, GPIO, xMII (x in {,SG,RGM,
etc} network MAC interfaces). In the context of network interfaces
these are often used in conjunction with stand-alone PHY devices.
A network driver on such a system must know several things that cannot
be probed, and thus must be communicated by the firmware:
- PHY type/model-number.
- PHY management channel (MDIO/I2C + management bus address)
- PHY interrupt connection, if any, (Often a GPIO pin).
- SFP eeprom location (Which I2C bus is it on).
On x86 systems, all those things were placed on a PCI NIC, and the
configuration could be identified in a stand alone manner by the NIC
driver, so everything was simple.
For SoC based systems, I don't see a better alternative than to expose
the topology via firmware tables. In the case of OF device-tree, this
is done in a standard manner with "phy-handle" and "interrupts"
properties utilizing phandle links to traverse branches of the device tree.
I am not an ACPI guru, so I don't know for certain the best way to
express this in ACPI, but it seems like _DSD may have to be involved.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote:
> On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote:
> > The ACPI DBG2 table defines a debug console. Add support for parsing it
> > and using it to select earlycon destination when no arguments provided.
> >
> > Signed-off-by: Leif Lindholm
> > ---
> > arch/arm64/kernel/acpi.c | 2 +
> > drivers/acpi/Makefile | 1 +
> > drivers/acpi/console.c| 103
> > ++
> > drivers/of/fdt.c | 2 +-
> > drivers/tty/serial/earlycon.c | 16 ---
> > include/linux/acpi.h | 4 ++
> > include/linux/serial_core.h | 9 ++--
> > 7 files changed, 126 insertions(+), 11 deletions(-)
> > create mode 100644 drivers/acpi/console.c
> >
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index b9a5623..be7600a 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
> > if (!param_acpi_force)
> > disable_acpi();
> > }
> > +
> > + acpi_early_console_probe();
> > }
> >
> > void __init acpi_gic_init(void)
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > index b5e7cd8..a89587d 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -10,6 +10,7 @@ ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
> > #
> > obj-y += tables.o
> > obj-$(CONFIG_X86) += blacklist.o
> > +obj-y += console.o
>
> obj-$(CONFIG_SERIAL_EARLYCON) += console.o
>
> to eliminate whole-file #ifdef
Yes, that makes more sense for this patch standalone, but I felt it
would be a bit weird to add the conditionality here only to delete it
in the subsequent patch. I don't feel strongly about it.
> >
> > #
> > # ACPI Core Subsystem (Interpreter)
> > diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> > new file mode 100644
> > index 000..a985890
> > --- /dev/null
> > +++ b/drivers/acpi/console.c
> > @@ -0,0 +1,103 @@
> > +/*
> > + * Copyright (c) 2012, Intel Corporation
> > + * Copyright (c) 2015, Linaro Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#define DEBUG
> > +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
> > +
> > +#ifdef CONFIG_SERIAL_EARLYCON
> > +static int use_earlycon __initdata;
> > +static int __init setup_acpi_earlycon(char *buf)
> > +{
> > + if (!buf)
> > + use_earlycon = 1;
> > +
> > + return 0;
> > +}
> > +early_param("earlycon", setup_acpi_earlycon);
> > +
> > +extern struct earlycon_id __earlycon_table[];
> > +
> > +static __initdata struct {
> > + int id;
> > + const char *name;
> > +} subtypes[] = {
> > + {0, "uart8250"},
> > + {1, "uart8250"},
> > + {2, NULL},
> > + {3, "pl011"},
> > +};
>
> Instead of having a table here, why not have an ACPI_EARLYCON_DECLARE()
> where individual drivers can provide an id similar to OF_EARLYCON_DECLARE()
> providing compatible strings?
The IDs are defined by the DBG2 specification, so it felt more
natural to encapsulate it here. However, a comment to that effect
would be useful. Or would you still prefer
ACPI_EARLYCON_DECLARE(0, uart8250)
ACPI_EARLYCON_DECLARE(1, uart8250)
...
?
> > +
> > +static int __init acpi_setup_earlycon(unsigned long addr, const char
> > *driver)
> > +{
> > + const struct earlycon_id *match;
> > +
> > + for (match = __earlycon_table; match->name[0]; match++)
> > + if (strcmp(driver, match->name) == 0)
> > + return setup_earlycon_driver(addr, match->setup);
> > +
> > + return -ENODEV;
> > +}
> > +
> > +static int __init acpi_parse_dbg2(struct acpi_table_header *table)
> > +{
> > + struct acpi_table_dbg2 *dbg2;
> > + struct acpi_dbg2_device *entry;
> > + void *tbl_end;
> > +
> > + dbg2 = (struct acpi_table_dbg2 *)table;
> > + if (!dbg2) {
> > + pr_debug("DBG2 not present.\n");
> > + return -ENODEV;
> > + }
> > +
> > + tbl_end = (void *)table + table->length;
> > +
> > + entry = (struct acpi_dbg2_device *)((void *)dbg2 + dbg2->info_offset);
> > +
> > + while (((void *)entry) + sizeof(struct acpi_dbg2_device) < tbl_end) {
> > + struct acpi_generic_address *addr;
> > +
> > + if (entry->revision != 0) {
> > + pr_debug("DBG2 revision %d not supported.\n",
> > +entry->revision);
> > + return -ENODEV;
> > + }
> > +
> > + addr = (void *)entry + entry->base_address_offset;
> > +
> > + pr_debug("DBG2 PROBE - console (%04x:%04x).\n",
> > +
Re: [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, Sep 08, 2015 at 02:09:51PM +0100, Mark Rutland wrote:
> On Tue, Sep 08, 2015 at 01:43:35PM +0100, Leif Lindholm wrote:
> > The ACPI DBG2 table defines a debug console. Add support for parsing it
> > and using it to select earlycon destination when no arguments provided.
> >
> > Signed-off-by: Leif Lindholm
>
> [...]
>
> > diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> > new file mode 100644
> > index 000..a985890
> > --- /dev/null
> > +++ b/drivers/acpi/console.c
> > @@ -0,0 +1,103 @@
> > +/*
> > + * Copyright (c) 2012, Intel Corporation
> > + * Copyright (c) 2015, Linaro Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#define DEBUG
>
> Why?
Kept around from Lv Zheng's 2012 set. Will drop.
> > +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
>
> Use ARRAY_SIZE (from kernel.h).
I was sure there was something like that, but my grep-fu failed me.
Will fix.
> > +
> > +#ifdef CONFIG_SERIAL_EARLYCON
> > +static int use_earlycon __initdata;
> > +static int __init setup_acpi_earlycon(char *buf)
> > +{
> > + if (!buf)
> > + use_earlycon = 1;
> > +
> > + return 0;
> > +}
> > +early_param("earlycon", setup_acpi_earlycon);
>
> It seems a shame to add this after folding the OF case into the earlycon
> code. What necessitates this being a separate early_param? Why is it too
> early to parse DBG2?
Currently, we don't even know where our ACPI tables are at this point
(efi_init() is called two functions after parse_early_param() in
setup_arch). More specifically, because acpi_boot_table_init() is
called even later than that.
If we moved both of those earlier, we could drop the extra earlycon
param handling for ACPI. That would of course reduce the ability to
have dynamically configurable debug messages for both of these.
> [...]
>
> > diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> > index 2bda09a..c063cbb 100644
> > --- a/drivers/tty/serial/earlycon.c
> > +++ b/drivers/tty/serial/earlycon.c
> > @@ -13,6 +13,7 @@
> >
> > #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -184,12 +185,16 @@ static int __init param_setup_earlycon(char *buf)
> > int err;
> >
> > /*
> > -* Just 'earlycon' is a valid param for devicetree earlycons;
> > -* don't generate a warning from parse_early_params() in that case
> > +* Just 'earlycon' is a valid param for devicetree or ACPI earlycons;
> > +* ACPI cannot be parsed yet, so return without action if enabled.
> > +* Otherwise, attempt initialization using DT.
> > */
> > - if (!buf || !buf[0])
> > - if (IS_ENABLED(CONFIG_OF_FLATTREE))
> > + if (!buf || !buf[0]) {
> > + if (!acpi_disabled)
> > + return 0;
> > + else if (IS_ENABLED(CONFIG_OF_FLATTREE))
> > return early_init_dt_scan_chosen_serial();
> > + }
>
> It would be much nicer if we could handle the ACPI earlycon parsing in
> the same place. As above, I assume I'm missing something that prevents
> that.
I don't disagree.
/
Leif
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] pwm: Add Broadcom BCM7038 PWM controller support
On 07/09/15 12:15, Ariel D'Alessandro wrote:
> Hi Florian,
>
> I wrote some observations below that maybe can be useful.
>
> El 28/08/15 a las 22:21, Florian Fainelli escribió:
>> Add support for the BCM7038-style PWM controller found in all BCM7xxx STB
>> SoCs.
>> This controller has a hardcoded 2 channels per controller, and cascades a
>> variable frequency generator on top of a fixed frequency generator which
>> offers
>> a range of a 148ns period all the way to ~622ms periods.
>>
>> Signed-off-by: Florian Fainelli
NB: you can trim your replies so we do not have to skip through lengthy
uncommented parts of the patch.
[snip]
>> +
>> +static inline u32 pwm_readl(struct brcmstb_pwm_dev *p, u32 off)
>
> The function name 'pwm_readl' sounds to be very common. It might be
> better to use a prefix here, don't you think? Maybe brcmstb_pwm_readl?
Sure, if that makes it clearer, these are local and inlined, so the
chances for getting a namespace conflict are very thin, but fair enough,
will rename to match the rest of the functions.
[snip]
>> +/*
>> + * We can be called with separate duty and period updates,
>> + * so do not reject dc == 0 right away
>> + */
>> +if (pc == PWM_PERIOD_MIN ||
>> + (dc < PWM_ON_MIN && duty_ns))
>
> No break needed here, this expression can be written on a single line
> increasing readability.
>
>> +return -EINVAL;
>> +
>> +/* We converged on a calculation */
>> +if (pc <= PWM_ON_PERIOD_MAX && dc <= PWM_ON_PERIOD_MAX)
>> +break;
>> +
>> +/*
>> + * The cword needs to be a power of 2 for the variable
>> + * frequency generator to output a 50% duty cycle variable
>> + * frequency which is used as input clock to the fixed
>> + * frequency generator.
>> + */
>> +cword >>= 1;
>> +
>> +/*
>> + * Desired periods are too large, we do not have a divider
>> + * for them
>> + */
>> +if (cword < CONST_VAR_F_MIN)
>> +return -EINVAL;
>> +}
>> +
>> +done:
>> +/*
>> + * Configure the defined "cword" value to have the variable frequency
>> + * generator output a base frequency for the constant frequency
>> + * generator to derive from.
>> + */
>> +pwm_writel(b, cword >> 8, PWM_CWORD_MSB + ch * PWM_CH_SIZE);
>> +pwm_writel(b, cword & 0xff, PWM_CWORD_LSB + ch * PWM_CH_SIZE);
>> +
>> +/* Select constant frequency signal output */
>> +reg = pwm_readl(b, PWM_CTRL2);
>> +reg |= (CTRL2_OUT_SELECT << (ch * CTRL_CHAN_OFFS));
>
> A nitpick here, outer parenthesis can be avoided.
>
>> +pwm_writel(b, reg, PWM_CTRL2);
>
> This read-modify-write sequence may be protected by some locking
> mechanism. Notice that, as written in the docs: "PWM core does not
> enforce any locking to pwm_enable(), pwm_disable() and pwm_config()".
Right, I will add required locking here, thanks!
[snip]
>> +r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +p->base = devm_ioremap_resource(&pdev->dev, r);
>> +if (!p->base)
>> +return -ENOMEM;
>
> I think you're missing some cleanup routine here. You have a previous
> call to clk_prepare_enable(), so you may have a call to
> clk_disable_unprepare() here in order to exit cleanly.
Good catch yes.
>
>> +
>> +ret = pwmchip_add(&p->chip);
>> +if (ret)
>> +dev_err(&pdev->dev, "failed to add PWM chip %d\n", ret);
>
> Cleanup needed here too.
>
>> +
>> +return ret;
>> +}
>> +
>> +static int brcmstb_pwm_remove(struct platform_device *pdev)
>> +{
>> +struct brcmstb_pwm_dev *p = platform_get_drvdata(pdev);
>> +
>> +clk_disable_unprepare(p->clk);
>> +
>> +return pwmchip_remove(&p->chip);
>
> AFAIK, pwmchip_remove() may return busy if the PWM chip provides a PWM
> device that is still requested, so you shouldn't disable the clock
> before you ensure the PWM chip has been successfuly removed.
Absolutely.
>
> It think you could do something like:
>
> ret = pwmchip_remove(&p->chip);
> if (ret)
> return ret;
>
> clk_disable_unprepare(p->clk);
> return 0;
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/5] HACK: serial: move pl011 initcall to device_initcall
On Tue, Sep 08, 2015 at 01:56:08PM +0100, Mark Rutland wrote:
> On Tue, Sep 08, 2015 at 01:43:37PM +0100, Leif Lindholm wrote:
> > ---
> > drivers/tty/serial/amba-pl011.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/amba-pl011.c
> > b/drivers/tty/serial/amba-pl011.c
> > index 452dbba..31cf985 100644
> > --- a/drivers/tty/serial/amba-pl011.c
> > +++ b/drivers/tty/serial/amba-pl011.c
> > @@ -2806,7 +2806,7 @@ static void __exit pl011_exit(void)
> > * While this can be a module, if builtin it's most likely the console
> > * So let's leave module_exit but move module_init to an earlier place
> > */
> > -arch_initcall(pl011_init);
> > +device_initcall(pl011_init);
> > module_exit(pl011_exit);
>
> What's the ordering constraint that you're trying to solve with this?
Basically that _CRS is not available until the ACPI subsystem is up -
so when uart_add_one_port() calls acpi_console_check(), that function
looks for a match against variables that have not been set yet.
> The cover didn't mention anything, and there's no commit message.
That's because I really don't want it committed :)
> Mark.
>
> >
> > MODULE_AUTHOR("ARM Ltd/Deep Blue Solutions Ltd");
> > --
> > 2.1.4
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] of/serial: move earlycon early_param handling to serial
On Tue, Sep 08, 2015 at 01:52:45PM +0100, Mark Rutland wrote:
> On Tue, Sep 08, 2015 at 01:43:34PM +0100, Leif Lindholm wrote:
> > We have multiple "earlycon" early_param handlers - merge the DT one into
> > the main earlycon one. This means the earlycon early_param handler does
> > not just return success if no options are specified.
> >
> > Signed-off-by: Leif Lindholm
> > ---
> > drivers/of/fdt.c | 11 +--
> > drivers/tty/serial/earlycon.c | 4 +++-
> > include/linux/of_fdt.h| 1 +
> > 3 files changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 6e82bc42..fcfc4c7 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -793,7 +793,7 @@ static inline void
> > early_init_dt_check_for_initrd(unsigned long node)
> > #ifdef CONFIG_SERIAL_EARLYCON
> > extern struct of_device_id __earlycon_of_table[];
> >
> > -static int __init early_init_dt_scan_chosen_serial(void)
> > +int __init early_init_dt_scan_chosen_serial(void)
> > {
> > int offset;
> > const char *p;
> > @@ -834,15 +834,6 @@ static int __init
> > early_init_dt_scan_chosen_serial(void)
> > }
> > return -ENODEV;
> > }
> > -
> > -static int __init setup_of_earlycon(char *buf)
> > -{
> > - if (buf)
> > - return 0;
> > -
> > - return early_init_dt_scan_chosen_serial();
> > -}
> > -early_param("earlycon", setup_of_earlycon);
> > #endif
> >
> > /**
> > diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> > index f096360..2bda09a 100644
> > --- a/drivers/tty/serial/earlycon.c
> > +++ b/drivers/tty/serial/earlycon.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -187,7 +188,8 @@ static int __init param_setup_earlycon(char *buf)
> > * don't generate a warning from parse_early_params() in that case
> > */
> > if (!buf || !buf[0])
> > - return 0;
> > + if (IS_ENABLED(CONFIG_OF_FLATTREE))
> > + return early_init_dt_scan_chosen_serial();
> >
> > err = setup_earlycon(buf);
> > if (err == -ENOENT || err == -EALREADY)
> > diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> > index df9ef38..772c47c 100644
> > --- a/include/linux/of_fdt.h
> > +++ b/include/linux/of_fdt.h
> > @@ -63,6 +63,7 @@ extern int early_init_dt_scan_chosen(unsigned long node,
> > const char *uname,
> > int depth, void *data);
> > extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
> > int depth, void *data);
> > +extern int early_init_dt_scan_chosen_serial(void);
>
> I think you need a static inline stub to prevent link errors in
> !CONFIG_OF_FLATTREE kernels, as we do for
> early_init_fdt_scan_reserved_mem and friends.
Will add, thanks.
>
> Mark.
>
> > extern void early_init_fdt_scan_reserved_mem(void);
> > extern void early_init_fdt_reserve_self(void);
> > extern void early_init_dt_add_memory_arch(u64 base, u64 size);
> > --
> > 2.1.4
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] QEMU fw_cfg DMA interface documentation
On Mon, Sep 07, 2015 at 01:08:29PM +0200, Gerd Hoffmann wrote: > > It's just simplicity. If you want to read a few times from the same > > field (like in ACPI tables, read the data size and then the data), you > > need a way to enable and disable the selector and manage the current > > offset for that entry. This is already provided with the "old" > > interface. > > Could be handled with a 'select' control bit. Only when set select > entry and reset offset to zero. I think two features would help "round off" the new fw_cfg DMA proposal: add a select bit as you describe (that uses the 16 most significant bits of the "control" field for the "select entry" when the bit is set), and define a static signature (eg, "QEMU CFG") when reading the 64bit MMIO dma register. Both are optional features that don't change the fundamental interface; I was thinking of sending them as two patches on top of Marc's next version of his patch series (if no one else gets to it first). -Kevin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote:
> The ACPI DBG2 table defines a debug console. Add support for parsing it
> and using it to select earlycon destination when no arguments provided.
>
> Signed-off-by: Leif Lindholm
> ---
> arch/arm64/kernel/acpi.c | 2 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/console.c| 103
> ++
> drivers/of/fdt.c | 2 +-
> drivers/tty/serial/earlycon.c | 16 ---
> include/linux/acpi.h | 4 ++
> include/linux/serial_core.h | 9 ++--
> 7 files changed, 126 insertions(+), 11 deletions(-)
> create mode 100644 drivers/acpi/console.c
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b9a5623..be7600a 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
> if (!param_acpi_force)
> disable_acpi();
> }
> +
> + acpi_early_console_probe();
> }
>
> void __init acpi_gic_init(void)
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index b5e7cd8..a89587d 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -10,6 +10,7 @@ ccflags-$(CONFIG_ACPI_DEBUG)+= -DACPI_DEBUG_OUTPUT
> #
> obj-y+= tables.o
> obj-$(CONFIG_X86)+= blacklist.o
> +obj-y+= console.o
obj-$(CONFIG_SERIAL_EARLYCON) += console.o
to eliminate whole-file #ifdef
>
> #
> # ACPI Core Subsystem (Interpreter)
> diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> new file mode 100644
> index 000..a985890
> --- /dev/null
> +++ b/drivers/acpi/console.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define DEBUG
> +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +
> +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
> +
> +#ifdef CONFIG_SERIAL_EARLYCON
> +static int use_earlycon __initdata;
> +static int __init setup_acpi_earlycon(char *buf)
> +{
> + if (!buf)
> + use_earlycon = 1;
> +
> + return 0;
> +}
> +early_param("earlycon", setup_acpi_earlycon);
> +
> +extern struct earlycon_id __earlycon_table[];
> +
> +static __initdata struct {
> + int id;
> + const char *name;
> +} subtypes[] = {
> + {0, "uart8250"},
> + {1, "uart8250"},
> + {2, NULL},
> + {3, "pl011"},
> +};
Instead of having a table here, why not have an ACPI_EARLYCON_DECLARE()
where individual drivers can provide an id similar to OF_EARLYCON_DECLARE()
providing compatible strings?
> +
> +static int __init acpi_setup_earlycon(unsigned long addr, const char *driver)
> +{
> + const struct earlycon_id *match;
> +
> + for (match = __earlycon_table; match->name[0]; match++)
> + if (strcmp(driver, match->name) == 0)
> + return setup_earlycon_driver(addr, match->setup);
> +
> + return -ENODEV;
> +}
> +
> +static int __init acpi_parse_dbg2(struct acpi_table_header *table)
> +{
> + struct acpi_table_dbg2 *dbg2;
> + struct acpi_dbg2_device *entry;
> + void *tbl_end;
> +
> + dbg2 = (struct acpi_table_dbg2 *)table;
> + if (!dbg2) {
> + pr_debug("DBG2 not present.\n");
> + return -ENODEV;
> + }
> +
> + tbl_end = (void *)table + table->length;
> +
> + entry = (struct acpi_dbg2_device *)((void *)dbg2 + dbg2->info_offset);
> +
> + while (((void *)entry) + sizeof(struct acpi_dbg2_device) < tbl_end) {
> + struct acpi_generic_address *addr;
> +
> + if (entry->revision != 0) {
> + pr_debug("DBG2 revision %d not supported.\n",
> + entry->revision);
> + return -ENODEV;
> + }
> +
> + addr = (void *)entry + entry->base_address_offset;
> +
> + pr_debug("DBG2 PROBE - console (%04x:%04x).\n",
> + entry->port_type, entry->port_subtype);
> +
> + if (use_earlycon &&
> + (entry->port_type == ACPI_DBG2_SERIAL_PORT) &&
> + (entry->port_subtype < NUM_ELEMS(subtypes)))
> + acpi_setup_earlycon(addr->address,
> + subtypes[entry->port_subtype].name);
Don't we need to handle space_id (and bit width) as well as address?
> +
> + entry = (struct acpi_dbg2_device *)
> + ((void *)entry + entry->length);
> + }
> +
> + return 0;
> +}
> +
> +int __init acpi_early_console_probe(void)
> +{
> + acpi_table_parse(ACPI_SIG_DBG2, acpi_parse_dbg2);
> +
>
Re: [PATCH 1/3] Revert "ahci: added support for Freescale AHCI sata"
On Mon, Sep 07, 2015 at 10:52:14AM +0200, Hans de Goede wrote:
> Hi,
>
> On 07-09-15 10:23, yuantian.t...@freescale.com wrote:
> >From: Tang Yuantian
> >
> >This reverts commit 5163fb62541e
> >("ahci: added support for Freescale AHCI sata")
> >
> >The reverted patch added Freescale QorIQ AHCI sata support to
> >ahci_platform driver though, but it left SoC specific settings to uboot.
> >It leads to QorIQ sata heavily depending on uboot. In order to removing
> >the dependency we first revert the old patch and then will add a new driver
> >for QorIQ SATA.
> >Since there are no LS* platforms that have been upstreamed, So
> >the revert would not break anything exists.
> >
> >Signed-off-by: Tang Yuantian
>
> The entire series looks good to me and is:
>
> Reviewed-by: Hans de Goede
Applied to libata/for-4.4.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v5 1/5] mtd: spi-nor: notify (Q)SPI controller about protocol change
On Tuesday, September 08, 2015 at 06:20:05 PM, Cyrille Pitchen wrote: > Hi Jonas, > > taking your comments into account I'm about to test a new series with > additional patches to handle the Read ID command in multiple I/O protocols > and relying on new members in the struct spi_nor: > > * @erase_proto: the SPI protocol used by erase operations > * @read_proto: the SPI protocol used by read operations > * @write_proto: the SPI protocol used by write operations > * @reg_proto the SPI protocol used by read_reg/write_reg operations > > enum spi_protocol erase_proto; > enum spi_protocol read_proto; > enum spi_protocol write_proto; > enum spi_protocol reg_proto; > > This way, the read(), write(), erase(), read_reg() and write_reg() hooks > can check the relevant protocol member so the spi-nor framework doesn't > need to call spi_nor_set_protocol() before any command. > > Also the op codes for read, page program and erase commands will be tuned > depending on the memory manufacturer and the selected SPI protocol. > > I'm likely to publish this new series tomorrow after my tests on a Micron > memory. Excellent, please keep me on Cc as I'm already warming up my Spansion part ;-) Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/8] pinctrl: freescale: imx: add shared input select reg support
Hi Shawn,
See comments below.
Regards
Adrian
From: Shawn Guo
Sent: Sunday, September 6, 2015 9:12 PM
To: Alonso Lazcano Adrian-B38018
Cc: linux-arm-ker...@lists.infradead.org; shawn@linaro.org;
linus.wall...@linaro.org; lzn...@gmail.com; linux-g...@vger.kernel.org;
devicetree@vger.kernel.org; robh...@kernel.org; Huang Yongcai-B20788; Li
Frank-B20596; Gong Yibin-B38343; Garg Nitin-B37173
Subject: Re: [PATCH v2 6/8] pinctrl: freescale: imx: add shared input select
reg support
On Tue, Sep 01, 2015 at 05:49:11PM -0500, Adrian Alonso wrote:
> - Add shared input select register support
> - imx7d has two iomux controllers iomuxc and iomuxc-lpsr
> which share select_input register for daisy chain settings
>
> Signed-off-by: Adrian Alonso
> ---
> Changes for V2: Resend
>
> drivers/pinctrl/freescale/pinctrl-imx.c | 28 +++-
> drivers/pinctrl/freescale/pinctrl-imx.h | 1 +
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 9f019be..597319d 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +40,7 @@ struct imx_pinctrl {
> struct device *dev;
> struct pinctrl_dev *pctl;
> void __iomem *base;
> + void __iomem *input_sel_base;
> const struct imx_pinctrl_soc_info *info;
> };
>
> @@ -254,7 +256,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev,
> unsigned selector,
>* Regular select input register can never be at offset
>* 0, and we only print register value for regular case.
>*/
> - writel(pin->input_val, ipctl->base + pin->input_reg);
> + if (info->flags & SHARE_INPUT_SELECT_REG)
This can be replaced by a NULL checking on input_sel_base.
[Adrian] Yes, but I will prefer to keep this flag check instead to keep code
consisten on how to handle
special cases, that way is easier to spot when input select register is shared.
> + writel(pin->input_val, ipctl->input_sel_base +
> + pin->input_reg);
> + else
> + writel(pin->input_val, ipctl->base +
> + pin->input_reg);
> dev_dbg(ipctl->dev,
> "==>select_input: offset 0x%x val 0x%x\n",
> pin->input_reg, pin->input_val);
> @@ -690,6 +697,8 @@ static int imx_pinctrl_probe_dt(struct platform_device
> *pdev,
> int imx_pinctrl_probe(struct platform_device *pdev,
> struct imx_pinctrl_soc_info *info)
> {
> + struct device_node *dev_np = pdev->dev.of_node;
> + struct device_node *np;
> struct imx_pinctrl *ipctl;
> struct resource *res;
> int ret;
> @@ -715,6 +724,23 @@ int imx_pinctrl_probe(struct platform_device *pdev,
> if (IS_ERR(ipctl->base))
> return PTR_ERR(ipctl->base);
>
> + if (info->flags & SHARE_INPUT_SELECT_REG) {
> + np = of_get_child_by_name(dev_np->parent, "iomuxc");
This doesn't scale well. First of all, we do not generally recommend
searching node by name, because most of time node name is not enforced
to be stable, and some nodes are named quite arbitrarily. Secondly, we
do not know if the hardware people will move select_input registers to
somewhere else than IOMUXC in the future.
Hence, I suggest you have a device tree phandle pointing the device
where select_input registers are located. In that case, flag
SHARE_INPUT_SELECT_REG can even be saved completely.
[Adrian] Agree, let me rework this :)
> + if (np) {
> + ipctl->input_sel_base = of_iomap(np, 0);
> + if (IS_ERR(ipctl->input_sel_base)) {
> + of_node_put(np);
> + dev_err(&pdev->dev,
> +"iomuxc base address not found\n");
> + return PTR_ERR(ipctl->input_sel_base);
> + }
> + } else {
> + dev_err(&pdev->dev, "iomuxc device node not foud\n");
s/foud/found
Shawn
> + return -EINVAL;
> + }
> + of_node_put(np);
> + }
> +
> imx_pinctrl_desc.name = dev_name(&pdev->dev);
> imx_pinctrl_desc.pins = info->pins;
> imx_pinctrl_desc.npins = info->npins;
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 67c07c2..d11a827 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -86,6 +86,7 @@ struct imx_
Re: [PATCH linux-next v9 0/3] mfd: flexcom: add a driver for Flexcom
On Tue, 08 Sep 2015, Cyrille Pitchen wrote: > Hi all, > > Le 01/09/2015 16:46, Cyrille Pitchen a écrit : > > ChangeLog > > > > v9: > > - go back to v5 (use the new "atmel,flexcom-mode" DT property). > > - fix the name of the spi node in the DT example: from spi@f8034400 to > > spi@400 > > - align the fields of the struct platform_driver atmel_flexcom_driver as > > suggested by Lee Jones. > > > [...] > > Are there any remaining blocking points for this series ? Yes. The merge window is open, so it's Maintainer sleepy time [0]. Will get back to reviewing next week probably. [0] AKA: Breath out and catch up with real-work for a bit. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] Documentation: arm64/arm: dt bindings for numa.
Hi Hanjun,
On Tue, Sep 8, 2015 at 6:57 PM, Hanjun Guo wrote:
> Hi Ganapatrao,
>
>
> On 08/29/2015 10:56 PM, Ganapatrao Kulkarni wrote:
>>
>> Hi Thunder,
>>
>> On Sat, Aug 29, 2015 at 3:16 PM, Leizhen (ThunderTown)
>> wrote:
>>>
>>>
>>>
>>> On 2015/8/28 22:02, Rob Herring wrote:
+benh
On Fri, Aug 28, 2015 at 7:32 AM, Mark Rutland
wrote:
>
> Hi,
>
> On Fri, Aug 14, 2015 at 05:39:32PM +0100, Ganapatrao Kulkarni wrote:
>>
>> DT bindings for numa map for memory, cores and IOs using
>> arm,associativity device node property.
>
>
> Given this is just a copy of ibm,associativity, I'm not sure I see much
> point in renaming the properties.
So just keep the ibm? I'm okay with that. That would help move to
common code. Alternatively, we could drop the vendor prefix and have
common code just check for both.
>>>
>>> Hi all,
>>>
>>> Why not copy the method of ACPI numa? There only three elements should be
>>> configured:
>>> 1) a cpu belong to which node
>>> 2) a memory block belong to which node
>>> 3) the distance of each two nodes
>>>
>>> The devicetree nodes of numa can be like below:
>>> / {
>>> ...
>>>
>>> numa-nodes-info {
>>> node-name: node-description {
>>> mem-ranges = <...>;
>>> cpus-list = <...>;
>>> };
>>>
>>> nodes-distance {
>>> distance-list = <...>;
>>> };
>>> };
>>>
>>> ...
>>> };
>>>
>> some what similar to what your are proposing is already implemented in
>> my v2 patchset.
>> https://lwn.net/Articles/623920/
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305164.html
>> we have went to associativity property based implementation to keep it
>> more generic.
>> i do have both acpi(using linaro/hanjun's patches) and associativity
>> based implementations on our internal tree
>> and tested on thunderx platform.
>
>
> Great thanks!
>
>> i do see issue in creating numa mapping using ACPI for IOs(for
>> example, i am not able to create numa mapping for ITS which is on each
>> node, using ACPI tables), since ACPI spec (tables SRAT and SLIT)
>> talks only about processor and memory.
>
>
> I'm not sure why the ITS needs to know the NUMA domain, for my
> understanding, the interrupt will route to the correct NUMA domain
> using setting the affinity, ITS will configured to route it to
> the right GICR(cpu), so I think the ITS don't need to know which
> NUMA node belonging to, correct me if I missed something.
IIUC, GICR/collection is per cpu and can be mapped to numa node using
cpu to node mapping.
However there are multiple its in multi-socket platform(at-least one
its per socket),
knowing its to numa node mapping will help in routing(optimal) the
interrupts to any one of GICR/collections of that node
Hence, we need to find which its belongs to which socket/node using dt.
same applies to pci bus too.
>
> Thanks
> Hanjun
thanks
Ganapat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/8] pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
Hi Shawn,
See comments below
Regards
From: Shawn Guo
Sent: Sunday, September 6, 2015 8:28 PM
To: Alonso Lazcano Adrian-B38018
Cc: linux-arm-ker...@lists.infradead.org; shawn@linaro.org;
linus.wall...@linaro.org; lzn...@gmail.com; devicetree@vger.kernel.org; Li
Frank-B20596; Garg Nitin-B37173; Huang Yongcai-B20788;
linux-g...@vger.kernel.org; robh...@kernel.org; Gong Yibin-B38343
Subject: Re: [PATCH v2 5/8] pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
On Tue, Sep 01, 2015 at 05:49:10PM -0500, Adrian Alonso wrote:
> - Add ZERO_OFFSET_VALID flag, on imx7d mux_conf reg
> offset is zero for iomuxc-lspr controller
> - Do default initialization on parse group function.
>
> Signed-off-by: Adrian Alonso
I do not follow why this patch is needed at all. All the register
validity check are done against -1, and zero offset is already supported
by the driver in the current form. Or am I missing anything?
Shawn
> ---
> Changes for V2: Resend
>
> drivers/pinctrl/freescale/pinctrl-imx.c | 23 +--
> drivers/pinctrl/freescale/pinctrl-imx.h | 1 +
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 95db9e8..9f019be 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -437,7 +437,7 @@ static void imx_pinconf_dbg_show(struct pinctrl_dev
> *pctldev,
> const struct imx_pin_reg *pin_reg = &info->pin_regs[pin_id];
> unsigned long config;
>
> - if (!pin_reg || pin_reg->conf_reg == -1) {
> + if (pin_reg->conf_reg == -1) {
> seq_printf(s, "N/A");
> return;
> }
> @@ -536,21 +536,29 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> return -ENOMEM;
>
> for (i = 0; i < grp->npins; i++) {
> - u32 mux_reg = be32_to_cpu(*list++);
> + u32 mux_reg;
> u32 conf_reg;
> unsigned int pin_id;
> struct imx_pin_reg *pin_reg;
> struct imx_pin *pin = &grp->pins[i];
>
> + mux_reg = be32_to_cpu(*list++);
> + if (!(info->flags & ZERO_OFFSET_VALID) && !mux_reg)
> + mux_reg = -1;
> +
> if (info->flags & SHARE_MUX_CONF_REG) {
> conf_reg = mux_reg;
> } else {
> conf_reg = be32_to_cpu(*list++);
> - if (!conf_reg)
> + if (!(info->flags & ZERO_OFFSET_VALID) && !conf_reg)
> conf_reg = -1;
> }
>
[Adrian] The below assignment is the important thing that this patch does,
it allows the pad_id to be zero and match the pad id's according to the mux_reg
offset.
> - pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
> + if (info->flags & ZERO_OFFSET_VALID)
> + pin_id = mux_reg / 4;
> + else
> + pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
> +
> pin_reg = &info->pin_regs[pin_id];
> pin->pin = pin_id;
> grp->pin_ids[i] = pin_id;
> @@ -684,7 +692,7 @@ int imx_pinctrl_probe(struct platform_device *pdev,
> {
> struct imx_pinctrl *ipctl;
> struct resource *res;
> - int ret, i;
> + int ret;
>
> if (!info || !info->pins || !info->npins) {
> dev_err(&pdev->dev, "wrong pinctrl info\n");
> @@ -702,11 +710,6 @@ int imx_pinctrl_probe(struct platform_device *pdev,
> if (!info->pin_regs)
> return -ENOMEM;
>
> - for (i = 0; i < info->npins; i++) {
> - info->pin_regs[i].mux_reg = -1;
> - info->pin_regs[i].conf_reg = -1;
> - }
> -
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ipctl->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(ipctl->base))
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
> b/drivers/pinctrl/freescale/pinctrl-imx.h
> index 26f8f1c..67c07c2 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.h
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.h
> @@ -85,6 +85,7 @@ struct imx_pinctrl_soc_info {
> };
>
> #define SHARE_MUX_CONF_REG 0x1
> +#define ZERO_OFFSET_VALID0x2
>
> #define NO_MUX 0x0
> #define NO_PAD 0x0
> --
> 2.1.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v5 1/5] mtd: spi-nor: notify (Q)SPI controller about protocol change
Hi Jonas, taking your comments into account I'm about to test a new series with additional patches to handle the Read ID command in multiple I/O protocols and relying on new members in the struct spi_nor: * @erase_proto:the SPI protocol used by erase operations * @read_proto: the SPI protocol used by read operations * @write_proto:the SPI protocol used by write operations * @reg_proto the SPI protocol used by read_reg/write_reg operations enum spi_protocol erase_proto; enum spi_protocol read_proto; enum spi_protocol write_proto; enum spi_protocol reg_proto; This way, the read(), write(), erase(), read_reg() and write_reg() hooks can check the relevant protocol member so the spi-nor framework doesn't need to call spi_nor_set_protocol() before any command. Also the op codes for read, page program and erase commands will be tuned depending on the memory manufacturer and the selected SPI protocol. I'm likely to publish this new series tomorrow after my tests on a Micron memory. Best Regards, Cyrille Le 31/08/2015 21:22, Jonas Gorski a écrit : > Hi, > > On Thu, Aug 27, 2015 at 11:51 AM, Cyrille Pitchen > wrote: >> Hi Jonas, >> >> Le 26/08/2015 16:02, Jonas Gorski a écrit : >>> On Wed, Aug 26, 2015 at 2:30 PM, Cyrille Pitchen >>> wrote: Once the Quad SPI mode has been enabled on a Micron flash memory, this device expects ALL the following commands to use the SPI 4-4-4 protocol. The (Q)SPI controller needs to be notified about the protocol change so it can adapt and keep on dialoging with the Micron memory. >>> >>> Doesn't that mean you need to disable quad mode on removal? Else the >>> following will break/fail: >>> >>> insmod atmel-quadspi.ko ~> spi-nor attaches -> sees micron -> enables quad >>> mode >>> rmmod atmel-quadspi.ko ~> spi-nor detaches >>> insmod atmel-quadspi.ko ~> spi-nor attaches -> fails to read the id >>> because flash is still in quad mode. >>> >> >> Indeed you're right such an issue does exist. So as you said one solution >> could be create a new function to "clean" what have been done by >> spi_nor_scan() >> then call it from remove() function of each driver calling spi_nor_scan() >> from >> its probe(). >> However we could also enhance the probing of the memory. It is true that >> Micron >> spi nor memories only accept SPI 4-4-4 commands once switched in quad mode >> but >> actually they also provide a new command for this purpose: >> "Multiple I/O Read ID" (0xAF). >> Hence we could first try to probe using the regular Read ID (0x9F) command >> then >> change the protocol, for instance to SPI 4-4-4, and try the 0xAF command. >> I don't think all combinations for command/protocol need to be tested: for >> Micron memories, their datasheets claim the 0x9F command is only supported in >> "extended spi mode" so for the SPI 1-1-1 protocol whereas the 0xAF command >> only works in dual or quad modes. >> On the other hand Spansion memories still reply to the regular 0x9F command >> in >> SPI 1-1-1 protocol even after their quad mode had been enabled. >> For other manufacturers, well... I don't know! > > At least from the two spansion datasheets I looked at, there is no 2_ > or 4_ mode for spansion flashes, and the quad mode only enables the > 1_x_4 commands, where as on micron the 1_x_4 commands are always > available, and you only need to switch to DIO or QIO if you want to > use 2_2_2 or 4_4_4. > > The question is how to detect if the READID command failed. Hopefully > it will result in an invalid command, and we get 0xff... (or 0x00...) > for the the id. And from there on we can first test 4_4_4 MIORDID (so > it won't a a full command on a DIO-enabled flash), and if that fails, > 2_2_2. We need to tell the spi-nor controller to send these > accordingly though. I wonder if it might not be better to pass the > c_a_d as an additional parameter to the read_reg/write_reg etc call > backs, because they might change depending on the command used. E.g. > when using SPI_NOR_QUAD, we might want to make use of the quad page > program command (which is 1_1_4), but there is no 1_1_2 version, so we > cannot rely on a global "protocol" member for that, unless we want to > do a set_protocol before every command. > >> >> Some of the advantages of the probe solution as compared to the remove one >> are: >> - we don't need to patch all drivers using spi_nor_scan() to call a new >> function from their remove(). >> - it doesn't rely on the assumption that the spi-nor memory starts in >> SPI 1-1-1 protocol. As a matter of fact the remove() won't be called for >> built-in modules or in many (all ?) cases of reset. Moreover some >> bootloaders >> may have already enabled the quad mode before starting the Linux kernel. >> This >> is what the sama5d2 romcode does when it is configured to boot from a QSPI >> memory. >> >> Anyway you're right and the issue need to be addre
Re: [PATCH v2 8/8] pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings
Hi Shawn,
See comments below.
Regards
Adrian
From: Shawn Guo
Sent: Sunday, September 6, 2015 9:42 PM
To: Alonso Lazcano Adrian-B38018
Cc: linux-arm-ker...@lists.infradead.org; shawn@linaro.org;
linus.wall...@linaro.org; lzn...@gmail.com; linux-g...@vger.kernel.org;
devicetree@vger.kernel.org; robh...@kernel.org; Huang Yongcai-B20788; Li
Frank-B20596; Gong Yibin-B38343; Garg Nitin-B37173
Subject: Re: [PATCH v2 8/8] pinctrl: freescale: imx: imx7d iomuxc-lpsr
devicetree bindings
On Tue, Sep 01, 2015 at 05:49:13PM -0500, Adrian Alonso wrote:
> Add iomuxc-lpsr devicetree bindings documentation
> Provide documentation context as well an example on
> pheriperals that could use pad from either iomuxc controller
> supported by iMX7D SoC
>
> Signed-off-by: Adrian Alonso
> ---
> Changes for V2: New patch on imx7d iomuxc-lpsr patch series
>
> .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 43
> ++
> 1 file changed, 43 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> index 8bbf25d..c7310fc 100644
> --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
> @@ -1,10 +1,19 @@
> * Freescale i.MX7 Dual IOMUX Controller
>
> +iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar
> +as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low
> +power state rentetion capabilities on gpios that are part of iomuxc-lpsr
> +(GPIO1_IO7..GPIO1_IO0).
I think the speciality of the select_input registers should be
mentioned too.
[Adrian] Agree will add notes for shared select input.
> +
> +Pheriparials using pads from iomuxc-lpsr support low state retention power
> +state, under LPSR mode GPIO's state of pads are retain.
> +
> Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> and usage.
>
> Required properties:
> - compatible: "fsl,imx7d-iomuxc"
> +- compatible: "fsl-imx7d-iomuxc-lpsr"
s/fsl-imx7d-iomuxc-lpsr/fsl,imx7d-iomuxc-lpsr
[Adrian] Will fix this, thanks.
Shawn
> - fsl,pins: each entry consists of 6 integers and represents the mux and
> config
>setting for one pin. The first 5 integers mux_val
>input_val> are specified using a PIN_FUNC_ID macro, which can be found in
> @@ -25,3 +34,37 @@ PAD_CTL_DSE_X1 (0 << 0)
> PAD_CTL_DSE_X2 (1 << 0)
> PAD_CTL_DSE_X3 (2 << 0)
> PAD_CTL_DSE_X4 (3 << 0)
> +
> +Examples:
> +While iomuxc-lpsr is intended to be used by dedicated peripherals to take
> +advantages of LPSR power mode, is also possible that an IP to use pads from
> +any of the iomux controllers. For example the I2C1 IP can use SCL pad from
> +iomuxc-lpsr controller and SDA pad from iomuxc controller as:
> +
> +i2c1: i2c@30a2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>;
> + status = "okay";
> +};
> +
> +iomuxc-lpsr@302c {
> + compatible = "fsl,imx7d-iomuxc-lpsr";
> + reg = <0x302c 0x1>;
> +
> + pinctrl_i2c1_1: i2c1grp-1 {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x407f
> + >;
> + };
> +};
> +
> +iomuxc@3033 {
> + compatible = "fsl,imx7d-iomuxc";
> + reg = <0x3033 0x1>;
> +
> + pinctrl_i2c1_2: i2c1grp-2 {
> + fsl,pins = <
> + MX7D_PAD_I2C1_SCL__I2C1_SCL 0x407f
> + >;
> + };
> +};
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next v9 0/3] mfd: flexcom: add a driver for Flexcom
Hi all, Le 01/09/2015 16:46, Cyrille Pitchen a écrit : > ChangeLog > > v9: > - go back to v5 (use the new "atmel,flexcom-mode" DT property). > - fix the name of the spi node in the DT example: from spi@f8034400 to > spi@400 > - align the fields of the struct platform_driver atmel_flexcom_driver as > suggested by Lee Jones. > [...] Are there any remaining blocking points for this series ? Best Regards, Cyrille -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings
> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: Monday, September 07, 2015 1:05 PM > To: David Daney > Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert; > Chintakuntla, Radha; > devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; > io...@lists.linux-foundation.org; linux-arm- > ker...@lists.infradead.org; Will Deacon; Robin Murphy; Lorenzo Pieralisi; > a...@arndb.de; tred...@nvidia.com; > majun...@huawei.com; thunder.leiz...@huawei.com; > laurent.pinch...@ideasonboard.com; Yoder Stuart-B08248 > Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings > > On Fri, Sep 04, 2015 at 11:33:35PM +0100, David Daney wrote: > > Hi Mark, > > Hi David, > > > I now have a prototype implementation for irq-gic-v3-its.c that is using > > this binding on Cavium's ThunderX platform. > > > > Q: Have you guys had any more thoughts on this that might require > > changing the binding? > > Having discussed this with Stuart and others at Linux Plumbers, I think > that the binding is sufficient, and unlikely to change greatly unless > there is a strong objection (Stuart, please correct me if I am wrong). > > Per Marc's comments there are probably some edge cases and/or wording > details to sort out, but I think the common/simple case is sorted. I'll > send a v2 once those have been settled. I think the binding as-is, is sufficient for the static description of RID to SID. I think the binding can be extended in a backwards compatible way to support dynamic RID->SID mappings if we need that in the future. The case that we (Freescale) are concerned with are where someone plugs an SRIOV card into an SoC and enables, say 64 VFs. It's like hot-plugging 64 new PCI devices at once. If all those devices that show up belong to the host they belong to one 'isolation context' and could share the same streamID, same SMMU mappings, and the same ITT in the GIC ITS. So a static mapping could work. But, as soon as I want to assign VF#5 to a virtual machine I need a new RID->SID mapping for VF#5. To require firmware to do that mapping ahead of time is a _real_ pain. I think longer term we need some mechanism to allow lazy, dynamic RID->SID mappings by Linux. We can start with the static approach, but we need to keep in the back of our minds that there may be cases in the near future where a static mapping is too inflexible. Thanks, Stuart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
Hi Daniel, On Mon, 2015-09-07 at 12:05 +0800, Daniel Kurtz wrote: > On Mon, Sep 7, 2015 at 12:00 PM, Daniel Kurtz wrote: > > Hi Dawei, > > > > On Fri, Sep 4, 2015 at 5:01 PM, Dawei Chien > > wrote: > >> Add thermal zone node to mt8173.dtsi. > >> > >> Signed-off-by: Dawei Chien > >> --- > >> This patch is base on following patches > >> https://patchwork.kernel.org/patch/6969581/ > >> https://patchwork.kernel.org/patch/6969571/ > >> https://patchwork.kernel.org/patch/6969381/ > >> --- > >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44 > >> ++ > >> 1 file changed, 44 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> index 208051a..6493bfd 100644 > >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi > >> @@ -17,6 +17,7 @@ > >> #include > >> #include > >> #include "mt8173-pinfunc.h" > >> +#include > > Also, as a nit, (#include ) should be > above '#include "mt8173-pinfunc.h"' Thank you, I will resend this patch with mt8171.h and sort header file. > -djk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
