Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Kevin, On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: > Hi Eddie, > > [...] > > > I check the log [0], > > Thanks for checking into this boot failure. > > > it seems first time mt8135-evbp1 boot to kernel > > shell successfully, then boot again. In the second time, mt8135 stay in > > fastboot mode, waiting host send boot image, then timeout. > > Actually, it never gets to a shell the first time. If you look closely, > the target reboots as soon as userspace starts. Look for the PYBOOT > line which says "finished booting, starting userspace" > > Later on, pyboot thinks it finds a root shell due to finding '#' > characters, but clearly it never got to a shell. > > > I download zImage and dtb in [1], and kernel run to shell successfully > > on my platform. > > Are you can you try using a ramdisk as well? You can use the pre-built > one here: > http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz > Yes, I tried this ramdisk, and I can reproduce fail issue. > Please check my boot logs to see how I'm generating the boot.img file > (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible > that the kernel image size with a ramdisk is breaking some of the > assumptions in the fastboot mode. I've seen problems like this on other > platforms due to hard-coded sizes/addresses in the boot firmware. > MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, thus cause user space fail. I will prepare new firmware that extend BOOT partition to 16MB. and put new firmware on Howard's github. I will mail to you when I am ready.. Eddie Thanks -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v1 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform
Signed-off-by: Yakir Yang
---
.../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..1898408
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+ "rockchip,rk3036-dw-hdmi";
+- reg:
+ Physical base address and length of the controller's registers.
+- clocks, clock-names:
+ Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+ HDMI interrupt number
+- ports:
+ Contain one port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+ Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi@20034000 {
+ compatible = "rockchip,rk3036-inno-hdmi";
+ reg = <0x20034000 0x4000>;
+ interrupts = ;
+ clocks = <&cru PCLK_HDMI>;
+ clock-names = "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_ctl>;
+ status = "disabled";
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_lcdc: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_hdmi>;
+ };
+ };
+};
+
+&pinctrl {
+ hdmi {
+ hdmi_ctl: hdmi-ctl {
+ rockchip,pins = <1 8 RK_FUNC_1 &pcfg_pull_none>,
+ <1 9 RK_FUNC_1 &pcfg_pull_none>,
+ <1 10 RK_FUNC_1 &pcfg_pull_none>,
+ <1 11 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+};
--
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 PATCH v1 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/Kconfig |8 +
drivers/gpu/drm/rockchip/Makefile|1 +
drivers/gpu/drm/rockchip/inno_hdmi.c | 1008 ++
drivers/gpu/drm/rockchip/inno_hdmi.h | 364
4 files changed, 1381 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..a5014e0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,11 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_INNO_HDMI
+ tristate "Rockchip specific extensions for Innosilicon HDMI"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..20faf9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..6b986f5
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,1008 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ *Yakir Yang
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+ int vic;
+ bool sink_is_hdmi;
+ bool sink_has_audio;
+ unsigned int enc_in_format;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+
+ struct mutex lock;
+ struct completion cmp;
+};
+
+struct inno_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+
+ int irq;
+ struct clk *pclk;
+ void __iomem *regs;
+
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct inno_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ int dpms_mode;
+ unsigned int tmds_rate;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+enum {
+ CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
+ CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
+ CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
+ CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
+ CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
+ CSC_RGB_0_255_TO_RGB_16_235_8BIT,
+};
+
+static const char coeff_csc[][24] = {
+ /*
+* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
+* R = 1.164*Y + 1.596*V - 204
+* G = 1.164*Y - 0.391*U - 0.813*V + 154
+* B = 1.164*Y + 2.018*U - 258
+*/
+ {
+ 0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
+ 0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
+ 0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
+ },
+ /*
+* YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
+* R = Y + 1.402*V - 248
+* G = Y - 0.344*U - 0.714*V + 135
+* B = Y + 1.772*U - 227
+*/
+ {
+ 0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
+ 0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
+ 0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
+ },
+ /*
+* YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
+* R = 1.164*Y + 1.793*V - 248
+
[RFC PATCH v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms
Hi guys: Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission (32-192kHz Fs) using IEC60958 and IEC 61937 - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle This IP have been integrated on some Rockchip CPUs (like RK3036/RK312x), due to those CPUs haven't been landed on manline kernel, so I creat a branch to verify this series [https://github.com/rockchip-linux/kernel]. - Yakir Yakir Yang (2): drm: rockchip/hdmi: add Innosilicon HDMI support dt-bindings: add document for Innosilicon HDMI on Rockchip platform .../display/rockchip/inno_hdmi-rockchip.txt| 50 + drivers/gpu/drm/rockchip/Kconfig |8 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/inno_hdmi.c | 1008 drivers/gpu/drm/rockchip/inno_hdmi.h | 364 +++ 5 files changed, 1431 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.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 3/4] ARM: dts: rockchip: add eFuse node for rk3066a SoCs
This patch add the eFuse dt node for rk3066a SoCs.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3066a.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 946f187..f61bb8a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -153,6 +153,19 @@
clock-names = "timer", "pclk";
};
+ efuse: efuse@2001 {
+ compatible = "rockchip,rockchip-efuse";
+ reg = <0x2001 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&cru PCLK_EFUSE>;
+ clock-names = "pclk_efuse";
+
+ cpu_leakage: cpu_leakage {
+ reg = <0x17 0x1>;
+ };
+ };
+
timer@20038000 {
compatible = "snps,dw-apb-timer-osc";
reg = <0x20038000 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 4/4] ARM: dts: rockchip: add eFuse node for rk3188 SoCs
This patch add the eFuse dt node for rk3188 SoCs.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3188.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 6399942..b01ef45 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -144,6 +144,19 @@
#reset-cells = <1>;
};
+ efuse: efuse@2001 {
+ compatible = "rockchip,rockchip-efuse";
+ reg = <0x2001 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&cru PCLK_EFUSE>;
+ clock-names = "pclk_efuse";
+
+ cpu_leakage: cpu_leakage {
+ reg = <0x17 0x1>;
+ };
+ };
+
usbphy: phy {
compatible = "rockchip,rk3188-usb-phy",
"rockchip,rk3288-usb-phy";
rockchip,grf = <&grf>;
--
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 0/4] support the efuse for rk3188/rk3066a SoCs and cleanup driver on nvmem.
This patchset to support reading the efuse info for more SoCs. (Note: support 32 bits SoCs). Meanwhile, cleanup sunxi/rockchip drivers for more readability. You can easy to test for following: cd /sys/bus/nvmem/devices/rockchip-efuse0 localhost rockchip-efuse0 # busybox hexdump -C nvmem Caesar Wang (4): nvmem: sunxi: trivial: fix code style nvmem: rockchip: trivial: Make the driver more readability ARM: dts: rockchip: add eFuse node for rk3066a SoCs ARM: dts: rockchip: add eFuse node for rk3188 SoCs arch/arm/boot/dts/rk3066a.dtsi | 13 ++ arch/arm/boot/dts/rk3188.dtsi | 13 ++ drivers/nvmem/rockchip-efuse.c | 90 -- drivers/nvmem/sunxi_sid.c | 9 ++--- 4 files changed, 71 insertions(+), 54 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 2/3] thermal: Add Mediatek thermal controller support
On Tue, Nov 10, 2015 at 10:26:30AM -0800, Eduardo Valentin wrote:
> On Tue, Nov 10, 2015 at 12:05:54PM +, Javi Merino wrote:
> > On Mon, Nov 09, 2015 at 11:13:32AM +0100, Sascha Hauer wrote:
>
>
>
> > > +
> > > +/*
> > > + * The MT8173 thermal controller has four banks. Each bank can read up to
> > > + * four temperature sensors simultaneously. The MT8173 has a total of 5
> > > + * temperature sensors. We use each bank to measure a certain area of the
> > > + * SoC. Since TS2 is located centrally in the SoC it is influenced by
> > > multiple
> > > + * areas, hence is used in different banks.
> > > + */
> > > +static const struct mtk_thermal_bank_cfg bank_data[] = {
> > > + {
> > > + .num_sensors = 2,
> > > + .sensors = { MT8173_TS2, MT8173_TS3 },
> > > + }, {
> > > + .num_sensors = 2,
> > > + .sensors = { MT8173_TS2, MT8173_TS4 },
> > > + }, {
> > > + .num_sensors = 3,
> > > + .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> > > + }, {
> > > + .num_sensors = 1,
> > > + .sensors = { MT8173_TS2 },
> > > + },
> > > +};
>
> Would it make sense to simply expose all sensors and let the
> configuration of their aggregation be done by DT?
This particular layout has been chosen because there's also the Smart
Voltage Scaler (SVS) in the SoC. The SVS uses the same banks for
measuring temperatures. I don't know the details yet, I just asked the
Mediatek guys.
>
> There is already ongoing effort to get aggregation functions
> generalized.
Do you have any pointers? I haven't seen these efforts yet.
> > > +static int mtk_read_temp(void *data, int *temperature)
> > > +{
> > > + struct mtk_thermal *mt = data;
> > > + int i;
> > > + int tempmax = INT_MIN;
> > > +
> > > + for (i = 0; i < MT8173_NUM_ZONES; i++) {
> > > + struct mtk_thermal_bank *bank = &mt->banks[i];
> > > + int t;
> > > +
> > > + mtk_thermal_get_bank(bank);
> > > +
> > > + t = mtk_thermal_bank_temperature(bank);
> >
> > IIUIC, when you had multiple thermal zones
> > mtk_thermal_bank_temperature() made sense, but now it looks like
> > you're just doing the maximum of all sensors. Why bother with the
> > banks any more? Aren't you just calculating the maximum of all
> > sensors? As TS2 is present in all banks, there's no point in reading
> > it four times just to get the maximum of all sensors.
> >
>
> Yeah, agreed here. If that is your intention, maybe read each sensor one
> time, then compute the max of each subset from memory instead.
I would have done that if there wasn't this SVS engine. I'll ask
internally what the constraint of this SVS engine actually are and let
you know.
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 v3 1/5] spi: introduce mmap read support for spi flash devices
Hi,
On Wed, Nov 11, 2015 at 12:20:46PM +0530, R, Vignesh wrote:
> On 11/11/2015 4:53 AM, Brian Norris wrote:
> > On Tue, Nov 10, 2015 at 10:59:55AM +0530, Vignesh R wrote:
> >> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> >> index cce80e6dc7d1..2f2c431b8917 100644Hi
> >> --- a/include/linux/spi/spi.h
> >> +++ b/include/linux/spi/spi.h
> >> @@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct
> >> spi_driver *sdrv)
> >> * @handle_err: the subsystem calls the driver to handle an error that
> >> occurs
> >> *in the generic implementation of transfer_one_message().
> >> * @unprepare_message: undo any work done by prepare_message().
> >> + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory.
> >> + * Flash drivers (like m25p80) can request memory
> >> + * mapped read via this method. This interface
> >> + * should only be used by mtd flashes and cannot be
> >> + * used by other spi devices.
> >> * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
> >> *number. Any individual value may be -ENOENT for CS lines that
> >> *are not GPIOs (driven by the SPI controller itself).
> >> @@ -507,6 +512,11 @@ struct spi_master {
> >> struct spi_message *message);
> >>int (*unprepare_message)(struct spi_master *master,
> >> struct spi_message *message);
> >> + int (*spi_mtd_mmap_read)(struct spi_device *spi,
> >> + loff_t from, size_t len,
> >> + size_t *retlen, u_char *buf,
> >> + u8 read_opcode, u8 addr_width,
> >> + u8 dummy_bytes);
> >
> > Is this API really sufficient? There are actually quite a few other
> > flash-related parameters that might be relevant to a controller. I
> > presume you happen not hit them because of the particular cases you're
> > using this for right now, but:
> >
> > * How many I/O lines are being used? These can vary depending on the
> >type of flash and the number of I/O lines supported by the controller
> >and connected on the board.
> >
>
> This API communicates whatever data is currently communicated via
> spi_message through spi_sync/transfer_one interfaces.
No it doesn't. A spi_message consists of a list of spi_transfer's, and
each spi_transfer has tx_nbits and rx_nbits fields.
> > * The previous point can vary across parts of the message. There are
> >various combinations of 1/2/4 lines used for opcode/address/data. We
> >only support a few of those combinations in m25p80 right now, but
> >you're not specifying any of that in this API. I guess you're just
> >making assumptions? (BTW, I think there are others having problems
> >with the difference between different "quad" modes on Micron flash; I
> >haven't sorted through all the discussion there.)
> >
>
> How is the spi controller currently being made aware of this via
> m25p80_read / spi_sync() interface? AFAIK, mode field of spi_device
> struct tell whether to do normal/dual/quad read but there is no info
> communicated wrt 1/2/4 opcode/address/data combinations.
Yes there is. m25p80 fills out spi_transfer::rx_nbits. Currently, we
only use this for the data portion, but it's possible to support more
lines for the address and opcode portions too, using the rx_nbits for
the opcode and address spi_transfer struct(s) (currently, m25p80_read()
uses 2 spi_transfers per message, where the first one contains opcode +
address + dummy on a single line, and the second transfer receives the
data on 1, 2, or 4 lines).
> And there is no
> info indicating capabilities of spi-master wrt no of IO lines for
> opcode/address/data that it can support.
For a true SPI controller, there is no need to specify something
different for opcode/address/data, since all those are treated the same;
they're just bits on 1, 2, or 4 lines. So the SPI_{TX,RX}_{DUAL,QUAD}
mode flags in struct spi_master tell m25p80 all it needs to know.
> >There are typically both flash device and SPI controller constraints
> >on this question, so there needs to be some kind of negotiation
> >involved, I expect. Or at least, the SPI master needs to expose which
> >modes it can support with this flash-read API.
> >
>
> If spi-master capabilities are known
For generic SPI handling, these are already known. But now you're adding
flash-specific capabilities, and I'm not going to assume that all
accelerated-read (e.g., your TI mmap'ed flash read) support all the same
modes as your generic modes.
So, which modes does your mmap'ed read handle? 1/1/1? 1/1/2? 1/1/4?
4/4/4? (where x/y/z means x lines for opcode, y lines for address, and z
lines for data)
> then spi_mmap_read_supported() (or
> a new function perhaps) can be used for negotiation. These capabilities
> can be added incr
RE: [PATCH 2/2 V2] drivers/gpio: Port gpio driver to layerscape platform
Hi, Arnd, Do you have more comments for the V2 patch, or could you please ack the patch? Thanks! Liu Gang -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Hi Brain,
On 11/11/2015 4:53 AM, Brian Norris wrote:
> Hi Vignesh,
>
> Sorry for the late review. I did not have time to review much back when
> you submitted your first RFCs for this.
>
> On Tue, Nov 10, 2015 at 10:59:55AM +0530, Vignesh R wrote:
>> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
>> index cce80e6dc7d1..2f2c431b8917 100644Hi
>> --- a/include/linux/spi/spi.h
>> +++ b/include/linux/spi/spi.h
>> @@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct
>> spi_driver *sdrv)
>> * @handle_err: the subsystem calls the driver to handle an error that
>> occurs
>> * in the generic implementation of transfer_one_message().
>> * @unprepare_message: undo any work done by prepare_message().
>> + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory.
>> + * Flash drivers (like m25p80) can request memory
>> + * mapped read via this method. This interface
>> + * should only be used by mtd flashes and cannot be
>> + * used by other spi devices.
>> * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
>> * number. Any individual value may be -ENOENT for CS lines that
>> * are not GPIOs (driven by the SPI controller itself).
>> @@ -507,6 +512,11 @@ struct spi_master {
>> struct spi_message *message);
>> int (*unprepare_message)(struct spi_master *master,
>> struct spi_message *message);
>> +int (*spi_mtd_mmap_read)(struct spi_device *spi,
>> + loff_t from, size_t len,
>> + size_t *retlen, u_char *buf,
>> + u8 read_opcode, u8 addr_width,
>> + u8 dummy_bytes);
>
> Is this API really sufficient? There are actually quite a few other
> flash-related parameters that might be relevant to a controller. I
> presume you happen not hit them because of the particular cases you're
> using this for right now, but:
>
> * How many I/O lines are being used? These can vary depending on the
>type of flash and the number of I/O lines supported by the controller
>and connected on the board.
>
This API communicates whatever data is currently communicated via
spi_message through spi_sync/transfer_one interfaces.
> * The previous point can vary across parts of the message. There are
>various combinations of 1/2/4 lines used for opcode/address/data. We
>only support a few of those combinations in m25p80 right now, but
>you're not specifying any of that in this API. I guess you're just
>making assumptions? (BTW, I think there are others having problems
>with the difference between different "quad" modes on Micron flash; I
>haven't sorted through all the discussion there.)
>
How is the spi controller currently being made aware of this via
m25p80_read / spi_sync() interface? AFAIK, mode field of spi_device
struct tell whether to do normal/dual/quad read but there is no info
communicated wrt 1/2/4 opcode/address/data combinations. And there is no
info indicating capabilities of spi-master wrt no of IO lines for
opcode/address/data that it can support.
>There are typically both flash device and SPI controller constraints
>on this question, so there needs to be some kind of negotiation
>involved, I expect. Or at least, the SPI master needs to expose which
>modes it can support with this flash-read API.
>
If spi-master capabilities are known then spi_mmap_read_supported() (or
a new function perhaps) can be used for negotiation. These capabilities
can be added incrementally once ability to specify spi-master
capabilities are in place.
> Also, this API doesn't actually have anything to do with memory mapping.
> It has to do with the de facto standard flash protocol. So I don't think
> mmap belongs in the name; it should be something about flash. (I know of
> at least one other controller that could probably use this API, excpet
> it doesn't use memory mapping to accomplish the accelerated flash read.)
>
As far as TI QSPI controller is concerned, the accelerated read happens
via mmap port whereby a predefined memory address space of SoC is
exposed as QSPI mmap region. This region can be accessed like normal
RAM(via memcpy()) and the QSPI controller interface takes care of
fetching data from flash on SPI bus automatically hence, I named it as
above. But, I have no hard feelings if it needs to be generalized to
spi_mtd_read() or something else.
Regards
Vignesh
--
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/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos,
> > Tacs.
> > +Each value is specified in cycles and has the
> > following
> > +meaning and valid range:
> > +Tacp : Page mode access cycle at Page mode (0 - 15)
> > +Tcah : Address holding time after CSn (0 - 15)
> > +Tcoh : Chip selection hold on OEn (0 - 15)
> > +Tacc : Access cycle (0 - 31, the actual time is N
> > + 1)
> > +Tcos : Chip selection set-up before OEn (0 - 15)
> > +Tacs : Address set-up before CSn (0 - 15)
>
> This is not easily extended. Perhaps a property per value instead.
We had a discussion with Krzysztof about it, he agreed with this form of the
property.
My concern was that it's just too much typing, and makes little sense because
these
settings always go together. If register layout changes, or parameter set
changes in
incompatible way, then it's another device, not exynos-srom anymore.
So would you agree with that, or is your position strong?
> > compatible = "samsung,exynos-srom";
> > - reg = <0x1257 0x10>;
> > + reg = <0x1257 0x14>;
> > +
> > + ethernet@3 {
> > + compatible = "smsc,lan9115";
> > + reg = <3 0 0x1>; // Bank 3, offset = 0
> > + phy-mode = "mii";
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-config = <1 9 12 1 9 1 1>;
>
> This doesn't match the doc.
Damn, overlooked. :(
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 v3 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288
Crypto driver support:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.
And other algorithms and platforms will be added later on.
Signed-off-by: Zain Wang
---
Changed in v3:
- add OF depended in Kconfig
- remove crypto_p variate
- fix of_device_id
- add reset property
Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type
Changde in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile| 1 +
drivers/crypto/rockchip/Makefile | 3 +
drivers/crypto/rockchip/rk3288_crypto.c| 392 +++
drivers/crypto/rockchip/rk3288_crypto.h| 220 +
drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 527 +
6 files changed, 1154 insertions(+)
create mode 100644 drivers/crypto/rockchip/Makefile
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..e5451b6 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_ROCKCHIP
+ tristate "Rockchip's Cryptographic Engine driver"
+ depends on OF && ARCH_ROCKCHIP
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+
+ help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..bb36baa
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,392 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int rk_crypto_enable_clk(struct rk_crypto_info *dev)
+{
+ int err;
+
+ err = clk_prepare_enable(dev->sclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
+ __func__, __LINE__);
+ goto err_return;
+ }
+ err = clk_prepare_enable(dev->aclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+ __func__, __LINE__);
+ goto err_aclk;
+ }
+ err = clk_prepare_enable(dev->hclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+ __func__, __LINE__);
+ goto err_hclk;
+ }
+
+ err = clk_prepare_enable(dev->dmaclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
+ __func__, __LINE__);
+ goto err_dmaclk;
+ }
+ return err;
+err_dmaclk:
+ clk_disable_unprepare(dev->hclk);
+err_hclk:
+ clk_disable_unprepare(dev->aclk);
+err_aclk:
+ clk_disable_unprepare(dev->sclk);
+err_return:
+ return err;
+}
+
+static void rk_crypto_disable_clk(struct rk_crypto_info *dev)
+{
+ clk_disable_unprepare(dev->dmaclk);
+ clk_disable_unprepare(dev->hclk);
+ clk_disable_unprepare(dev->aclk);
+ clk_disable_unprepare(dev->sclk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+
[PATCH v3 2/4] clk: rockchip: set an ID for crypto clk
Set an ID for crypto clk, so that it can be called in other part.
Signed-off-by: Zain Wang
---
Changed in v3:
- None
Changed in v2:
- None
Changed in v1:
- define SCLK_CRYPTO in rk3288-cru.h
- use SCLK_CRYPTO instead of SRST_CRYPTO
drivers/clk/rockchip/clk-rk3288.c | 2 +-
include/dt-bindings/clock/rk3288-cru.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
- COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+ COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
#define SCLK_USBPHY480M_SRC122
#define SCLK_PVTM_CORE 123
#define SCLK_PVTM_GPU 124
+#define SCLK_CRYPTO125
#define SCLK_MAC 151
#define SCLK_MACREF_OUT152
--
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 v3 4/4] ARM: dts: rockchip: Add Crypto node for rk3288
Add Crypto node for rk3288 including crypto controller and dma clk.
Signed-off-by: Zain Wang
---
Changed in v3:
- add reset property
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
arch/arm/boot/dts/rk3288.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..f0d1217 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -778,6 +778,18 @@
status = "disabled";
};
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+ clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ resets = <&cru SRST_CRYPTO>;
+ reset-names = "crypto-rst";
+ status = "okay";
+ };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
--
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 v3 0/4] crypto: add crypto accelerator support for rk3288
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc), and the more algorithms and new hash drivers will be added later on. Changed in v3: - add OF depended in Kconfig - rename some variate - add reset property - remove crypto_p variate Changed in v2: - remove some part about hash - add weak key detection - changed some variate's type Changed in v1: - modify some variate's name - modify some variate's type - modify some return value - remove or modify some print info - use more dev_xxx in probe - modify the prio of cipher - add Kconfig Zain Wang (4): crypto: rockchip/crypto - add DT bindings documentation clk: rockchip: set an ID for crypto clk Crypto: rockchip/crypto - add crypto driver for rk3288 ARM: dts: rockchip: Add Crypto node for rk3288 .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++ arch/arm/boot/dts/rk3288.dtsi | 12 + drivers/clk/rockchip/clk-rk3288.c | 2 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/rockchip/Makefile | 3 + drivers/crypto/rockchip/rk3288_crypto.c| 392 +++ drivers/crypto/rockchip/rk3288_crypto.h| 220 + drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 527 + include/dt-bindings/clock/rk3288-cru.h | 1 + 10 files changed, 1197 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt create mode 100644 drivers/crypto/rockchip/Makefile create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.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
[PATCH v3 1/4] crypto: rockchip/crypto - add DT bindings documentation
Add DT bindings documentation for the rk3288 crypto drivers.
Signed-off-by: Zain Wang
---
Changed in v3:
- add reset property
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
- remove the description of status
.../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..096df34
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: Base physical address of the engine and length of memory mapped
+ region
+- interrupts: Interrupt number
+- clocks: Reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+ "hclk" used to clock data
+ "sclk" used to clock crypto accelerator
+ "apb_pclk" used to clock dma
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the name "crypto-rst".
+
+Examples:
+
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+ clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ resets = <&cru SRST_CRYPTO>;
+ reset-names = "crypto-rst";
+ status = "okay";
+ };
--
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 v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
---
Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
Moved MSI functionality to separate functions.
Changed error return values.
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
drivers/pci/host/Kconfig | 16 +-
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1062
4 files changed, 1144 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+ configuration sapce, and length
+- reg-names: Must include the following entries:
+ "breg": bridge registers
+ "pcireg": PCIe controller registers
+ "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+ "msi1, msi0": interrupt asserted when msi is received
+ "intx": interrupt that is asserted when an legacy interrupt is received
+ "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+ mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+ Please refer to the standard PCI bus binding document for a more
+ detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent: MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy
interrupts
+ - interrupt-controller: identifies the node as an interrupt controller
+ - #interrupt-cells: should be set to 1
+ - #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "xlnx,nwl-pcie-2.11";
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <&gic>;
+ interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+ interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+ <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+ <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+ <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+ msi-parent = <&nwl_pcie>;
+ reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x0200 0x 0xe100 0x 0xe100 0
0x0f00>;
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..39799cf 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,12 +15,22 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
+config PCIE_XILINX_NWL
+ bool "NWL PCIe Core"
+ depends on ARCH_ZYNQMP
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
config PCIE_DW
- bool
+bool
config PCI_EXYNOS
- bool "Samsung Exynos PCIe controller"
- depends on SOC_EXYNOS5440
+bool "Samsung Exynos PCIe controller"
+depends on SOC_EXYNOS5440
select PCIEPORTBUS
select PCIE_DW
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/dri
Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port
On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> This fixes a bug where if you disconnect and re-connect the USB cable,
> the gadget driver stops working.
>
> Add support for async_irq to wake up driver from low power mode.
> Without this, the power management code never calls resume.
> Also, have the phy driver kick the gadget driver (chipidea otg)
> by having the chipidea driver register with it, for vbus connect
> notifications.
>
> Signed-off-by: Tim Bird
> ---
> drivers/usb/chipidea/udc.c| 6 ++
> drivers/usb/phy/phy-msm-usb.c | 16
> include/linux/usb/msm_hsusb.h | 1 +
> 3 files changed, 23 insertions(+)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 8223fe7..06234cd 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
>
> ci->gadget.ep0 = &ci->ep0in->ep;
>
> + if (ci->usb_phy) {
> + retval = otg_set_peripheral(ci->usb_phy->otg, &ci->gadget);
> + if (retval)
> + goto destroy_eps;
> + }
> +
> retval = usb_add_gadget_udc(dev, &ci->gadget);
> if (retval)
> goto destroy_eps;
Although it looks no affect for other drivers, it is better you
can split patches between controller and phy, then I can have a test.
In fact, most of phy-msm-usb.c's implementations (except USB PHY related)
are included in chipidea drivers, hope you can try it in future.
> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> index 80eb991..eb80f92 100644
> --- a/drivers/usb/phy/phy-msm-usb.c
> +++ b/drivers/usb/phy/phy-msm-usb.c
> @@ -1731,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
> return motg->irq;
> }
>
> + motg->async_irq = platform_get_irq_byname(pdev, "async_irq");
> + if (motg->async_irq < 0) {
> + dev_info(&pdev->dev, "platform_get_irq for async_irq failed\n");
> + motg->async_irq = 0;
> + }
> +
dev_err
> regs[0].supply = "vddcx";
> regs[1].supply = "v3p3";
> regs[2].supply = "v1p8";
> @@ -1780,6 +1786,16 @@ static int msm_otg_probe(struct platform_device *pdev)
> goto disable_ldo;
> }
>
> + if (motg->async_irq) {
> + ret = devm_request_irq(&pdev->dev, motg->async_irq,
> + msm_otg_irq, IRQF_TRIGGER_RISING,
> + "msm_otg", motg);
> + if (ret) {
> + dev_err(&pdev->dev, "request irq failed (ASYNC INT)\n");
> + goto disable_ldo;
> + }
> + }
> +
> phy->init = msm_phy_init;
> phy->set_power = msm_otg_set_power;
> phy->notify_disconnect = msm_phy_notify_disconnect;
> diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
> index 8c8f685..08c67a3 100644
> --- a/include/linux/usb/msm_hsusb.h
> +++ b/include/linux/usb/msm_hsusb.h
> @@ -164,6 +164,7 @@ struct msm_otg {
> struct usb_phy phy;
> struct msm_otg_platform_data *pdata;
> int irq;
> + int async_irq;
> struct clk *clk;
> struct clk *pclk;
> struct clk *core_clk;
> --
> 1.8.2.2
>
--
Best Regards,
Peter Chen
--
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 V3 2/5] PM / OPP: Add {opp-microvolt|opp-microamp}- binding
Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.
In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-.
The can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-
- opp-microamp-
If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the - string, if they are
available.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 47 +++
1 file changed, 47 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index d072fa0ffbd4..a3e7f0d5e1fb 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -100,6 +100,14 @@ properties.
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.
+- opp-microvolt-: Named opp-microvolt property. This is exactly similar
to
+ the above opp-microvolt property, but allows multiple voltage ranges to be
+ provided for the same OPP. At runtime, the platform can pick a and
+ matching opp-microvolt- property will be enabled for all OPPs. If the
+ platform doesn't pick a specific or the doesn't match with any
+ opp-microvolt- properties, then opp-microvolt property shall be used,
if
+ present.
+
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
@@ -112,6 +120,9 @@ properties.
for few regulators, then this should be marked as zero for them. If it isn't
required for any regulator, then this property need not be present.
+- opp-microamp-: Named opp-microamp property. Similar to
+ opp-microvolt- property, but for microamp instead.
+
- clock-latency-ns: Specifies the maximum possible transition latency (in
nanoseconds) for switching to this OPP from any other OPP.
@@ -528,3 +539,39 @@ Example 6: opp-supported-hw
};
};
};
+
+Example 7: opp-microvolt-, opp-microamp-:
+(example: device with two possible microvolt ranges: slow and fast)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ operating-points-v2 = <&cpu0_opp_table>;
+ };
+ };
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt-slow = <90 915000 925000>;
+ opp-microvolt-fast = <97 975000 985000>;
+ opp-microamp-slow = <7>;
+ opp-microamp-fast = <71000>;
+ };
+
+ opp01 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt-slow = <90 915000 925000>, /* Supply
vcc0 */
+ <91 925000 935000>; /* Supply
vcc1 */
+ opp-microvolt-fast = <97 975000 985000>, /* Supply
vcc0 */
+<96 965000 975000>; /* Supply
vcc1 */
+ opp-microamp = <7>; /* Will be used for both
slow/fast */
+ };
+ };
+};
--
2.6.2.198.g614a2ac
--
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 V3 3/5] PM / OPP: Remove 'operating-points-names' binding
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 62 +--
1 file changed, 2 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index a3e7f0d5e1fb..24eac9a97749 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their
"operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
-Devices may want to choose OPP tables at runtime and so can provide a list of
-phandles here. But only *one* of them should be chosen at runtime. This must be
-accompanied by a corresponding "operating-points-names" property, to uniquely
-identify the OPP tables.
-
If required, this can be extended for SoC vendor specfic bindings. Such
bindings
should be documented as
Documentation/devicetree/bindings/power/-opp.txt
and should have a compatible description like: "operating-points-v2-".
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
- tables are present), to uniquely identify them. The same list must be present
- for all the CPUs which are sharing clock/voltage rails and hence the OPP
- tables.
-
* OPP Table Node
This describes the OPPs belonging to a device. This node can have following
@@ -448,54 +437,7 @@ Example 4: Handling multiple regulators
};
};
-Example 5: Multiple OPP tables
-
-/ {
- cpus {
- cpu@0 {
- compatible = "arm,cortex-a7";
- ...
-
- cpu-supply = <&cpu_supply>
- operating-points-v2 = <&cpu0_opp_table_slow>,
<&cpu0_opp_table_fast>;
- operating-points-names = "slow", "fast";
- };
- };
-
- cpu0_opp_table_slow: opp_table_slow {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp00 {
- opp-hz = /bits/ 64 <6>;
- ...
- };
-
- opp01 {
- opp-hz = /bits/ 64 <8>;
- ...
- };
- };
-
- cpu0_opp_table_fast: opp_table_fast {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp10 {
- opp-hz = /bits/ 64 <10>;
- ...
- };
-
- opp11 {
- opp-hz = /bits/ 64 <11>;
- ...
- };
- };
-};
-
-Example 6: opp-supported-hw
+Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process)
/ {
@@ -540,7 +482,7 @@ Example 6: opp-supported-hw
};
};
-Example 7: opp-microvolt-, opp-microamp-:
+Example 6: opp-microvolt-, opp-microamp-:
(example: device with two possible microvolt ranges: slow and fast)
/ {
--
2.6.2.198.g614a2ac
--
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 V3 4/5] PM / OPP: Rename OPP nodes as opp@
It would be better to name OPP nodes as opp@ as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.
And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 24eac9a97749..601256fe8c0d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -177,20 +177,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch
DVFS states together.
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
clock-latency-ns = <29>;
@@ -256,20 +256,20 @@ independently.
* independently.
*/
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9;
@@ -332,20 +332,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9>;
@@ -358,20 +358,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp10 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <1045000 105 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <40>;
opp-suspend;
};
- opp11 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1075000>;
opp-microamp = <10>;
clock-latency-ns = <40>;
};
- opp12 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <101 110 111>;
opp-microamp = <95000>;
@@ -398,7 +398,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10
[PATCH V3 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Viresh Kumar
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 294cfe40388d..40beede46e55 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -64,73 +64,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp01 {
+ opp@3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp02 {
+ opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <925000>;
clock-latency-ns = <20>;
};
- opp03 {
+ opp@5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <95>;
clock-latency-ns = <20>;
};
- opp04 {
+ opp@6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <975000>;
clock-latency-ns = <20>;
};
- opp05 {
+ opp@7 {
opp-hz = /bits/ 64 <7>;
opp-microvolt = <987500>;
clock-latency-ns = <20>;
};
- opp06 {
+ opp@8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <100>;
clock-latency-ns = <20>;
opp-suspend;
};
- opp07 {
+ opp@9 {
opp-hz = /bits/ 64 <9>;
opp-microvolt = <1037500>;
clock-latency-ns = <20>;
};
- opp08 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1087500>;
clock-latency-ns = <20>;
};
- opp09 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <1137500>;
clock-latency-ns = <20>;
};
- opp10 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1187500>;
clock-latency-ns = <20>;
};
- opp11 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <125>;
clock-latency-ns = <20>;
};
- opp12 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1287500>;
clock-latency-ns = <20>;
};
- opp13 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <135>;
clock-latency-ns = <20>;
--
2.6.2.198.g614a2ac
--
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 V3 1/5] PM / OPP: Add "opp-supported-hw" binding
We may want to enable only a subset of OPPs, from the bigger list of
OPPs, based on what version of the hardware we are running on. This
would enable us to not duplicate OPP tables for every version of the
hardware we support.
To enable that, this patch defines a new property 'opp-supported-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 65 +++
1 file changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 0cb44dc21f97..d072fa0ffbd4 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -123,6 +123,26 @@ properties.
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-supported-hw: This enables us to select only a subset of OPPs from the
+ larger OPP table, based on what version of the hardware we are running on. We
+ still can't have multiple nodes with the same opp-hz value in OPP table.
+
+ It's an user defined array containing a hierarchy of hardware version
numbers,
+ supported by the OPP. For example: a platform with hierarchy of three levels
+ of versions (A, B and C), this field should be like , where X
+ corresponds to Version hierarchy A, Y corresponds to version hierarchy B and
Z
+ corresponds to version hierarchy C.
+
+ Each level of hierarchy is represented by a 32 bit value, and so there can be
+ only 32 different supported version per hierarchy. i.e. 1 bit per version. A
+ value of 0x will enable the OPP for all versions for that hierarchy
+ level. And a value of 0x will disable the OPP completely, and so we
+ never want that to happen.
+
+ If 32 values aren't sufficient for a version hierarchy, than that version
+ hierarchy can be contained in multiple 32 bit values. i.e. in the
+ above example, Z1 & Z2 refer to the version hierarchy Z.
+
- status: Marks the node enabled/disabled.
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -463,3 +483,48 @@ Example 5: Multiple OPP tables
};
};
};
+
+Example 6: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process)
+
+/ {
+ 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 process versions for 0xF
+* cuts, i.e. only first four cuts.
+*/
+ opp-supported-hw = <0xF 0x 0x>
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+
+ opp01 {
+ /*
+* Supports:
+* - cuts: only one, 6th cut (represented by 6th bit).
+* - substrate: supports 16 different substrate versions
+* - process: supports 9 different process versions
+*/
+ opp-supported-hw = <0x20 0xffff 0xf4f0>
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+ };
+};
--
2.6.2.198.g614a2ac
--
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 V3 0/5] PM / OPP: opp-supported-hw and -name bindings
Hi Rafael,
Rob only needs to Ack the modified 2/5 patch and then you can safely
apply this series.
The first patch enables us to select only a subset of OPPs from the
bigger table, based on what version of the hardware we are running on.
The second one enables us to select slightly different values for
multiple properties, based on what kind of hardware they are running on.
The third one removes an (unused) binding, which is replaced by the
second patch with a better solution.
The fourth patch is based on what Stephen suggested (and then reviewed)
in the earlier series, and the 5th one updates the existing users of
these bindings for it.
V2->V3:
- dropped turbo/suspend named properties
- Applied all the Acks
Viresh Kumar (5):
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add {opp-microvolt|opp-microamp}- binding
PM / OPP: Remove 'operating-points-names' binding
PM / OPP: Rename OPP nodes as opp@
ARM: dts: exynos4412: Rename OPP nodes as opp@
Documentation/devicetree/bindings/opp/opp.txt | 132 ++
arch/arm/boot/dts/exynos4412.dtsi | 28 +++---
2 files changed, 107 insertions(+), 53 deletions(-)
--
2.6.2.198.g614a2ac
--
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: [kbuild-all] [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver
Hi Sinan,
Sorry please ignore this warning -- it's actually a problem specific
to the mn10300 arch. I'll disable such warning in mn10300 in future.
Thanks,
Fengguang
On Sun, Nov 08, 2015 at 07:43:52PM -0500, Sinan Kaya wrote:
>
>
> On 11/8/2015 2:13 PM, kbuild test robot wrote:
> >Hi Sinan,
> >
> >[auto build test WARNING on: robh/for-next]
> >[also build test WARNING on: v4.3 next-20151106]
> >
> >url:
> >https://github.com/0day-ci/linux/commits/Sinan-Kaya/ma-add-Qualcomm-Technologies-HIDMA-driver/20151108-125824
> >base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
> >config: mn10300-allyesconfig (attached as .config)
> >reproduce:
> > wget
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=mn10300
> >
> >All warnings (new ones prefixed by >>):
> >
> >In file included from include/linux/printk.h:277:0,
> > from include/linux/kernel.h:13,
> > from include/linux/list.h:8,
> > from include/linux/kobject.h:20,
> > from include/linux/device.h:17,
> > from include/linux/dmaengine.h:20,
> > from drivers/dma/qcom/hidma.c:45:
> >drivers/dma/qcom/hidma.c: In function 'hidma_prep_dma_memcpy':
> >include/linux/dynamic_debug.h:64:16: warning: format '%zu' expects
> > argument of type 'size_t', but argument 7 has type 'unsigned int'
> > [-Wformat=]
> > static struct _ddebug __aligned(8) \
> >^
> >include/linux/dynamic_debug.h:84:2: note: in expansion of macro
> > 'DEFINE_DYNAMIC_DEBUG_METADATA'
> > DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> > ^
> >include/linux/device.h:1171:2: note: in expansion of macro
> > 'dynamic_dev_dbg'
> > dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
> > ^
> >>>drivers/dma/qcom/hidma.c:391:2: note: in expansion of macro 'dev_dbg'
> > dev_dbg(mdma->ddev.dev,
> > ^
> >
> >vim +/dev_dbg +391 drivers/dma/qcom/hidma.c
> >
> >375
> >376 mchan->allocated = 0;
> >377 spin_unlock_irqrestore(&mchan->lock, irqflags);
> >378 dev_dbg(mdma->ddev.dev, "freed channel for %u\n",
> > mchan->dma_sig);
> >379 }
> >380
> >381
> >382 static struct dma_async_tx_descriptor *
> >383 hidma_prep_dma_memcpy(struct dma_chan *dmach, dma_addr_t
> > dma_dest,
> >384 dma_addr_t dma_src, size_t len,
> > unsigned long flags)
> >385 {
> >386 struct hidma_chan *mchan = to_hidma_chan(dmach);
> >387 struct hidma_desc *mdesc = NULL;
> >388 struct hidma_dev *mdma = mchan->dmadev;
> >389 unsigned long irqflags;
> >390
> > > 391 dev_dbg(mdma->ddev.dev,
> >392 "memcpy: chan:%p dest:%pad src:%pad len:%zu\n",
> > mchan,
> >393 &dma_dest, &dma_src, len);
> >394
>
> What am I missing?
>
> len is size_t. This page says use %zu for size_t.
>
> https://www.kernel.org/doc/Documentation/printk-formats.txt
>
>
>
> >395 /* Get free descriptor */
> >396 spin_lock_irqsave(&mchan->lock, irqflags);
> >397 if (!list_empty(&mchan->free)) {
> >398 mdesc = list_first_entry(&mchan->free, struct
> > hidma_desc,
> >399 node);
> >
> >---
> >0-DAY kernel test infrastructureOpen Source Technology Center
> >https://lists.01.org/pipermail/kbuild-all Intel Corporation
> >
>
>
>
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
--
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 RESEND 15/16] leds: add LM3633 driver
Hi Jacek,
On 11/10/2015 10:44 PM, Jacek Anaszewski wrote:
+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
>>>+ struct device_attribute *attr,
>>>+ const char *buf, size_t len)
>>>+{
>>>+struct ti_lmu_led *lmu_led = to_ti_lmu_led(dev);
>>>+struct ti_lmu_led_chip *chip = lmu_led->chip;
>>>+unsigned int low, high;
>>>+u8 reg, offset, val;
>>>+int ret;
>>>+
>>>+/*
>>>+ * Sequence
>>>+ *
>>>+ * 1) Read pattern level data
>>>+ * 2) Disable a bank before programming a pattern
>>>+ * 3) Update LOW BRIGHTNESS register
>>>+ * 4) Update HIGH BRIGHTNESS register
>>>+ *
>>>+ * Level register addresses have offset number based on the LED
>>>bank.
>>>+ */
>>>+
>>>+ret = sscanf(buf, "%u %u", &low, &high);
>>>+if (ret != 2)
>>>+return -EINVAL;
>>>+
>>>+low = min_t(unsigned int, low, LM3633_LED_MAX_BRIGHTNESS);
>>
>>Why don't you take into account the value defined by led-max-microamp
>>DT property here?
>
>'low' and 'high' are brightness value. The range is from 0 to 255. It is
>mostly related with LED sysfs -/sys/class/led//brightness.
>On the other hand, led-max-microamp is current limit. It is from 5mA to
>30mA. It's different configuration in this device.
Doesn't the current has direct influence on the LED brightness?
Are there other means for adjusting brightness than current setting?
I see in your enum ti_lmu_max_current, that there are 26 possible
current levels. I think that they should reflect 26 possible
brightness levels, so max_brightness can be at most 26.
Let me describe LM3633 in more details. I'd like to have your opinion
about led-max-microamp and max_brightness usages. Datasheet would be
better to figure out characteristics.
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Max current level is not same as brightness level in LM3633.
LM3633 device has two parameters for output brightness control.
One is brightness code(base register address is 0x44). The other is
current limit(base register address is 0x22). It also provides hardware
protection like excessive current.
0 <= brightness_code <= 0xff
0 <= current_limit_code <= 0x1f, it means
5mA <= current_limit <= 30mA.
LM3633 device calculates the output current below.
(1) Linear brightness mode
Iout = current_limit * brightness_code/255
(2) Exponential brightness mode
Iout = current_limit * 0.85 ^ (44 - (brightness_code + 1)/5.18)
So output current(Iout) can not be in excess of current_limit.
led-max-microamp was designed for defining max brightness limit.
It should be converted into max brightness level in the driver and
assigned to max_brightness property of struct led_classdev.
This attribute overrides legacy 0-255 brightness scale.
It could be applied when brightness is determined by only one parameter
- current level. Flash/torch device would be a good example. In this
device, current setting is directly scaled to the output brightness.
However, LM3633 has two parameters for the brightness control - current
limit and brightness level. Max current setting is one of brightness
control parameters. In this patch, 'led-max-microamp' from DT is
converted to 'current_limit_code'. Then, this value is written once when
the driver is initialized. On the other hand, 'brightness_code' can be
changed at run time. And 'max_brightness' of led_classdev is set to max
brightness register value, 0xff.
It sounds 'led-max-microamp' property might not be a general usage in
LM3633. Do you have some idea?
Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Hi Eddie, [...] > I check the log [0], Thanks for checking into this boot failure. > it seems first time mt8135-evbp1 boot to kernel > shell successfully, then boot again. In the second time, mt8135 stay in > fastboot mode, waiting host send boot image, then timeout. Actually, it never gets to a shell the first time. If you look closely, the target reboots as soon as userspace starts. Look for the PYBOOT line which says "finished booting, starting userspace" Later on, pyboot thinks it finds a root shell due to finding '#' characters, but clearly it never got to a shell. > I download zImage and dtb in [1], and kernel run to shell successfully > on my platform. Are you can you try using a ramdisk as well? You can use the pre-built one here: http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz Please check my boot logs to see how I'm generating the boot.img file (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible that the kernel image size with a ramdisk is breaking some of the assumptions in the fastboot mode. I've seen problems like this on other platforms due to hard-coded sizes/addresses in the boot firmware. > I don't know whether this issue caused by test environment or not. I do not think it is the test environment, since as you can see from [1], it's booting just fine with mainline kernel, and was working fine until next-20151102. Kevin [1] http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151110/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5642652759b5149878091908 -- 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] Documentation: dt-bindings: add async_irq to msm_hsusb
Add optional async_irq to msm_hsusb binding doc.
Signed-off-by: Tim Bird
---
Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 8654a3e..7ba1dff 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -23,7 +23,12 @@ Required properties:
"qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
- regs: Offset and length of the register set in the memory map
-- interrupts: interrupt-specifier for the OTG interrupt.
+- interrupts: interrupt-specifier for the OTG interrupts
+
+- interrupt-names: Should contain the following:
+ "core_irq"USB core interrupt
+ "async_irq" Asynchronous interrupt to wake up from low power mode
+(optional)
- clocks: A list of phandle + clock-specifier pairs for the
clocks listed in clock-names
@@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
usb@f9a55000 {
compatible = "qcom,usb-otg-snps";
reg = <0xf9a55000 0x400>;
-interrupts = <0 134 0>;
+interrupts = <0 134 0>, <0 140 0>;
+interrupt-names = "core_irq", "async_irq";
dr_mode = "peripheral";
clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>,
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port
This fixes a bug where if you disconnect and re-connect the USB cable,
the gadget driver stops working.
Add support for async_irq to wake up driver from low power mode.
Without this, the power management code never calls resume.
Also, have the phy driver kick the gadget driver (chipidea otg)
by having the chipidea driver register with it, for vbus connect
notifications.
Signed-off-by: Tim Bird
---
drivers/usb/chipidea/udc.c| 6 ++
drivers/usb/phy/phy-msm-usb.c | 16
include/linux/usb/msm_hsusb.h | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..06234cd 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
ci->gadget.ep0 = &ci->ep0in->ep;
+ if (ci->usb_phy) {
+ retval = otg_set_peripheral(ci->usb_phy->otg, &ci->gadget);
+ if (retval)
+ goto destroy_eps;
+ }
+
retval = usb_add_gadget_udc(dev, &ci->gadget);
if (retval)
goto destroy_eps;
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 80eb991..eb80f92 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1731,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
return motg->irq;
}
+ motg->async_irq = platform_get_irq_byname(pdev, "async_irq");
+ if (motg->async_irq < 0) {
+ dev_info(&pdev->dev, "platform_get_irq for async_irq failed\n");
+ motg->async_irq = 0;
+ }
+
regs[0].supply = "vddcx";
regs[1].supply = "v3p3";
regs[2].supply = "v1p8";
@@ -1780,6 +1786,16 @@ static int msm_otg_probe(struct platform_device *pdev)
goto disable_ldo;
}
+ if (motg->async_irq) {
+ ret = devm_request_irq(&pdev->dev, motg->async_irq,
+ msm_otg_irq, IRQF_TRIGGER_RISING,
+ "msm_otg", motg);
+ if (ret) {
+ dev_err(&pdev->dev, "request irq failed (ASYNC INT)\n");
+ goto disable_ldo;
+ }
+ }
+
phy->init = msm_phy_init;
phy->set_power = msm_otg_set_power;
phy->notify_disconnect = msm_phy_notify_disconnect;
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 8c8f685..08c67a3 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -164,6 +164,7 @@ struct msm_otg {
struct usb_phy phy;
struct msm_otg_platform_data *pdata;
int irq;
+ int async_irq;
struct clk *clk;
struct clk *pclk;
struct clk *core_clk;
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices
Hi Vignesh,
Sorry for the late review. I did not have time to review much back when
you submitted your first RFCs for this.
On Tue, Nov 10, 2015 at 10:59:55AM +0530, Vignesh R wrote:
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index cce80e6dc7d1..2f2c431b8917 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct
> spi_driver *sdrv)
> * @handle_err: the subsystem calls the driver to handle an error that occurs
> * in the generic implementation of transfer_one_message().
> * @unprepare_message: undo any work done by prepare_message().
> + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory.
> + * Flash drivers (like m25p80) can request memory
> + * mapped read via this method. This interface
> + * should only be used by mtd flashes and cannot be
> + * used by other spi devices.
> * @cs_gpios: Array of GPIOs to use as chip select lines; one per CS
> * number. Any individual value may be -ENOENT for CS lines that
> * are not GPIOs (driven by the SPI controller itself).
> @@ -507,6 +512,11 @@ struct spi_master {
> struct spi_message *message);
> int (*unprepare_message)(struct spi_master *master,
>struct spi_message *message);
> + int (*spi_mtd_mmap_read)(struct spi_device *spi,
> + loff_t from, size_t len,
> + size_t *retlen, u_char *buf,
> + u8 read_opcode, u8 addr_width,
> + u8 dummy_bytes);
Is this API really sufficient? There are actually quite a few other
flash-related parameters that might be relevant to a controller. I
presume you happen not hit them because of the particular cases you're
using this for right now, but:
* How many I/O lines are being used? These can vary depending on the
type of flash and the number of I/O lines supported by the controller
and connected on the board.
* The previous point can vary across parts of the message. There are
various combinations of 1/2/4 lines used for opcode/address/data. We
only support a few of those combinations in m25p80 right now, but
you're not specifying any of that in this API. I guess you're just
making assumptions? (BTW, I think there are others having problems
with the difference between different "quad" modes on Micron flash; I
haven't sorted through all the discussion there.)
There are typically both flash device and SPI controller constraints
on this question, so there needs to be some kind of negotiation
involved, I expect. Or at least, the SPI master needs to expose which
modes it can support with this flash-read API.
Also, this API doesn't actually have anything to do with memory mapping.
It has to do with the de facto standard flash protocol. So I don't think
mmap belongs in the name; it should be something about flash. (I know of
at least one other controller that could probably use this API, excpet
it doesn't use memory mapping to accomplish the accelerated flash read.)
>
> /*
>* These hooks are for drivers that use a generic implementation
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Print rather than WARN'ing when overlap check fails
On Tue, 2015-11-10 at 09:41 +, David Laight wrote: > From: Michael Ellerman > > Sent: 10 November 2015 05:09 > > __rmem_check_for_overlap() is called very early in boot, and on some > > powerpc systems it's not safe to call WARN that early in boot. > > > > If the overlap check fails the system will oops instead of printing a > > warning. Furthermore because it's so early in boot the console is not up > > and the user doesn't see the oops, they just get a dead system. > > Wouldn't it be better to add the required checks to WARN()? Yes obviously it would. But that's less simple than it sounds. I'm working on it. cheers -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] of: Add vendor prefix for Advantech Corporation
On Tue, Nov 10, 2015 at 12:00 PM, Akshay Bhat wrote: > This patch adds vendor prefix for Advantech Corporation. > > Website: http://www.advantech.com/ > Signed-off-by: Akshay Bhat 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 55df1d4..5134b24 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -10,6 +10,7 @@ adAvionic Design GmbH > adapteva Adapteva, Inc. > adhAD Holdings Plc. > adiAnalog Devices, Inc. > +advantech Advantech Corporation > aeroflexgaislerAeroflex Gaisler AB > al Annapurna Labs > allwinner Allwinner Technology Co., Ltd. > -- > 2.6.3 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On 11/10/2015 12:44 PM, Mark Brown wrote: On Tue, Nov 10, 2015 at 11:52:12AM -0600, Andrew F. Davis wrote: Anyway, All I'm trying to do here is keep things clean in the DT. We only have one consistent option: No, not really. Match all sub parts by compatible: Or we end up with some hybrid approach, matching some on node name, others on compatible when needed. Yes, the above matches Linux device model (still not sure why that is such a problem?), but it also matches modular functionality in the device. There's also the third option where we don't have any compatible strings in the subnodes at all. Ok, two, but would you really want to go that way? Matching by node name costs us all of the flexibility of DT sub-device selection. Still don't see an upside as we would now be locked to node names instead of compatible strings to declare component type compatibility (what they are for). -- 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] iio: health: Add driver for the TI AFE4404 heart monitor
On 11/05/2015 01:09 PM, Jonathan Cameron wrote: Lars, Hartmut, Peter, This is becoming a really involved ABI discussion so I'd like some input on this if any of you have the time. I'm going to be busy now until at least the weekend... On 04/11/15 21:17, Andrew F. Davis wrote: On 11/04/2015 01:40 PM, Jonathan Cameron wrote: On 02/11/15 20:37, Andrew F. Davis wrote: On 11/01/2015 02:52 PM, Jonathan Cameron wrote: On 31/10/15 16:31, Andrew F. Davis wrote: Add driver for the TI AFE4404 heart rate monitor and pulse oximeter. This device detects reflected LED light fluctuations and presents an ADC value to the user space for further signal processing. Data sheet located here: http://www.ti.com/product/AFE4404/datasheet Signed-off-by: Andrew F. Davis Hi Andrew, Good to see this resurface. It's a fascinating little device. Anyhow, most of the interesting bit in here is unsuprisingly concerned with the interface. I know we went round a few loops of this before but it still feels like we haven't worked out to handle it well. I would like as much input as we can get on this as inevitablly it will have repercussions outside this driver. Your approach of hammering out descriptive sysfs attributes is a good starting point but we need to work towards a formal description that can be generalised. Whilst there are not many similar devices out there to this one, I suspect there are a few and more may well show up in future. Yeah, I'm working on brining up drivers for them now :) cool The escence of my rather roundabout response inline is that I'm suggesting adding a new channel type to represent light transmission, taking the analogous case of proximity devices in which we are looking at light reflection. I've also taken the justification we use for illuminance vs intensity readings for two sensor ALS sensors as a precident for having compound channels of a different type to the 'raw' data that feeds them. Hence I propose something along the lines of: in_intensityX_raw (raw channel value with the led on) in_intensityX_ambient_raw (raw channel value with the led off) I'm not sure, I know it may be too late for a lot of drivers but putting the 'X' against the 'intensity' works for devices like ADCs/DACs with a simple list of numeric channels, but for any other device with named channels this will become very inconsistent, especially when adding modified channels and differential channels. Sadly its ABI now so we can't realistically change it. We can extend, we can't replace (we we can over the course of a lot of years but that's a nightmare). For example: in_intensity5_name_ambient-2_mean_raw The oddity here is that in your case the device in interacting with a stimulus output. Normally the index reflects an actual sensor. We are kind of bludgeoning it in. The only equivalently nasty case I know of is touch screens where different resistances are being connected - from a generic point of view those are a nightmare as well (as every implementation does it differently). Yeah, this part really doesn't fit the mold for this subsystem, or any really, hwmon, input, were also considered, but the plan is still to attempt to shoehorn it in to this one, so hopefully you can bear with me on all these oddities :) Much as it irritates my sense of neat and tidy I guess that if we do end up with an ABI for this that we don't like later it isn't the end of the world as I doubt we'll be inundated with hundreds of these sensors. However, lets keep the naming within reason to how we would naturally extend the ABI. Having thought more on these differential channels, do we really need to have them explicitly as differential channels at all? Perhaps we are better off with in_intensity0_led1_raw in_intensity1_ambient_raw in_intensity2_transmitted_led1_raw in_intensity3_led2_raw in_intensity4_ambient_raw in_intensity5_transmitted_led2_raw in_intenisty6_led3_raw in_intenisty7_ambient_raw in_intensity8_transmitted_led3_raw in_intensity9_transmitted_led1_meanfiltered_raw (and it does want to be explicitly meanfiltered and not mean which would imply the mean over all time) in_intensity10_transmitted_led2_meanfiltered_raw It's simple, descriptive and almost fits in the current ABI - you could even blugeon it in easily enough except for the mean filtered case. In many ways this is your naming proposal after all. One issue might be that we really only have 4 real channels that become different things depending on how you setup the device. Matching the names of the registers is the only way we can label these, as the user might change their use. in_intensity_[RegName]_raw I really can't see any way around it, the channels are just to adjustable. This will really be true for the afe4300 driver, the part looks to have about 13 different measurement inputs it can take, all user-select multiplexed into 1 register/channel. :/ I really don't like the mean filtered case. My suggestion on that long
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Tue, Nov 10, 2015 at 11:52:12AM -0600, Andrew F. Davis wrote: > Anyway, All I'm trying to do here is keep things clean in the DT. We only have > one consistent option: No, not really. > Match all sub parts by compatible: > Or we end up with some hybrid approach, matching some on node name, others > on compatible when needed. Yes, the above matches Linux device model (still > not sure why that is such a problem?), but it also matches modular > functionality > in the device. There's also the third option where we don't have any compatible strings in the subnodes at all. signature.asc Description: PGP signature
Re: [PATCH v3 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation
On Tue, Nov 10, 2015 at 6:15 AM, Rob Herring wrote:
> On Mon, Nov 09, 2015 at 10:05:44AM -0800, Duc Dang wrote:
>> This adds the APM X-Gene SLIMpro mailbox device tree
>> node documentation.
>>
>> [dhdang: rebase over 4.3-rc5]
>> Signed-off-by: Feng Kan
>> Signed-off-by: Duc Dang
>> ---
>> .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34
>> ++
>> 1 file changed, 34 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>> b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>> new file mode 100644
>> index 000..d02a3d8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>> @@ -0,0 +1,34 @@
>> +The APM X-Gene SLIMpro mailbox is used to communicate messages between
>> +the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
>> +interrupt based door bell mechanism and can exchange simple messages using
>> the
>> +internal registers.
>> +
>> +There are total of 7 interrupts in this mailbox. Each used for an individual
>> +door bell (or mailbox channel).
>> +
>> +Required properties:
>> +- compatible:Should be as "apm, xgene-slimpro-mbox".
> ^
> remove the space
I will fix in next version of the patch.
>
>> +
>> +- reg: Contain the mailbox register address range.
>
> s/Contain/Contains/
Will change.
>
>> +
>> +- interrupts:7 interrupts must start from 0 to 6, interrupt 0
>> define the
>> + the interrupt for mailbox channel 0 and interrupt 1 for
>> + mailbox channel 1 and so likewise for the reminder.
>
> s/start/be/
Will change.
>
>> +
>> +- #mbox-cells: only one to specify the mailbox channel number.
>> +
>> +Example:
>> +
>> +Mailbox Node:
>> + slimpro-mbox: slimpro-mbox@1054 {
>> + compatible = "apm,xgene-slimpro-mbox";
>> + reg = <0x0 0x1054 0x0 0xa000>;
>> + #mbox-cells = <1>;
>> + interrupts =<0x0 0x0 0x4>,
>> + <0x0 0x1 0x4>,
>> + <0x0 0x2 0x4>,
>> + <0x0 0x3 0x4>,
>> + <0x0 0x4 0x4>,
>> + <0x0 0x5 0x4>,
>> + <0x0 0x6 0x4>,
>> + };
>> --
>> 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
Regards,
Duc Dang.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] thermal: mediatek: Add cpu power cooling model.
On Tue, Nov 10, 2015 at 11:20:18AM +, Javi Merino wrote: > On Fri, Nov 06, 2015 at 08:54:33AM +0530, Viresh Kumar wrote: > > Cc'ing Javi (which you should have as he wrote the power-thing for > > cpu-cooling). > > > > On 05-11-15, 19:10, dawei chien wrote: > > > This is because our platform currently only support mt8173_cpufreq.c, so > > > that I only add static power model for our owner IC. > > > > Bindings are (normally) supposed to be general than a platform > > specific. > > > > > Please understanding that I wouldn't give a DT binding document since I > > > will remove static power table on next version, but I can try to explain > > > it. > > > > Then just don't add things in the first place. > > > > > As far as I know, static power is somewhat leakage of CPU clusters, so > > > that we hardly to find a formula, which can suitable all kinds of CPUs > > > since leakage is different. In ARM IPA framework, static power only need > > > to be defined by who register cpufreq_power_cooling_register. The > > > voltage/power table is just one way to present leakage power of CPUs. > > > > The bindings don't fix the values for static power, but just provides > > a field for platforms to use. Everyone can then send its own power > > figures. Why do you thing it can't be generalized? > > The way they are described here is useful only for this platform, but > it's not generic. It only takes into account voltage as (I assume) > it's the only variable that affects it in this implementation. A > generalized version of the static power should take into account the > temperature and the idle state. Still, why would we have one binding to describe static power per platform? I would prefer we go towards a generalized binding description. If temperature is not needed on all platforms, make it an optional property. BR, Eduardo Valentin -- 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] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro
Hello Andrew,
On Sat, Oct 24, 2015 at 2:05 PM, Andrew F. Davis wrote:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments. AM33XX_IOPAD allows us to use part of the
> pinctrl physical address as in the TRM instead of an offset.
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/boot/dts/am335x-boneblack.dts | 44
> +-
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index eadbba3..346f529 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -36,32 +36,32 @@
> &am33xx_pinmux {
> nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
> pinctrl-single,pins = <
> - 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
> AM33XX_PIN_OUTPUT */
> - 0xa0 0x08 /* lcd_data0.lcd_data0,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa4 0x08 /* lcd_data1.lcd_data1,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa8 0x08 /* lcd_data2.lcd_data2,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xac 0x08 /* lcd_data3.lcd_data3,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb0 0x08 /* lcd_data4.lcd_data4,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb4 0x08 /* lcd_data5.lcd_data5,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb8 0x08 /* lcd_data6.lcd_data6,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xbc 0x08 /* lcd_data7.lcd_data7,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc0 0x08 /* lcd_data8.lcd_data8,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc4 0x08 /* lcd_data9.lcd_data9,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc8 0x08 /* lcd_data10.lcd_data10,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xcc 0x08 /* lcd_data11.lcd_data11,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd0 0x08 /* lcd_data12.lcd_data12,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd4 0x08 /* lcd_data13.lcd_data13,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd8 0x08 /* lcd_data14.lcd_data14,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xdc 0x08 /* lcd_data15.lcd_data15,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xe0 0x00 /* lcd_vsync.lcd_vsync,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> - 0xe4 0x00 /* lcd_hsync.lcd_hsync,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> - 0xe8 0x00 /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT */
> - 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> + AM33XX_IOPAD(0x9b0, (PIN_OUTPUT_PULLDOWN |
> MUX_MODE3)) /* xdma_event_intr0 */
I missed when I first reviewed this patch but there is no need to
enclose the padconf values into parenthesis, for example the following
is easier to read and is preferred IMHO:
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */
Same for all the other pinctrl lines.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Tue, Nov 10, 2015 at 12:05:54PM +, Javi Merino wrote:
> On Mon, Nov 09, 2015 at 11:13:32AM +0100, Sascha Hauer wrote:
> > +
> > +/*
> > + * The MT8173 thermal controller has four banks. Each bank can read up to
> > + * four temperature sensors simultaneously. The MT8173 has a total of 5
> > + * temperature sensors. We use each bank to measure a certain area of the
> > + * SoC. Since TS2 is located centrally in the SoC it is influenced by
> > multiple
> > + * areas, hence is used in different banks.
> > + */
> > +static const struct mtk_thermal_bank_cfg bank_data[] = {
> > + {
> > + .num_sensors = 2,
> > + .sensors = { MT8173_TS2, MT8173_TS3 },
> > + }, {
> > + .num_sensors = 2,
> > + .sensors = { MT8173_TS2, MT8173_TS4 },
> > + }, {
> > + .num_sensors = 3,
> > + .sensors = { MT8173_TS1, MT8173_TS2, MT8173_TSABB },
> > + }, {
> > + .num_sensors = 1,
> > + .sensors = { MT8173_TS2 },
> > + },
> > +};
Would it make sense to simply expose all sensors and let the
configuration of their aggregation be done by DT?
There is already ongoing effort to get aggregation functions
generalized.
> > +
> > +struct mtk_thermal_sense_point {
> > + int msr;
> > + int adcpnp;
> > +};
> > +
> > +static const struct mtk_thermal_sense_point
> > + sensing_points[MT8173_NUM_SENSORS_PER_ZONE] = {
> > + {
> > + .msr = TEMP_MSR0,
> > + .adcpnp = TEMP_ADCPNP0,
> > + }, {
> > + .msr = TEMP_MSR1,
> > + .adcpnp = TEMP_ADCPNP1,
> > + }, {
> > + .msr = TEMP_MSR2,
> > + .adcpnp = TEMP_ADCPNP2,
> > + }, {
> > + .msr = TEMP_MSR3,
> > + .adcpnp = TEMP_ADCPNP3,
> > + },
> > +};
> > +
> > +/**
> > + * raw_to_mcelsius - convert a raw ADC value to mcelsius
> > + * @mt:The thermal controller
> > + * @raw: raw ADC value
> > + *
> > + * This converts the raw ADC value to mcelsius using the SoC specific
> > + * calibration constants
> > + */
> > +static int raw_to_mcelsius(struct mtk_thermal *mt, int sensno, s32 raw)
> > +{
> > + s32 tmp;
> > +
> > + raw &= 0xfff;
> > +
> > + tmp = 203450520 << 3;
> > + tmp /= 165 + mt->o_slope;
> > + tmp /= 1 + mt->adc_ge;
> > + tmp *= raw - mt->vts[sensno] - 3350;
> > + tmp >>= 3;
> > +
> > + return mt->degc_cali * 500 - tmp;
> > +}
> > +
> > +/**
> > + * mtk_thermal_get_bank - get bank
> > + * @bank: The bank
> > + *
> > + * The bank registers are banked, we have to select a bank in the
> > + * PTPCORESEL register to access it.
> > + */
> > +static void mtk_thermal_get_bank(struct mtk_thermal_bank *bank)
> > +{
> > + struct mtk_thermal *mt = bank->mt;
> > + u32 val;
> > +
> > + mutex_lock(&mt->lock);
> > +
> > + val = readl(mt->thermal_base + PTPCORESEL);
> > + val &= ~0xf;
> > + val |= bank->id;
> > + writel(val, mt->thermal_base + PTPCORESEL);
> > +}
> > +
> > +/**
> > + * mtk_thermal_put_bank - release bank
> > + * @bank: The bank
> > + *
> > + * release a bank previously taken with mtk_thermal_get_bank,
> > + */
> > +static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
> > +{
> > + struct mtk_thermal *mt = bank->mt;
> > +
> > + mutex_unlock(&mt->lock);
> > +}
> > +
> > +/**
> > + * mtk_thermal_bank_temperature - get the temperature of a bank
> > + * @bank: The bank
> > + *
> > + * The temperature of a bank is considered the maximum temperature of
> > + * the sensors associated to the bank.
> > + */
> > +static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
> > +{
> > + struct mtk_thermal *mt = bank->mt;
> > + int temp, i, max;
> > + u32 raw;
> > +
> > + temp = max = INT_MIN;
> > +
> > + for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
> > + raw = readl(mt->thermal_base + sensing_points[i].msr);
> > +
> > + temp = raw_to_mcelsius(mt, bank_data[bank->id].sensors[i], raw);
> > +
> > + /*
> > +* The first read of a sensor often contains very high bogus
> > +* temperature value. Filter these out so that the system does
> > +* not immediately shut down.
> > +*/
> > + if (temp > 20)
> > + temp = 0;
> > +
> > + if (temp > max)
> > + max = temp;
> > + }
> > +
> > + return max;
> > +}
> > +
> > +static int mtk_read_temp(void *data, int *temperature)
> > +{
> > + struct mtk_thermal *mt = data;
> > + int i;
> > + int tempmax = INT_MIN;
> > +
> > + for (i = 0; i < MT8173_NUM_ZONES; i++) {
> > + struct mtk_thermal_bank *bank = &mt->banks[i];
> > + int t;
> > +
> > + mtk_thermal_get_bank(bank);
> > +
> > + t = mtk_thermal_bank_temperature(bank);
>
> IIUIC, when you had multiple thermal zones
> mtk_thermal_bank_temperature() made sense, but now it looks like
> you're just doing the maximum of all sensors. Why bother with the
> banks any m
Re: [PATCH v2 01/10] of: Add vendor prefix for Advantech Corporation
On 11/05/2015 03:22 PM, Rob Herring wrote: On Thu, Nov 05, 2015 at 01:13:35PM -0500, Akshay Bhat wrote: This patch adds vendor prefix for Advantech Corporation. Website: http://www.advantech.com/ Signed-off-by: Akshay Bhat --- 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 55df1d4..2b3c5ac 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -10,6 +10,7 @@ adAvionic Design GmbH adapteva Adapteva, Inc. adh AD Holdings Plc. adi Analog Devices, Inc. +advAdvantech Corporation adv is a bit short. I think it would be better to go with "advantech". Rob Fixed in v3. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384203.html aeroflexgaisler Aeroflex Gaisler AB alAnnapurna Labs allwinner Allwinner Technology Co., Ltd. -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/10] ARM: dts: imx: Update vendor info for GE Bx50v3 boards
On 11/10/2015 06:19 AM, Lucas Stach wrote: Am Donnerstag, den 05.11.2015, 13:13 -0500 schrieb Akshay Bhat: Update vendor and copyright info for GE Bx50v3 boards Signed-off-by: Akshay Bhat This one and the following patches should be folded into the patches introducing the files being patched here. They fix the original patches and it makes no sense to merge patches with slightly wrong DTs, just to immediately following up with patches to fix things. Regards, Lucas Fixed in v3. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384202.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mtd: ofpart: document the lock flag.
On Fri, Oct 30, 2015 at 01:34:00PM -0700, Brian Norris wrote: > From: Michal Suchanek > > The lock flag of ofpart is undocumented. Add to binding doc. > > Signed-off-by: Michal Suchanek > Signed-off-by: Brian Norris > Cc: Sascha Hauer Pushed to l2-mtd.git -- 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 v3 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module
From: Justin Waters
Add support for Advantech BA-16 module based on iMX6D processor
http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-ba16.dtsi | 584 ++
1 file changed, 584 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 000..d0c4568
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,584 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q.dtsi"
+#include
+
+/ {
+ memory {
+ reg = <0x1000 0x4000>;
+ };
+
+ clocks {
+ clk24m: clk24m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_usb_h1_vbus: regulator@2 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_1p8v: regulator@3 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator@4 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ lvds_ppen: regulator@5 {
+ compatible = "regulator-fixed";
+ regulator-name = "lvds_ppen";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+
+ backlight {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_display>;
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+100 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+120 121 122 123 124 125 126 127 128 129
+130 131 132 133 134 135 136 137 138 139
+140 141 142 143 144 145 146 147 148 149
+150 151 152 153 154 155 156 157 158 159
+160 161 162 163 164 165 166 167 168 169
+170 171 172 173 174 175 176 177 178 179
+180 181 182 183 184 185 186 187 188 189
+190 191 192 193 194 195 196 197 198 199
+200 201 202 203 204 205
[PATCH v3 0/7] ARM: dts: Add Advantech board support
This series aims to add Advantech BA-16 module (iMX6 based) and GE board support. This series has been tested against linux-next tag next-20151110. Modifications: v2->v3: - Change vendor prefix from adv to advantech as suggested by Rob Herring - Reorder patches and squash/fold v2 commits as suggested by Lucas Stash History: [v1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381872.html [v2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/383276.html Akshay Bhat (5): of: Add vendor prefix for Advantech Corporation of: Add vendor prefix for General Electric Company ARM: dts: imx: Add support for Advantech/GE B450v3 ARM: dts: imx: Add support for Advantech/GE B650v3 ARM: dts: imx: Add support for Advantech/GE B850v3 Justin Waters (2): ARM: dts: imx: Add Advantech BA-16 Qseven module ARM: dts: imx: Add support for Advantech/GE Bx50v3 .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/imx6q-b450v3.dts | 75 +++ arch/arm/boot/dts/imx6q-b650v3.dts | 74 +++ arch/arm/boot/dts/imx6q-b850v3.dts | 122 + arch/arm/boot/dts/imx6q-ba16.dtsi | 584 + arch/arm/boot/dts/imx6q-bx50v3.dtsi| 211 7 files changed, 1071 insertions(+) create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] ARM: dts: imx: Add support for Advantech/GE B650v3
Add support for Advantech/GE B650v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b650v3.dts | 74 ++
2 files changed, 75 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b3330fe..e2df9f8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -311,6 +311,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
+ imx6q-b650v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
new file mode 100644
index 000..fa9e0e0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B650V3 QSeven Board";
+ compatible = "ge,imx6q-b650v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] ARM: dts: imx: Add support for Advantech/GE B450v3
Add support for Advantech/GE B450v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b450v3.dts | 75 ++
2 files changed, 76 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..b3330fe 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,6 +310,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard-revb1.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
+ imx6q-b450v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 000..919e4a4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B450V3 QSeven Board";
+ compatible = "ge,imx6q-b450v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3
From: Justin Waters
Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
the Advantech BA-16 module (based on iMX6D). This file has the
devicetree entries that are common to all 3 boards.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 211
1 file changed, 211 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
new file mode 100644
index 000..2715cd9
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -0,0 +1,211 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q-ba16.dtsi"
+
+/ {
+ regulators {
+ /* regulator for wl18xx on sdhc4 */
+ wl18xx_vmmc: regulator@6 {
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1807";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pca9539 3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ reg_wlan: regulator@7 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V_wlan";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx6q-ba16-sgtl5000",
+"fsl,imx-audio-sgtl5000";
+ model = "imx6q-ba16-sgtl5000";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT";
+ mux-int-port = <1>;
+ mux-ext-port = <4>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mclk: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2200>;
+ };
+ };
+};
+
+&i2c1 {
+ pca9547: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c3: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+
+ ads7830: ads7830@48 {
+ compatible = "ti,ads7830";
+ reg = <0x48>;
+ };
+
+ mma8453: mma8453@1c {
+ compatible = "fsl,mma8453";
+ reg = <0x1c>;
+ };
+ };
+
+ mux_i2c4: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ };
+
+ mpl3115: mpl3115@60 {
+ compatible = "fsl,mpl3115";
+ reg = <0x60>;
+ };
+ };
+
+ mux_i2c5: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c6: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ codec: sgtl5000@0a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&mclk>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+ };
+
+ mux_i2c7: i2c@4 {
+ #address-cells = <1>;
+
[PATCH v3 7/7] ARM: dts: imx: Add support for Advantech/GE B850v3
Add support for Advantech/GE B850v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b850v3.dts | 122 +
2 files changed, 123 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e2df9f8..7ad1eb8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -312,6 +312,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
imx6q-b650v3.dtb \
+ imx6q-b850v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
new file mode 100644
index 000..2dbcf71
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B850V3 QSeven Board";
+ compatible = "ge,imx6q-b850v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ fsl,dual-channel;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: stdp4028 {
+ clock-frequency = <137143857>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hback-porch = <100>;
+ hfront-porch = <40>;
+ vback-porch = <30>;
+ vfront-porch = <3>;
+ hsync-len = <10>;
+ vsync-len = <2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ pca9547_ddc: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c11: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+ };
+
+ mux_i2c12: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+ };
+
+ mux_i2c13: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c14: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+ };
+
+ mux_i2c15: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4>;
+ };
+
+ mux_i2c16: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x5>;
+ };
+
+ mux_i2c17: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x6>;
+ };
+
+ mux_i2c18: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&mux_i2c11>;
+};
+
+&mux_i2c3 {
+ ads7830_2: ads7830@4a {
+ compatible = "ti,ads7830";
+ reg = <0x4a>;
+ };
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] of: Add vendor prefix for General Electric Company
This patch adds vendor prefix for General Electric Company Signed-off-by: Akshay Bhat 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 5134b24..598154c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -87,6 +87,7 @@ fcs Fairchild Semiconductor fireflyFirefly focaltech FocalTech Systems Co.,Ltd fslFreescale Semiconductor +ge General Electric Company GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc. gefGE Fanuc Intelligent Platforms Embedded Systems, Inc. geniatech Geniatech, Inc. -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] of: Add vendor prefix for Advantech Corporation
This patch adds vendor prefix for Advantech Corporation. Website: http://www.advantech.com/ Signed-off-by: Akshay Bhat --- 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 55df1d4..5134b24 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -10,6 +10,7 @@ adAvionic Design GmbH adapteva Adapteva, Inc. adhAD Holdings Plc. adiAnalog Devices, Inc. +advantech Advantech Corporation aeroflexgaislerAeroflex Gaisler AB al Annapurna Labs allwinner Allwinner Technology Co., Ltd. -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On 11/10/2015 11:04 AM, Mark Brown wrote:
On Tue, Nov 10, 2015 at 10:47:33AM -0600, Andrew F. Davis wrote:
On 11/10/2015 03:57 AM, Mark Brown wrote:
Of course this is a negative review of the binding! What on earth did
you think my feedback meant? The driver and the binding go together.
The bindings should be driver/platform/OS agnostic, changing the bindings
because the Linux regulator subsystem maintainer doesn't like them
in regulator drivers is then not correct.
If the binding is accepted then the regulator driver will just have
to deal with it, so as I said, why not nack the bindings patch, and
explain your objection where DT maintainers might see it.
If I'm not going to merge the driver because of issues in the DT code it
is vanishingly unlikely that I'm going to merge the regulator bindings
either. I would have thought it should be clear that my review comments
cover both the manifestation of the bindings in the driver and the
bindings themselves.
Kind of an interesting situation, if I didn't have the regulator as a separate
node like you want, then I wouldn't really need a separate regulator binding
Doc,
for you to merge, it could all be merged as a single MFD binding.
Anyway, All I'm trying to do here is keep things clean in the DT. We only have
one consistent option:
Match all sub parts by compatible:
tps65912: tps65912@2d {
compatible = "ti,tps65912";
reg = <0x58>;
interrupts ...
regulator {
compatible = "ti,tps65912-regulator";
dcdc1 {
regulator-name = "vdd_core";
regulator-min-microvolt = <912000>;
regulator-max-microvolt = <1144000>;
};
...
};
pwrbutton {
compatible = "ti,palmas-pwrbutton";
interrupt-parent = <&tps65912>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
wakeup-source;
ti,palmas-long-press-seconds = <12>;
};
gpio {
compatible = "ti,palmas-gpio";
gpio-controller;
#gpio-cells = <2>;
};
...
};
Or we end up with some hybrid approach, matching some on node name, others
on compatible when needed. Yes, the above matches Linux device model (still
not sure why that is such a problem?), but it also matches modular functionality
in the 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 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Tue, Nov 10, 2015 at 10:47:33AM -0600, Andrew F. Davis wrote: > On 11/10/2015 03:57 AM, Mark Brown wrote: > >Of course this is a negative review of the binding! What on earth did > >you think my feedback meant? The driver and the binding go together. > The bindings should be driver/platform/OS agnostic, changing the bindings > because the Linux regulator subsystem maintainer doesn't like them > in regulator drivers is then not correct. > If the binding is accepted then the regulator driver will just have > to deal with it, so as I said, why not nack the bindings patch, and > explain your objection where DT maintainers might see it. If I'm not going to merge the driver because of issues in the DT code it is vanishingly unlikely that I'm going to merge the regulator bindings either. I would have thought it should be clear that my review comments cover both the manifestation of the bindings in the driver and the bindings themselves. signature.asc Description: PGP signature
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On 11/10/2015 03:57 AM, Mark Brown wrote: On Mon, Nov 09, 2015 at 11:41:20AM -0600, Andrew F. Davis wrote: On 11/06/2015 03:16 PM, Mark Brown wrote: There are cases where it's useful where we're abstracting something and gaining some meaningful reuse. This really does not appear to be one of those cases, there are no parameters in the DT and the compatible string is the full device name. As before I see no reason to make that call now and limit ourselves. To repeat *yet* *again* the point is that putting the current Linux driver model into the DT is limiting our future selves. You do not need to populate it. There is no value in populating it and as previously discussed putting the Linux driver model into DT can be actively harmful if we change our idea of how we should model things. The dev passed to regulator_register needs to have of_node populated for your OF init_data helper to work. Devices with OF tables can just pass their own dev. Others have to use their parents' nodes, this is a workaround, OF devices should be probed with their of_node pre-populated. This is not a workaroud, the only reason you think it is a workaround is the desire to directly represent the Linux device model in the DT. Please stop this. I don't understand why you are pushing so hard to put the Linux device model representation of the device into DT but it's getting very repetitive. I'm not pushing anything, this is how other sub-nodes of MFD devices are Every time we go through this we finish the discussion and then you come back with yet another excuse for trying to push the current Linux device model into the DT or another version of the patch with the same problem. I keep finding different problems, do you expect me to ignore them? You are making minor restatements of the same thing over and over again which ignore the main feedback. The fact that other people have merged imperfect code into the kernel is not a good reason to merge even more of it when we have better tools. Looking at that binding I'm seeing no reason why any of the subfunctions should have compatible strings (and if we're going down the route you're trying to go down we really ought to have something in the binding for at least an interrupt controller in there as well...). These are not "subfunctions" they are full drivers, they only need register accessors passed in, they do not call the core and the core does not call them. To repeat *yet* *again* they are groupings of functionality which happen to represent the way Linux models devices right now. There's no generality in there, it's just a dump of the current Linux model of the functions into the DT. I've made different points every time, you are repeating yourself because you only have one counter, you don't like what you perceive as putting the "Linux device model representation of the device into DT". I understand this, I simply don't agree that is what is going on, or that this way will cause us any problems in the future. If your problem is with the DT binding for this or other MFDs, then nack *them* and explain to everyone why what they are doing is wrong and why regulators should be special cases. Blocking the regulator drivers to force a change in DT is not going to fix this issue. Of course this is a negative review of the binding! What on earth did you think my feedback meant? The driver and the binding go together. The bindings should be driver/platform/OS agnostic, changing the bindings because the Linux regulator subsystem maintainer doesn't like them in regulator drivers is then not correct. If the binding is accepted then the regulator driver will just have to deal with it, so as I said, why not nack the bindings patch, and explain your objection where DT maintainers might see it. -- 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: codecs: Add da7218 codec driver
On Tue, Nov 10, 2015 at 04:21:04PM +, Opensource [Adam Thomson] wrote: > On November 10, 2015 15:45, Mark Brown wrote: > > That seems like a particularly unfortunate choice given that > > VOICECOMMAND is used in the standard Google headset mapping (see > > ts3a227e for an example, that's a device specifically aimed at providing > > accessory detection in Chromebooks). There's also been some pushback > > against using the input devices due to the difficulty in enabling apps > > to access input devices - ALSA controls were preferred instead but > > that's less helpful for tinyalsa. Perhaps that can be added relatively > > easily, or a uevent or something. > I chose VOICECOMMAND as I thought this kind of feature might offer the same > kind > of use as the physical button, but if this only for Google headset use then > fair > enough. No, that's a generic button but the point is that the expected workflow from userspace is going to be different if the user pressed a button to initiate a voice command compared to if they use an activation phrase. > > Not sure what the best way forward here is, the other implementations of > > this that I'm aware of do more of the detection in offload and present > > streams of detected audio to userspace via normal capture. > Yes, this is far more simplistic, and any voice processing or capture is not > handled by the codec. It just an indication of above threshold noise level at > the mic. For the implementations you know of, how are those events indicated > to > user-space? I'm not aware of any implementations that just do the activity detection. I've seen hardware with it but nobody using it in software. > > I would at least suggest moving this into a separate patch and doing > > the integration separately. > Are you happy for me to leave the actual controls for this feature in, without > the user-space reporting side? Otherwise it's a pain to strip that out, and > then > re-instate later. The event can be masked off until the user-space reporting > is added in a subsequent patch. Possibly, let's see what the code looks like. signature.asc Description: PGP signature
Re: [PATCH v4 2/2] leds: rt5033: Add RT5033 Flash led device driver
Hi Ingi,
Thanks for the update. Please find my comments below.
On 11/10/2015 03:17 AM, Ingi Kim wrote:
This patch adds device driver of Richtek RT5033 PMIC.
The driver supports a current regulated output to drive white LEDs.
I would add here also the part from leds-rt5033.txt header.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-rt5033.c | 502 +
include/linux/mfd/rt5033-private.h | 51
4 files changed, 562 insertions(+)
create mode 100644 drivers/leds/leds-rt5033.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 42990f2..29613e3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -345,6 +345,14 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_RT5033
+ tristate "LED support for RT5033 PMIC"
+ depends on LEDS_CLASS_FLASH && OF
+ depends on MFD_RT5033
+ help
+ This option enables support for on-chip LED driver on
+ RT5033 PMIC.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b503f92..bcc4d93 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
+obj-$(CONFIG_LEDS_RT5033) += leds-rt5033.o
obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
new file mode 100644
index 000..eb89731
--- /dev/null
+++ b/drivers/leds/leds-rt5033.c
@@ -0,0 +1,502 @@
+/*
+ * led driver for RT5033
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Ingi Kim
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RT5033_LED_FLASH_TIMEOUT_MIN 64000
+#define RT5033_LED_FLASH_TIMEOUT_STEP 32000
+#define RT5033_LED_FLASH_BRIGHTNESS_MIN5
+#define RT5033_LED_FLASH_BRIGHTNESS_MAX_1CH60
+#define RT5033_LED_FLASH_BRIGHTNESS_MAX_2CH80
+#define RT5033_LED_FLASH_BRIGHTNESS_STEP 25000
+#define RT5033_LED_TORCH_BRIGHTNESS_MIN12500
+#define RT5033_LED_TORCH_BRIGHTNESS_STEP 12500
+
+/* Macro to get offset of rt5033_led_config_data */
+#define RT5033_LED_CONFIG_DATA_OFFSET(val, step, min) (((val) - (min)) \
+ / (step))
+#define MIN(a, b) ((a) > (b) ? (b) : (a))
Please use min() macro from include/linux/kernel.h
+#define FLED1_IOUT (BIT(0))
+#define FLED2_IOUT (BIT(1))
+
+enum rt5033_fled {
+ FLED1,
+ FLED2,
+};
+
+struct rt5033_sub_led {
+ enum rt5033_fled fled_id;
+ struct led_classdev_flash fled_cdev;
+ struct work_struct work_brightness_set;
+
+ u32 torch_brightness;
+ u32 flash_brightness;
+ u32 flash_timeout;
+};
+
+/* RT5033 Flash led platform data */
+struct rt5033_led {
+ struct device *dev;
+ struct mutex lock;
+ struct regmap *regmap;
+ struct rt5033_sub_led sub_leds[2];
+
+ u32 iout_torch_max[2];
+ u32 iout_flash_max[2];
You're not using above two properties anywhere in the driver.
+ u8 fled_mask;
+
+ /* arrangement of current outputs */
+ bool iout_joint;
+};
+
+struct rt5033_led_config_data {
+ const char *label[2];
+ u32 flash_max_microamp[2];
+ u32 flash_max_timeout[2];
+ u32 torch_max_microamp[2];
+ u32 num_leds;
+};
+
+static struct rt5033_sub_led *flcdev_to_sub_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct rt5033_sub_led, fled_cdev);
+}
+
+static struct rt5033_led *sub_led_to_led(struct rt5033_sub_led *sub_led)
+{
+ return container_of(sub_led, struct rt5033_led,
+ sub_leds[sub_led->fled_id]);
+}
+
+static int rt5033_fled_used(struct rt5033_led *led, enum rt5033_fled fled_id)
+{
+ u8 fled_bit = (fled_id == FLED1) ? FLED1_IOUT : FLED2_IOUT;
+
+ return led->fled_mask & fled_bit;
+}
+
+static void __rt5033_led_brightness_set(struct rt5033_led *led,
+ enum rt5033_fled fled_id,
+
Re: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
On Tue, Nov 10, 2015 at 09:33:12PM +0530, Kapil Hali wrote: > Hi Russel, Wrong. Look at my name as sent in the From: and as quoted in the very next line. As far as I'm concerned (and I don't care what other people say) it's disrespectful to spell people's names incorrectly. > It was clear the very first time itself as pointed out by you and the > lead developers and hence the change was readily sent in the very next > patch set. I didn't change a comment in this patch, which is misleading > about the SMP enable-method used in the patch set, it is my mistake and > I apologies for the same. I will change it and send the next patch set. Thanks. > Also, before sending out the patch set, I had asked for a clarification > about the method: https://lkml.org/lkml/2015/11/6/234 Sorry, I don't read every single email irrespective of how it's marked. There's way too much email, and way too much mail with improperly classified recipient lists to be able to usefully sort this mail. (If you do the math, the email rate during a 12 hour working day from just linux-arm-kernel is one email every 2.5 minutes, assuming 300 emails a day. It takes way longer than that to compose a proper reply to an email - I've spent around 15 minutes on this one alone. Hence, if I'm busy, I more or less totally ignore email now, and rarely bother to "catch up" with missed emails.) > For my understanding, I am repeating my query- In case of simple method of > waking up secondary core, smp_boot_secondary() will always return success > indicating secondary core successfully started. I understand that in > __cpu_up(), primary core waits for completion till secondary core comes > online or time outs. However, is it appropriate to return successful start > of secondary core without knowing if it really did? Yes, because all that your smp_boot_secondary() should be doing is trying to start the core. If you encounter an error trying to do so, that's what the error return is for. If you just set a bit somewhere to tell the hardware to release the secondary core's reset, then if you set the bit and return success, that's prefectly acceptable. The core ARM SMP code will then wait up to one second for the secondary core to become known to the kernel before declaring that the CPU failed to come online. If it fails to appear, we assume that it will never appear - and actually at that point the system is in an unknown state: if the secondary CPU crashed during its boot, it could start scribbling into memory or touching devices in an unpredictable way: the only sane answer is to reboot the whole system to ensure that it's back to a known good state. Hence why we don't provide any cleanup at the point of a failed secondary CPU (I've been debating about tainting the kernel at that point, so we know when things have gone bad.) Hope this helps. -- 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 v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
Hi Rob,
On 11/7/2015 11:33 PM, Rob Herring wrote:
> On Fri, Nov 6, 2015 at 3:11 PM, Kapil Hali wrote:
>> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
>> Northstar Plus CPU to the 32-bit ARM CPU device tree binding
>> documentation file and create a new binding documentation for
>> Northstar Plus CPU.
>>
>> Signed-off-by: Kapil Hali
>> ---
>> .../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36
>> ++
>> Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>> 2 files changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> new file mode 100644
>> index 000..8506da7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> @@ -0,0 +1,36 @@
>> +Broadcom Northstar Plus SoC CPU Enable Method
>> +-
>> +This binding defines the enable method used for starting secondary
>> +CPUs in the following Broadcom SoCs:
>> + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
>> +
>> +The enable method is specified by defining the following required
>> +properties in the "cpus" device tree node:
>> + - enable-method = "brcm,bcm-nsp-smp";
>
> As I said already, this is supposed to be per cpu.
>
>> + - secondary-boot-reg = <...>;
>
> And then you might as well move this too.
>
NS/NSP family of SoCs have maximum of two cores. There would not be a
need for another boot-reg in this family of SoCs. However, I agree, it
should go to individual CPU nodes. I will do the change in the next patch.
>> +
>> +The secondary-boot-reg property is a u32 value that specifies the
>> +physical address of the register used to request the ROM holding pen
>> +code release a secondary CPU.
>> +
>> +Example:
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + enable-method = "brcm,bcm-nsp-smp";
>> + secondary-boot-reg = <0x042c>;
>> +
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + next-level-cache = <&L2>;
>> + reg = <0>;
>> + };
>> +
>> + cpu1: cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + next-level-cache = <&L2>;
>> + reg = <1>;
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>> b/Documentation/devicetree/bindings/arm/cpus.txt
>> index 91e6e5c..6abe3f3 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
>> @@ -191,6 +191,7 @@ nodes to be present and contain the properties described
>> below.
>> "allwinner,sun8i-a23"
>> "arm,psci"
>> "brcm,brahma-b15"
>> + "brcm,bcm-nsp-smp"
>> "marvell,armada-375-smp"
>> "marvell,armada-380-smp"
>> "marvell,armada-390-smp"
>> --
>> 2.1.0
>>
Thanks,
Kapil Hali
--
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 RESEND v2 3/4] ARM: BCM: Add SMP support for Broadcom NSP
Hi Florian, Linus,
On 11/10/2015 7:59 AM, Florian Fainelli wrote:
> 2015-11-09 2:09 GMT-08:00 Linus Walleij :
>> On Fri, Nov 6, 2015 at 8:49 PM, Kapil Hali wrote:
>>
>>> Add SMP support for Broadcom's Northstar Plus SoC
>>> cpu enable method. This changes also consolidates
>>> iProc family's - BCM NSP and BCM Kona, platform
>>> SMP handling in a common file.
>>>
>>> Northstar Plus SoC is based on ARM Cortex-A9
>>> revision r3p0 which requires configuration for ARM
>>> Errata 764369 for SMP. This change adds the needed
>>> configuration option.
>>>
>>> Signed-off-by: Kapil Hali
>>
>> This version looks saner to me.
>>
>>> +static int nsp_write_lut(void)
>>> +{
>>> + void __iomem *sku_rom_lut;
>>> + phys_addr_t secondary_startup_phy;
>>> +
>>> + if (!secondary_boot) {
>>> + pr_warn("required secondary boot register not specified\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + sku_rom_lut = ioremap_nocache((phys_addr_t)secondary_boot,
>>> + sizeof(secondary_boot));
>>
>> Why is this address not just taken directly from the device tree?
>
> It comes directly from DT, that's what bcm_smp_prepare_cpus() does
> read from Device Tree.
>
>>
>> If it is not in the device tree: why?
>>
>> Also give it a sane name, bcm_sec_boot_address or so.
>> "secondary_boot" sounds like a function you call to boot
>> the second core.
>
> Agree with that, there could be a better name which better reflects
> this is a variable.
>
As this change is consolidating SMP implementation, I kept the same
name of the variable which was used in kona_smp.c so that the changes
in the common code is minimal. Also, the fact that the change is part
of up-streamed code, I didn't alter with the variable name. Shall I
change it in the next patch?
Thanks,
Kapil
--
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: codecs: Add da7218 codec driver
On November 10, 2015 15:45, Mark Brown wrote: > > It's to detect the noise level on a mic and raise an event if the captured > > sound is above a specific threshold level. Apologies if that wasn't clear. > > > In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and > > release of this key, to indicate to user-space. This seemed like the obvious > > choice for this feature to me, although I'd happily get your opinion on > > this. > > That seems like a particularly unfortunate choice given that > VOICECOMMAND is used in the standard Google headset mapping (see > ts3a227e for an example, that's a device specifically aimed at providing > accessory detection in Chromebooks). There's also been some pushback > against using the input devices due to the difficulty in enabling apps > to access input devices - ALSA controls were preferred instead but > that's less helpful for tinyalsa. Perhaps that can be added relatively > easily, or a uevent or something. > I chose VOICECOMMAND as I thought this kind of feature might offer the same kind of use as the physical button, but if this only for Google headset use then fair enough. > Not sure what the best way forward here is, the other implementations of > this that I'm aware of do more of the detection in offload and present > streams of detected audio to userspace via normal capture. > Yes, this is far more simplistic, and any voice processing or capture is not handled by the codec. It just an indication of above threshold noise level at the mic. For the implementations you know of, how are those events indicated to user-space? > I would at least suggest moving this into a separate patch and doing > the integration separately. Are you happy for me to leave the actual controls for this feature in, without the user-space reporting side? Otherwise it's a pain to strip that out, and then re-instate later. The event can be masked off until the user-space reporting is added in a subsequent patch.
[RFC PATCH v3 1/2] base: dma-coherent: Add DT property for non exclusive shared-dma-pool
In order to have the ability to declare a non exclusive shared-dma-pool,
i.e. without the DMA_MEMORY_EXCLUSIVE flag, add the 'no-exclusive' DT
optional parameter to initialize the coherent memory without the flag.
Signed-off-by: Neil Armstrong
---
drivers/base/dma-coherent.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 55b8398..b57478f 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -279,10 +279,14 @@ EXPORT_SYMBOL(dma_mmap_from_coherent);
static int rmem_dma_device_init(struct reserved_mem *rmem, struct device *dev)
{
struct dma_coherent_mem *mem = rmem->priv;
+ unsigned flags = 0;
+
+ if (!of_get_flat_dt_prop(rmem->fdt_node, "no-exclusive", NULL))
+ flags |= DMA_MEMORY_EXCLUSIVE;
if (!mem &&
dma_init_coherent_memory(rmem->base, rmem->base, rmem->size,
-DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE,
+DMA_MEMORY_MAP | flags,
&mem) != DMA_MEMORY_MAP) {
pr_err("Reserved memory: failed to init DMA memory pool at %pa,
size %ld MiB\n",
&rmem->base, (unsigned long)rmem->size / SZ_1M);
--
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 PATCH v3 0/2] Expose DMA_MEMORY_EXCLUSIVE through shared-dma-pool
The shared-dma-pool dt node only exposes exclusive memory, but in order to export non-exclusive coherent memory, add the no-exclusive property and document it. v3: use correct of_get_flat_dt_prop helper v2: simplify patch by looking for DT attribute in callback Neil Armstrong (2): base: dma-coherent: Add DT property for non exclusive shared-dma-pool devicetree: reserved-memory: document the optional no-exclusive parameter .../devicetree/bindings/reserved-memory/reserved-memory.txt | 3 +++ drivers/base/dma-coherent.c | 6 +- 2 files changed, 8 insertions(+), 1 deletion(-) -- 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 PATCH v3 2/2] devicetree: reserved-memory: document the optional no-exclusive parameter
Document the 'no-exclusive' parameter used for the 'shared-dma-pool' compatible reserved-memory type. Acked-by: Rob Herring Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index 3da0ebd..897aada 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -63,6 +63,9 @@ reusable (optional) - empty property able to reclaim it back. Typically that means that the operating system can use that region to store volatile or cached data that can be otherwise regenerated or migrated elsewhere. +no-exclusive (optional) - empty property +- Indicates the operating system can fall back to the default allocation + mechanism if no more enough memory is available from this pool. Linux implementation note: - If a "linux,cma-default" property is present, then Linux will use the -- 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 v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
Hi Florian,
On 11/8/2015 3:10 AM, Florian Fainelli wrote:
> Le 06/11/2015 13:11, Kapil Hali a écrit :
>> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
>> Northstar Plus CPU to the 32-bit ARM CPU device tree binding
>> documentation file and create a new binding documentation for
>> Northstar Plus CPU.
>>
>> Signed-off-by: Kapil Hali
>> ---
>> .../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36
>> ++
>> Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>> 2 files changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> new file mode 100644
>> index 000..8506da7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>> @@ -0,0 +1,36 @@
>> +Broadcom Northstar Plus SoC CPU Enable Method
>> +-
>> +This binding defines the enable method used for starting secondary
>> +CPUs in the following Broadcom SoCs:
>> + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
>> +
>> +The enable method is specified by defining the following required
>> +properties in the "cpus" device tree node:
>> + - enable-method = "brcm,bcm-nsp-smp";
>> + - secondary-boot-reg = <...>;
>> +
>> +The secondary-boot-reg property is a u32 value that specifies the
>> +physical address of the register used to request the ROM holding pen
>> +code release a secondary CPU.
>
> Is it really how the ROM code is implemented, as a pen holding/release
> mechanism (which sounds like how this was implemented previously in the
> kernel actually) or should this be described in a more generic way as
> the physical address of the register where the secondary CPUs reset
> vector address must be written to? Or something along these lines.
>
I overlooked this patch and didn't change the description. It is a physical
address of a register which holds the address of the secondary core's entry
point.
>> +
>> +Example:
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +enable-method = "brcm,bcm-nsp-smp";
>
> Just a nit, but if NSP and NS are sharing the same mechanism, would not
> a more "NS-centric" property be more appropriate because NS came before NSP?
>
>> +secondary-boot-reg = <0x042c>;
>> +
>> +cpu0: cpu@0 {
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a9";
>> +next-level-cache = <&L2>;
>> +reg = <0>;
>> +};
>> +
>> +cpu1: cpu@1 {
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a9";
>> +next-level-cache = <&L2>;
>> +reg = <1>;
>> +};
>> +};
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
>> b/Documentation/devicetree/bindings/arm/cpus.txt
>> index 91e6e5c..6abe3f3 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.txt
>> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
>> @@ -191,6 +191,7 @@ nodes to be present and contain the properties described
>> below.
>> "allwinner,sun8i-a23"
>> "arm,psci"
>> "brcm,brahma-b15"
>> +"brcm,bcm-nsp-smp"
>> "marvell,armada-375-smp"
>> "marvell,armada-380-smp"
>> "marvell,armada-390-smp"
>>
>
>
Thanks,
Kapil Hali
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
Hi Russel, On 11/8/2015 11:01 PM, Russell King - ARM Linux wrote: > On Sat, Nov 07, 2015 at 01:40:23PM -0800, Florian Fainelli wrote: >> Le 06/11/2015 13:11, Kapil Hali a écrit : >>> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's >>> Northstar Plus CPU to the 32-bit ARM CPU device tree binding >>> documentation file and create a new binding documentation for >>> Northstar Plus CPU. >>> >>> Signed-off-by: Kapil Hali >>> --- >>> .../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36 >>> ++ >>> Documentation/devicetree/bindings/arm/cpus.txt | 1 + >>> 2 files changed, 37 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt >>> >>> diff --git >>> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt >>> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt >>> new file mode 100644 >>> index 000..8506da7 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt >>> @@ -0,0 +1,36 @@ >>> +Broadcom Northstar Plus SoC CPU Enable Method >>> +- >>> +This binding defines the enable method used for starting secondary >>> +CPUs in the following Broadcom SoCs: >>> + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312 >>> + >>> +The enable method is specified by defining the following required >>> +properties in the "cpus" device tree node: >>> + - enable-method = "brcm,bcm-nsp-smp"; >>> + - secondary-boot-reg = <...>; >>> + >>> +The secondary-boot-reg property is a u32 value that specifies the >>> +physical address of the register used to request the ROM holding pen >>> +code release a secondary CPU. >> >> Is it really how the ROM code is implemented, as a pen holding/release >> mechanism (which sounds like how this was implemented previously in the >> kernel actually) or should this be described in a more generic way as >> the physical address of the register where the secondary CPUs reset >> vector address must be written to? Or something along these lines. > > Why do people insist on using holding pens to bring their secondary CPUs > into existence? I hope the hardware people aren't being dumb and have no > way to hold in reset or power down their secondary CPUs, either of which > is a vital feature for things like kexec and the like. If they do have > a way to hold secondary CPUs in reset or powered down, why aren't they > using that at boot instead of implementing the stupid Versatile scheme, > which exists because Versatile _can't_ hold its CPUs in reset or power > them down... > > It's times like this that I wonder what kind of drugs the hardware SoC > people are on, but I'm well aware that people contributing SMP bringup > solutions are also dumb idiots who copy the Versatile scheme with very > little thought... (as you can see, I'm not mincing my words here - if > people want to be lazy in this regard despite this having been brought > up multiple times, and the lead developers having said that the versatile > pen_release stuff should not be used, they earn themselves the right to > be called dumb idiots. Simple solution to avoid that title: don't be a > dumb idiot by copy the Versatile SMP bring up code! It's not a sane > model for any SoC sane SoC to follow.) > > Is this clear enough? > It was clear the very first time itself as pointed out by you and the lead developers and hence the change was readily sent in the very next patch set. I didn't change a comment in this patch, which is misleading about the SMP enable-method used in the patch set, it is my mistake and I apologies for the same. I will change it and send the next patch set. Also, before sending out the patch set, I had asked for a clarification about the method: https://lkml.org/lkml/2015/11/6/234 For my understanding, I am repeating my query- In case of simple method of waking up secondary core, smp_boot_secondary() will always return success indicating secondary core successfully started. I understand that in __cpu_up(), primary core waits for completion till secondary core comes online or time outs. However, is it appropriate to return successful start of secondary core without knowing if it really did? Thanks, Kapil Hali -- 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: codecs: Add da7218 codec driver
On Tue, Nov 10, 2015 at 02:24:13PM +, Opensource [Adam Thomson] wrote: > On November 10, 2015 14:15, Mark Brown wrote: > > So this *isn't* a normal mic detection feature? What's the userspace > > interface for reporting then? > By mic detection you thought this was to detect if a mic was present or not? That and button detection. > It's to detect the noise level on a mic and raise an event if the captured > sound is above a specific threshold level. Apologies if that wasn't clear. > In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and > release of this key, to indicate to user-space. This seemed like the obvious > choice for this feature to me, although I'd happily get your opinion on this. That seems like a particularly unfortunate choice given that VOICECOMMAND is used in the standard Google headset mapping (see ts3a227e for an example, that's a device specifically aimed at providing accessory detection in Chromebooks). There's also been some pushback against using the input devices due to the difficulty in enabling apps to access input devices - ALSA controls were preferred instead but that's less helpful for tinyalsa. Perhaps that can be added relatively easily, or a uevent or something. Not sure what the best way forward here is, the other implementations of this that I'm aware of do more of the detection in offload and present streams of detected audio to userspace via normal capture. I would at least suggest moving this into a separate patch and doing the integration separately. signature.asc Description: PGP signature
Re: [PATCH V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On Tue, Nov 10, 2015 at 8:55 AM, Viresh Kumar wrote: > On 06-11-15, 07:23, Viresh Kumar wrote: >> Yeah, but in that case 1200 *may* not be a turbo frequency anymore, as >> the voltage constraints might have changed. >> >> So turbo frequency is something that should be used only in small >> bursts, as they are consume lot of power. They aren't available to be >> used freely. They may also have thermal side effects.. >> >> In a similar way, for suspend-freq, we may or may not want the lowest >> frequency to be used during suspend and so that can change as well. >> And we shouldn't have suspend-freq set for two OPP nodes. > > @Rob: Does my comments make any sense now? Or you still think we are > doing something wrong here? What you said could be possible, but I'm still doubtful. I would drop these until you have an actual user. 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 v2 1/4] iio: adc: add IMX7D ADC driver support
On 11/09/2015 02:28 PM, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
>
> Signed-off-by: Haibo Chen
Looks pretty good, a few comments inline.
[...]
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
I don't think you need all of these.
[...]
> +static void imx7d_adc_feature_config(struct imx7d_adc *info)
> +{
> + info->adc_feature.clk_pre_div = IMX7D_ADC_ANALOG_CLK_PRE_DIV_4;
> + info->adc_feature.avg_num = IMX7D_ADC_AVERAGE_NUM_32;
> + info->adc_feature.core_time_unit = 1;
> + info->adc_feature.average_en = true;
What's the plan for these? Right now they are always initialized to the same
static value.
> +}
[...]
> +static int imx7d_adc_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val,
> + int *val2,
> + long mask)
> +{
> + struct imx7d_adc *info = iio_priv(indio_dev);
> +
> + u32 channel;
> + long ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(&indio_dev->mlock);
> + reinit_completion(&info->completion);
> +
> + channel = (chan->channel) & 0x0f;
> + info->channel = channel;
> + imx7d_adc_channel_set(info);
How about just passing channel directy adc_channel_set() instead of doing it
implicitly through the info struct?
[...]
> +static irqreturn_t imx7d_adc_isr(int irq, void *dev_id)
> +{
> + struct imx7d_adc *info = (struct imx7d_adc *)dev_id;
> + int status;
> +
> + status = readl(info->regs + IMX7D_REG_ADC_INT_STATUS);
> + if (status & IMX7D_REG_ADC_INT_STATUS_CHANNEL_INT_STATUS) {
> + info->value = imx7d_adc_read_data(info);
> + complete(&info->completion);
> + }
> + writel(0, info->regs + IMX7D_REG_ADC_INT_STATUS);
Is the hardware really this broken? If the interrupt happens between reading
the status register and clearing it here it will be missed.
> +
> + return IRQ_HANDLED;
You should only return IRQ_HANDLED if you actually handled are interrupt.
> +}
[...]
> +
> +static int imx7d_adc_probe(struct platform_device *pdev)
> +{
> + struct imx7d_adc *info;
> + struct iio_dev *indio_dev;
> + struct resource *mem;
> + int irq;
> + int ret;
> + u32 channels;
> +
> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct imx7d_adc));
> + if (!indio_dev) {
> + dev_err(&pdev->dev, "Failed allocating iio device\n");
> + return -ENOMEM;
> + }
> +
> + info = iio_priv(indio_dev);
> + info->dev = &pdev->dev;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + info->regs = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(info->regs)) {
> + ret = PTR_ERR(info->regs);
> + dev_err(&pdev->dev, "failed to remap adc memory: %d\n", ret);
> + return ret;
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(&pdev->dev, "no irq resource?\n");
> + return irq;
> + }
> +
> + ret = devm_request_irq(info->dev, irq,
> + imx7d_adc_isr, 0,
> + dev_name(&pdev->dev), info);
This is too early. Completion is not initialized, clocks are not enabled, etc...
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed requesting irq, irq = %d\n", irq);
> + return ret;
> + }
> +
[...]
> + ret = of_property_read_u32(pdev->dev.of_node,
Extra space.
> + "num-channels", &channels);
What decides how many channels are in use?
> + if (ret)
> + channels = ARRAY_SIZE(imx7d_adc_iio_channels);
> +
> + indio_dev->name = dev_name(&pdev->dev);
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->dev.of_node = pdev->dev.of_node;
> + indio_dev->info = &imx7d_adc_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = imx7d_adc_iio_channels;
> + indio_dev->num_channels = (int)channels;
I don't think you need the case here.
>[...]
--
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/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On 06-11-15, 07:23, Viresh Kumar wrote: > Yeah, but in that case 1200 *may* not be a turbo frequency anymore, as > the voltage constraints might have changed. > > So turbo frequency is something that should be used only in small > bursts, as they are consume lot of power. They aren't available to be > used freely. They may also have thermal side effects.. > > In a similar way, for suspend-freq, we may or may not want the lowest > frequency to be used during suspend and so that can change as well. > And we shouldn't have suspend-freq set for two OPP nodes. @Rob: Does my comments make any sense now? Or you still think we are doing something wrong here? -- viresh -- 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] Documentation: dt: Add bindings for Secure-only devices
On 10 November 2015 at 14:51, Rob Herring wrote: > On Fri, Oct 30, 2015 at 08:07:34PM +, Peter Maydell wrote: >> +status = "okay"; secure-status = "okay"; // ditto >> +secure-status = "okay"; // ditto >> +// neither explicitly defined: ditto >> >> (Do you want the full set of 9 options you get from multiplying >> out "okay" vs "disabled" vs not-set for each property?) > > Better to err on completeness. The inheritance is easily missed. > > Also, one nit. Use C style comments so when people copy-n-paste this it > is the correct style. OK; I'll send out a v2 with these fixes. thanks -- PMM -- 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] Documentation: dt: Add bindings for Secure-only devices
On Fri, Oct 30, 2015 at 08:07:34PM +, Peter Maydell wrote: > On 30 October 2015 at 18:28, Rob Herring wrote: > > On Thu, Oct 29, 2015 at 9:01 AM, Peter Maydell > > wrote: > >> +Valid Secure world properties: > >> + > >> +- secure-status : specifies whether the device is present and usable > >> + in the secure world. The combination of this with "status" allows > >> + the various possible combinations of device visibility to be > >> + specified: > >> + status = "okay"; // visible in S and NS > > > > I assume neither property present or both okay also mean the same. > > > > status = "okay"; secure-status = "okay"; > > > > We should be explicit. > > Yes; status defaults to "okay" (presumably this is listed in > the overal DT binding spec somewhere), and secure-status > defaults to "same as status, which might in turn be defaulted". > We can list the complete set of options (neither present, > both 'okay', status not present but secure-status present, etc), > though it gets a bit long-winded, especially if we later add > more secure- properties (they'd all have to have verbiage about > "if not present, same as non-prefixed property; if both not > present, both take the default the non-prefixed property takes > if it's not present; if prefixed property not present, it > defaults to same as non-prefixed property", which we already > say in the introductory section). Still, for just status it > would be easy enough to add a couple of lines: > > +status = "okay"; secure-status = "okay"; // ditto > +secure-status = "okay"; // ditto > +// neither explicitly defined: ditto > > (Do you want the full set of 9 options you get from multiplying > out "okay" vs "disabled" vs not-set for each property?) Better to err on completeness. The inheritance is easily missed. Also, one nit. Use C style comments so when people copy-n-paste this it is the correct style. > > >> + status = "disabled"; secure-status = "okay"; // S-only > >> + status = "okay"; secure-status = "disabled"; // NS-only > > > > In HKG when we discussed this, 'status = "secure"' was the proposal. > > That would be simpler: > > > > S world can use "okay" or "secure" > > NS world can use "okay" or no property. > > > > That leaves out the case of disabled in S and enabled for NS. We could > > want that for s/w reasons, but can we have h/w like that? > > It's perfectly possible to design hardware like that (though > I can't think of a reason to do so offhand). I think it's the desire > to be able to describe all the possible valid h/w combinations > that brought us to this secure- prefix design. Plus it > extends nicely to cover other possibilities as we need it; > for instance "device A is at S-0x1 but NS-0x2" can be > done by specifying a device like: >status = "okay"; >secure-status = "okay"; >reg = < 0x2 0x1000 >; >secure-regs = < 0x1 0x1000 >; > (apologies if I've messed the syntax up there). > > Just going for 'status=secure' would deal with the immediate > requirement, but my preference is for a description that > lets us describe all the possible configurations, not just > the ones we think are common, and secure-* is a neat way > of doing that (IIRC it was Grant's suggestion; speaking of > whom, I just noticed I forgot to cc him on the original patch). I don't really want to give blanket approval to use secure-* prefix, but I'm okay with secure-status I guess. For secure-reg in particular, I would do something different and similar to PCI where we add another address cell to define the address space as secure or non-secure. So your example becomes: reg = <0 0x2 0x1000 >, <1 0x1 0x1000 >; The bus compatible would also have to be something like "arm,secure-bus". No point in debating this now. We can worry about it when we have an example. 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 1/4] Documentation: dt-bindings: Describe SROMc configuration
On Fri, Nov 6, 2015 at 4:03 AM, Pavel Fedin wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.
>
> Also, fix size of SROMc mapping in the example.
>
> Signed-off-by: Pavel Fedin
> Reviewed-by: Krzysztof Kozlowski
> ---
> .../bindings/arm/samsung/exynos-srom.txt | 71
> +-
> 1 file changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> index 33886d5..3ff2950 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,75 @@ Required properties:
>
> - reg: offset and length of the register set
>
> -Example:
> +Optional properties:
> +The SROM controller can be used to attach external peripherals. In this case
> +extra properties, describing the bus behind it, should be specified as below:
> +
> +- #address-cells: Must be set to 2 to allow memory address translation
2 is for CS# and offset.
> +
> +- #size-cells: Must be set to 1 to allow CS address passing
size is the size, not the address.
> +
> +- ranges: Must be set up to reflect the memory layout with four integer
> values
> + per bank:
> +0
s/physical/parent/
You could have another level of translation above for the parent.
> +
> +Sub-nodes:
> +The actual device nodes should be added as subnodes to the SROMc node. These
> +subnodes, except regular device specification, should contain the following
> +properties, describing configuration of the relevant SROM bank:
> +
> +Required properties:
> +- reg: bank number, base address (relative to start of the bank) and size of
> + the memory mapped for the device. Note that base address will be
> + typically 0 as this is the start of the bank.
> +
> +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
> +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
> +Each value is specified in cycles and has the
> following
> +meaning and valid range:
> +Tacp : Page mode access cycle at Page mode (0 - 15)
> +Tcah : Address holding time after CSn (0 - 15)
> +Tcoh : Chip selection hold on OEn (0 - 15)
> +Tacc : Access cycle (0 - 31, the actual time is N +
> 1)
> +Tcos : Chip selection set-up before OEn (0 - 15)
> +Tacs : Address set-up before CSn (0 - 15)
This is not easily extended. Perhaps a property per value instead.
> +
> +Optional properties:
> +- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is
> used.
> +
> +- samsung,srom-page-mode : page mode configuration for the bank:
> + 0 - normal (one data)
> + 1 - four data
> + If omitted, default of 0 is used.
> +
> +Example: basic definition, no banks are configured
> + sromc@1257 {
> + compatible = "samsung,exynos-srom";
> + reg = <0x1257 0x14>;
> + };
> +
> +Example: SROMc with SMSC911x ethernet chip on bank 3
> sromc@1257 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x0400 0x2 // Bank0
> + 1 0 0x0500 0x2 // Bank1
> + 2 0 0x0600 0x2 // Bank2
> + 3 0 0x0700 0x2>; // Bank3
> +
> compatible = "samsung,exynos-srom";
> - reg = <0x1257 0x10>;
> + reg = <0x1257 0x14>;
> +
> + ethernet@3 {
> + compatible = "smsc,lan9115";
> + reg = <3 0 0x1>; // Bank 3, offset = 0
> + phy-mode = "mii";
> + interrupt-parent = <&gpx0>;
> + interrupts = <5 8>;
> + reg-io-width = <2>;
> + smsc,irq-push-pull;
> + smsc,force-internal-phy;
> +
> + samsung,srom-config = <1 9 12 1 9 1 1>;
This doesn't match the doc.
> + };
> };
> --
> 2.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
On November 10, 2015 14:15, Mark Brown wrote: > > > The general userspace expectation is that the detection is always active > > > and consistent rather than varying at runtime - runtime variability > > > might be a bit surprising for it, and even then variability in what is > > > detected based on other settings is a bit surprising. If the hardware > > > is that limited I guess it's about all that can be done but I'm still > > > not clear what the use cases are for configuring the levels (as opposed > > > ot the routing). > > > How about the example of always on voice in Android, which can be enabled > > and > > disabled, depending on user settings, and routing will vary depending on > > which > > mic is in use at the time? For the levelling is it not plausible that a user > > could configure the level based on their current environment. You have > > moderately loud background noise, then your threshold would want to be > > higher, but in a quiet environment the likelihood is you would want to lower > > that threshold? > > So this *isn't* a normal mic detection feature? What's the userspace > interface for reporting then? By mic detection you thought this was to detect if a mic was present or not? It's to detect the noise level on a mic and raise an event if the captured sound is above a specific threshold level. Apologies if that wasn't clear. In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and release of this key, to indicate to user-space. This seemed like the obvious choice for this feature to me, although I'd happily get your opinion on this.
Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
On Tue, Nov 10, 2015 at 01:55:30PM +, Opensource [Adam Thomson] wrote: > On November 9, 2015 14:02, Mark Brown wrote: > > The general userspace expectation is that the detection is always active > > and consistent rather than varying at runtime - runtime variability > > might be a bit surprising for it, and even then variability in what is > > detected based on other settings is a bit surprising. If the hardware > > is that limited I guess it's about all that can be done but I'm still > > not clear what the use cases are for configuring the levels (as opposed > > ot the routing). > How about the example of always on voice in Android, which can be enabled and > disabled, depending on user settings, and routing will vary depending on which > mic is in use at the time? For the levelling is it not plausible that a user > could configure the level based on their current environment. You have > moderately loud background noise, then your threshold would want to be > higher, but in a quiet environment the likelihood is you would want to lower > that threshold? So this *isn't* a normal mic detection feature? What's the userspace interface for reporting then? signature.asc Description: PGP signature
Re: [PATCH v3 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts documentation
On Mon, Nov 09, 2015 at 10:05:44AM -0800, Duc Dang wrote:
> This adds the APM X-Gene SLIMpro mailbox device tree
> node documentation.
>
> [dhdang: rebase over 4.3-rc5]
> Signed-off-by: Feng Kan
> Signed-off-by: Duc Dang
> ---
> .../bindings/mailbox/xgene-slimpro-mailbox.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>
> diff --git
> a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
> b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
> new file mode 100644
> index 000..d02a3d8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
> @@ -0,0 +1,34 @@
> +The APM X-Gene SLIMpro mailbox is used to communicate messages between
> +the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
> +interrupt based door bell mechanism and can exchange simple messages using
> the
> +internal registers.
> +
> +There are total of 7 interrupts in this mailbox. Each used for an individual
> +door bell (or mailbox channel).
> +
> +Required properties:
> +- compatible:Should be as "apm, xgene-slimpro-mbox".
^
remove the space
> +
> +- reg: Contain the mailbox register address range.
s/Contain/Contains/
> +
> +- interrupts:7 interrupts must start from 0 to 6, interrupt 0 define
> the
> + the interrupt for mailbox channel 0 and interrupt 1 for
> + mailbox channel 1 and so likewise for the reminder.
s/start/be/
> +
> +- #mbox-cells: only one to specify the mailbox channel number.
> +
> +Example:
> +
> +Mailbox Node:
> + slimpro-mbox: slimpro-mbox@1054 {
> + compatible = "apm,xgene-slimpro-mbox";
> + reg = <0x0 0x1054 0x0 0xa000>;
> + #mbox-cells = <1>;
> + interrupts =<0x0 0x0 0x4>,
> + <0x0 0x1 0x4>,
> + <0x0 0x2 0x4>,
> + <0x0 0x3 0x4>,
> + <0x0 0x4 0x4>,
> + <0x0 0x5 0x4>,
> + <0x0 0x6 0x4>,
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
On November 9, 2015 14:02, Mark Brown wrote: > > > What I'm trying to figure out here is if this depends on the audio > > > routing at runtime or if it's got dedicated configuration? > > > This feature is available for any/all mics connected. Which mics are enabled > > is a runtime configuration of routing, so to me it makes sense also that we > > can > > configure which channel triggers an event, based on our scenario at that > > time. > > The general userspace expectation is that the detection is always active > and consistent rather than varying at runtime - runtime variability > might be a bit surprising for it, and even then variability in what is > detected based on other settings is a bit surprising. If the hardware > is that limited I guess it's about all that can be done but I'm still > not clear what the use cases are for configuring the levels (as opposed > ot the routing). How about the example of always on voice in Android, which can be enabled and disabled, depending on user settings, and routing will vary depending on which mic is in use at the time? For the levelling is it not plausible that a user could configure the level based on their current environment. You have moderately loud background noise, then your threshold would want to be higher, but in a quiet environment the likelihood is you would want to lower that threshold?
Re: [PATCH RESEND 15/16] leds: add LM3633 driver
On 11/10/2015 08:38 AM, Kim, Milo wrote:
Hi Jacek,
On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:
Hi Milo,
Thanks for the patch. Please find my comments in the code.
diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..c1d8759
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
@@ -0,0 +1,60 @@
+LM3633 LED driver generates programmable pattern via the sysfs.
+
+LED Pattern Generator Structure
+
+(3)
+ (a) ---> ___
+ / \
+ (2) / \ (4)
+ (b) > _/ \_ ...
+ (1) (5)
+
+ |<- period -> |
+
+What:/sys/class/leds//pattern_times
"time" noun is uncountable.
+Date:Oct 2015
+KernelVersion:4.3
These properties certainly will not appear in 4.3.
Oops! 4.4 gonna be OK?
We have currently 4.4 merge window, so the most plausible is 4.5.
+Contact:Milo Kim
+Description:read/write
+Set pattern time dimension. There are five arguments.
+ (1) startup delay
+ (2) rising dimming time
+ (3) how much time stays at high level
+ (4) falling dimming time
+ (5) how much time stays at low level
+Ranges are
+ (1), (3), (5): 0 ~ 1. Unit is millisecond.
+ (2), (4): 0 ~ 16000. Unit is millisecond.
+
+Example:
+No delay, rising 200ms, high 300ms, falling 100ms,
low 400ms.
+echo "0 200 300 100 400" >
/sys/class/leds//pattern_times
+
+cat /sys/class/leds//pattern_times
+delay: 0, rise: 200, high: 300, fall: 100, low: 400
Generally a sysfs attribute should represent a single value.
There are cases where the attribute comprises a list of space separated
values, but certainly colons and commas adds to much noise, and are
cumbersome to parse. I'd opt for creating a separate sysfs attribute
for each of the above 5 properties.
Got it, thanks!
+What:/sys/class/leds//pattern_levels
+Date:Oct 2015
+KernelVersion:4.3
+Contact:Milo Kim
+Description:read/write
+Set pattern level(brightness). There are two arguments.
+ (a) Low brightness level
+ (b) High brightness level
+Ranges are from 0 to 255.
+
+Example:
+Low level is 0, high level is 255.
+echo "0 255" > /sys/class/leds//pattern_levels
I'd go also for two separate attributes. E.g. pattern_brightness_lo and
pattern_brightness_hi, or maybe you'll have better idea.
OK.
+cat /sys/class/leds//pattern_levels
+low brightness: 0, high brightness: 255
+
+What:/sys/class/leds//run_pattern
+Date:Oct 2015
+KernelVersion:4.3
+Contact:Milo Kim
+Description:write only
+After 'pattern_times' and 'pattern_levels' are updated,
+run the pattern by writing 1 to 'run_pattern'.
+To stop running pattern, writes 0 to 'run_pattern'.
I wonder how registering an in-driver trigger would work. It would
allow for hiding above pattern attributes when the trigger is inactive,
and thus making the sysfs interface more transparent. You could avoid
the need for run_pattern attribute, as setting the trigger would itself
activate the pattern, and setting brightness to 0 would turn it off.
I like this idea, let me try to fix it.
+/**
+ * struct ti_lmu_led
+ *
+ * @chip:Pointer to parent LED device
+ * @bank_id:LED bank ID
+ * @cdev:LED subsystem device structure
+ * @name:LED channel name
+ * @led_string:LED string configuration.
+ *Bit mask is set on parsing DT.
+ * @imax:[Optional] Max current index.
+ *It's result of ti_lmu_get_current_code().
Why is this optional?
You're correct, this is not optional. DT property is optional.
+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+struct ti_lmu_led *lmu_led = to_ti_lmu_led(dev);
+struct ti_lmu_led_chip *chip = lmu_led->chip;
+unsigned int low, high;
+u8 reg, offset, val;
+int ret;
+
+/*
+ * Sequence
+ *
+ * 1) Read pattern level data
+ * 2) Disable a bank before programming a pattern
+ * 3) Update LOW BRIGHTNESS register
+ * 4) Update HIGH BRIGHTNESS register
+ *
+ * Level register addresses have offset number based on the LED
bank.
+ */
+
+ret = sscanf(buf, "%u %u", &low, &high);
+if (ret != 2)
+return -EINVAL;
+
+low = min_t(unsigne
Re: [PATCH 1/1] drivers: of: of_reserved_mem: fixup the alignment with CMA setup
Hello,
On 2015-11-10 13:30, Jason Liu wrote:
There is an alignment mismatch issue between the of_reserved_mem and
the CMA setup requirement. The of_reserved_mem will try to get the
alignment value from the DTS and pass it to __memblock_alloc_base to
do the memory block base allocation, but the alignment value specified
in the DTS may not satisfy the CAM setup requirement since CMA setup
required the alignment as the following in the code:
align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
The sanity check in the function of rmem_cma_setup will fail if the
alignment does not setup correctly and thus CMA will fail to setup.
This patch is to fixup the alignment to meet the CMA setup required.
Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138
Signed-off-by: Jason Liu
Cc: Marek Szyprowski
Cc: Grant Likely
Cc: Rob Herring
Acked-by: Marek Szyprowski
---
drivers/of/of_reserved_mem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 62f467b..9394311 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -124,6 +124,10 @@ static int __init __reserved_mem_alloc_size(unsigned long
node,
align = dt_mem_next_cell(dt_root_addr_cells, &prop);
}
+ /* Need adjust the alignment to satisfy the CMA requirement */
+ if (IS_ENABLED(CONFIG_CMA) && of_flat_dt_is_compatible(node,
"shared-dma-pool"))
+ align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1,
pageblock_order));
+
prop = of_get_flat_dt_prop(node, "alloc-ranges", &len);
if (prop) {
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/32] devicetree: bindings: scsi: HiSi SAS
On Tue, Nov 10, 2015 at 5:09 AM, John Garry wrote: > On 09/11/2015 18:01, Rob Herring wrote: >> >> On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote: >>> >>> Add devicetree bindings for HiSilicon SAS driver. >>> >>> Signed-off-by: John Garry >>> Signed-off-by: Zhangfei Gao >>> --- >>> .../devicetree/bindings/scsi/hisilicon-sas.txt | 81 >>> ++ >>> 1 file changed, 81 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/scsi/hisilicon-sas.txt >>> >>> diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt >>> b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt >>> new file mode 100644 >>> index 000..2333cc3 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt >>> @@ -0,0 +1,81 @@ >>> +* HiSilicon SAS controller >>> + >>> +The HiSilicon SAS controller supports SAS/SATA. >>> + >>> +Main node required properties: >>> + - compatible : value should be as follows: >>> + (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS >>> controller IP >> >> >> Please do a more specific compatible string with the SOC part number. >> Same versions of IP blocks can have different integration/process >> features/bugs. >> > > How about "hisilicon,hip05-sas-v1"? That's fine. 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
[PATCH 1/1] drivers: of: of_reserved_mem: fixup the alignment with CMA setup
There is an alignment mismatch issue between the of_reserved_mem and
the CMA setup requirement. The of_reserved_mem will try to get the
alignment value from the DTS and pass it to __memblock_alloc_base to
do the memory block base allocation, but the alignment value specified
in the DTS may not satisfy the CAM setup requirement since CMA setup
required the alignment as the following in the code:
align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
The sanity check in the function of rmem_cma_setup will fail if the
alignment does not setup correctly and thus CMA will fail to setup.
This patch is to fixup the alignment to meet the CMA setup required.
Mailing-list-thread: https://lkml.org/lkml/2015/11/9/138
Signed-off-by: Jason Liu
Cc: Marek Szyprowski
Cc: Grant Likely
Cc: Rob Herring
---
drivers/of/of_reserved_mem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 62f467b..9394311 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -124,6 +124,10 @@ static int __init __reserved_mem_alloc_size(unsigned long
node,
align = dt_mem_next_cell(dt_root_addr_cells, &prop);
}
+ /* Need adjust the alignment to satisfy the CMA requirement */
+ if (IS_ENABLED(CONFIG_CMA) && of_flat_dt_is_compatible(node,
"shared-dma-pool"))
+ align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1,
pageblock_order));
+
prop = of_get_flat_dt_prop(node, "alloc-ranges", &len);
if (prop) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] cpufreq: arm_big_little: Add support to register a cpufreq cooling device
On Mon, Nov 09, 2015 at 05:29:23PM +, Punit Agrawal wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal
> Acked-by: Viresh Kumar
> Cc: Sudeep Holla
> Cc: Eduardo Valentin
> ---
> drivers/cpufreq/arm_big_little.c | 52
> ++--
> 1 file changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8..72a2777 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -55,6 +56,10 @@ static bool bL_switching_enabled;
> #define ACTUAL_FREQ(cluster, freq) ((cluster == A7_CLUSTER) ? freq << 1 :
> freq)
> #define VIRT_FREQ(cluster, freq)((cluster == A7_CLUSTER) ? freq >> 1 :
> freq)
>
> +struct private_data {
> + struct thermal_cooling_device *cdev;
> +};
> +
My first impression was that this is redundant and you could store the
pointer to cdev in driver_data itself. But seeing that it's mirroring
the structure in cpufreq-dt and it's simpler to do it this way I guess
it's ok to create this struct with only one pointer. You can add my
Reviewed-by: Javi Merino
> static struct cpufreq_arm_bL_ops *arm_bL_ops;
> static struct clk *clk[MAX_CLUSTERS];
> static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
> @@ -440,6 +445,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> {
> u32 cur_cluster = cpu_to_cluster(policy->cpu);
> struct device *cpu_dev;
> + struct private_data *priv;
> int ret;
>
> cpu_dev = get_cpu_device(policy->cpu);
> @@ -457,9 +463,15 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
> if (ret) {
> dev_err(cpu_dev, "CPU %d, cluster: %d invalid freq table\n",
> policy->cpu, cur_cluster);
> - put_cluster_clk_and_freq_table(cpu_dev);
> - return ret;
> + goto out_free_cpufreq_table;
> + }
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + ret = -ENOMEM;
> + goto out_free_cpufreq_table;
> }
> + policy->driver_data = priv;
>
> if (cur_cluster < MAX_CLUSTERS) {
> int cpu;
> @@ -484,12 +496,19 @@ static int bL_cpufreq_init(struct cpufreq_policy
> *policy)
>
> dev_info(cpu_dev, "%s: CPU %d initialized\n", __func__, policy->cpu);
> return 0;
> +
> +out_free_cpufreq_table:
> + put_cluster_clk_and_freq_table(cpu_dev);
> +
> + return ret;
> }
>
> static int bL_cpufreq_exit(struct cpufreq_policy *policy)
> {
> struct device *cpu_dev;
> + struct private_data *priv = policy->driver_data;
>
> + cpufreq_cooling_unregister(priv->cdev);
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> pr_err("%s: failed to get cpu%d device\n", __func__,
> @@ -498,11 +517,39 @@ static int bL_cpufreq_exit(struct cpufreq_policy
> *policy)
> }
>
> put_cluster_clk_and_freq_table(cpu_dev);
> + kfree(priv);
> dev_dbg(cpu_dev, "%s: Exited, cpu: %d\n", __func__, policy->cpu);
>
> return 0;
> }
>
> +static void bL_cpufreq_ready(struct cpufreq_policy *policy)
> +{
> + struct device *cpu_dev = get_cpu_device(policy->cpu);
> + struct device_node *np = of_node_get(cpu_dev->of_node);
> + struct private_data *priv = policy->driver_data;
> +
> + if (WARN_ON(!np))
> + return;
> +
> + if (of_find_property(np, "#cooling-cells", NULL)) {
> + u32 power_coefficient = 0;
> +
> + of_property_read_u32(np, "dynamic-power-coefficient",
> + &power_coefficient);
> +
> + priv->cdev = of_cpufreq_power_cooling_register(np,
> + policy->related_cpus, power_coefficient, NULL);
> + if (IS_ERR(priv->cdev)) {
> + dev_err(cpu_dev,
> + "running cpufreq without cooling device: %ld\n",
> + PTR_ERR(priv->cdev));
> + priv->cdev = NULL;
> + }
> + }
> + of_node_put(np);
> +}
> +
> static struct cpufreq_driver bL_cpufreq_driver = {
> .name = "arm-big-little",
> .flags = CPUFREQ_STICKY |
> @@ -513,6 +560,7 @@ static struct cpufreq_driver bL_cpufreq_driver = {
> .get= bL_cpufr
Re: [PATCH v3 2/3] cpufreq-dt: Supply power coefficient when registering cooling devices
On Mon, Nov 09, 2015 at 05:29:22PM +, Punit Agrawal wrote: > Support registering cooling devices with dynamic power coefficient > where provided by the device tree. This allows OF registered cooling > devices driver to be used with the power_allocator thermal governor. > > Signed-off-by: Punit Agrawal > Acked-by: Viresh Kumar > Cc: Eduardo Valentin > --- > drivers/cpufreq/cpufreq-dt.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) FWIW, Reviewed-by: Javi Merino -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Mon, Nov 09, 2015 at 11:13:32AM +0100, Sascha Hauer wrote: > This adds support for the Mediatek thermal controller found on MT8173 > and likely other SoCs. > The controller is a bit special. It does not have its own ADC, instead > it controls the on-SoC AUXADC via AHB bus accesses. For this reason > we need the physical address of the AUXADC. Also it controls a mux > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell. > > Signed-off-by: Sascha Hauer > --- > drivers/thermal/Kconfig | 8 + > drivers/thermal/Makefile | 1 + > drivers/thermal/mtk_thermal.c | 619 > ++ > 3 files changed, 628 insertions(+) > create mode 100644 drivers/thermal/mtk_thermal.c > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index 5aabc4b..503448a 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -348,6 +348,14 @@ config INTEL_PCH_THERMAL > Thermal reporting device will provide temperature reading, > programmable trip points and other information. > > +config MTK_THERMAL > + tristate "Temperature sensor driver for mediatek SoCs" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + default y > + help > + Enable this option if you want to have support for thermal management > + controller present in Mediatek SoCs > + > menu "Texas Instruments thermal drivers" > depends on ARCH_HAS_BANDGAP || COMPILE_TEST > source "drivers/thermal/ti-soc-thermal/Kconfig" > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile > index 26f1608..5f979e7 100644 > --- a/drivers/thermal/Makefile > +++ b/drivers/thermal/Makefile > @@ -45,3 +45,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL) += intel_pch_thermal.o > obj-$(CONFIG_ST_THERMAL) += st/ > obj-$(CONFIG_TEGRA_SOCTHERM) += tegra_soctherm.o > obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o > +obj-$(CONFIG_MTK_THERMAL)+= mtk_thermal.o > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c > new file mode 100644 > index 000..2d2e97c > --- /dev/null > +++ b/drivers/thermal/mtk_thermal.c > @@ -0,0 +1,619 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Hanyi Wu > + * > + * 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 > + > +/* AUXADC Registers */ > +#define AUXADC_CON0_V0x000 > +#define AUXADC_CON1_V0x004 > +#define AUXADC_CON1_SET_V0x008 > +#define AUXADC_CON1_CLR_V0x00c > +#define AUXADC_CON2_V0x010 > +#define AUXADC_DATA(channel) (0x14 + (channel) * 4) > +#define AUXADC_MISC_V0x094 > + > +#define AUXADC_CON1_CHANNEL(x) BIT(x) > + > +#define APMIXED_SYS_TS_CON1 0x604 > + > +/* Thermal Controller Registers */ > +#define TEMP_MONCTL0 0x000 > +#define TEMP_MONCTL1 0x004 > +#define TEMP_MONCTL2 0x008 > +#define TEMP_MONIDET00x014 > +#define TEMP_MONIDET10x018 > +#define TEMP_MSRCTL0 0x038 > +#define TEMP_AHBPOLL 0x040 > +#define TEMP_AHBTO 0x044 > +#define TEMP_ADCPNP0 0x048 > +#define TEMP_ADCPNP1 0x04c > +#define TEMP_ADCPNP2 0x050 > +#define TEMP_ADCPNP3 0x0b4 > + > +#define TEMP_ADCMUX 0x054 > +#define TEMP_ADCEN 0x060 > +#define TEMP_PNPMUXADDR 0x064 > +#define TEMP_ADCMUXADDR 0x068 > +#define TEMP_ADCENADDR 0x074 > +#define TEMP_ADCVALIDADDR0x078 > +#define TEMP_ADCVOLTADDR 0x07c > +#define TEMP_RDCTRL 0x080 > +#define TEMP_ADCVALIDMASK0x084 > +#define TEMP_ADCVOLTAGESHIFT 0x088 > +#define TEMP_ADCWRITECTRL0x08c > +#define TEMP_MSR00x090 > +#define TEMP_MSR10x094 > +#define TEMP_MSR20x098 > +#define TEMP_MSR30x0B8 > + > +#define TEMP_SPARE0 0x0f0 > + > +#define PTPCORESEL 0x400 > + > +#define TEMP_MONCTL1_PERIOD_UNIT(x) ((x) & 0x3ff) > + > +#define TEMP_MONCTL2_FILTER_INTERVAL(x) (((x) & 0x3ff)) << 16 > +#define TEMP_MONCTL2_SENSOR_INTERVAL(x) ((x) & 0x3ff) > + > +#define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)(x) > + > +#define TEMP_ADCWRITECTRL_ADC_PNP_WRITE BIT(0) > +#define TEMP_ADCWRITECTRL_ADC_MUX_WRITE BIT(1) > + > +#define TEMP_ADCVALIDMASK_VALID_HIGH BIT(5) > +#define TEMP_ADCVALIDM
Re: [PATCH v3 1/2] thermal: mediatek: Add cpu power cooling model.
On Fri, Nov 06, 2015 at 08:54:33AM +0530, Viresh Kumar wrote: > Cc'ing Javi (which you should have as he wrote the power-thing for > cpu-cooling). > > On 05-11-15, 19:10, dawei chien wrote: > > This is because our platform currently only support mt8173_cpufreq.c, so > > that I only add static power model for our owner IC. > > Bindings are (normally) supposed to be general than a platform > specific. > > > Please understanding that I wouldn't give a DT binding document since I > > will remove static power table on next version, but I can try to explain > > it. > > Then just don't add things in the first place. > > > As far as I know, static power is somewhat leakage of CPU clusters, so > > that we hardly to find a formula, which can suitable all kinds of CPUs > > since leakage is different. In ARM IPA framework, static power only need > > to be defined by who register cpufreq_power_cooling_register. The > > voltage/power table is just one way to present leakage power of CPUs. > > The bindings don't fix the values for static power, but just provides > a field for platforms to use. Everyone can then send its own power > figures. Why do you thing it can't be generalized? The way they are described here is useful only for this platform, but it's not generic. It only takes into account voltage as (I assume) it's the only variable that affects it in this implementation. A generalized version of the static power should take into account the temperature and the idle state. > > Actually, static power is optional since dynamic power is much more than > > static power. > > Maybe, we should still capture it. > > @Javi ? It really depends on the platform. If dawei says that for their platform static power is negligible then it is ok to not capture it. Cheers, Javi -- 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 08/10] ARM: dts: imx: Update vendor info for GE Bx50v3 boards
Am Donnerstag, den 05.11.2015, 13:13 -0500 schrieb Akshay Bhat:
> Update vendor and copyright info for GE Bx50v3 boards
>
> Signed-off-by: Akshay Bhat
This one and the following patches should be folded into the patches
introducing the files being patched here. They fix the original patches
and it makes no sense to merge patches with slightly wrong DTs, just to
immediately following up with patches to fix things.
Regards,
Lucas
> ---
> arch/arm/boot/dts/imx6q-b450v3.dts | 4 ++--
> arch/arm/boot/dts/imx6q-b650v3.dts | 4 ++--
> arch/arm/boot/dts/imx6q-b850v3.dts | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
> b/arch/arm/boot/dts/imx6q-b450v3.dts
> index d63d9e1..efe9c1e 100644
> --- a/arch/arm/boot/dts/imx6q-b450v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b450v3.dts
> @@ -1,6 +1,6 @@
> /*
> * Copyright 2015 Timesys Corporation.
> - * Copyright 2015 GE Healthcare.
> + * Copyright 2015 General Electric Company
> *
> * The code contained herein is licensed under the GNU General Public
> * License. You may obtain a copy of the GNU General Public License
> @@ -16,7 +16,7 @@
>
> / {
> model = "Advantech MX6Q B450V3 QSeven Board";
> - compatible = "adv,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
> + compatible = "ge,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
>
> chosen {
> stdout-path = &uart3;
> diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
> b/arch/arm/boot/dts/imx6q-b650v3.dts
> index 29cbdb0..d40efa9 100644
> --- a/arch/arm/boot/dts/imx6q-b650v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b650v3.dts
> @@ -1,6 +1,6 @@
> /*
> * Copyright 2015 Timesys Corporation.
> - * Copyright 2015 GE Healthcare.
> + * Copyright 2015 General Electric Company
> *
> * The code contained herein is licensed under the GNU General Public
> * License. You may obtain a copy of the GNU General Public License
> @@ -16,7 +16,7 @@
>
> / {
> model = "Advantech MX6Q B650V3 QSeven Board";
> - compatible = "adv,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
> + compatible = "ge,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
>
> chosen {
> stdout-path = &uart3;
> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
> b/arch/arm/boot/dts/imx6q-b850v3.dts
> index be6c0da..a77f392 100644
> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
> @@ -1,6 +1,6 @@
> /*
> * Copyright 2015 Timesys Corporation.
> - * Copyright 2015 GE Healthcare.
> + * Copyright 2015 General Electric Company
> *
> * The code contained herein is licensed under the GNU General Public
> * License. You may obtain a copy of the GNU General Public License
> @@ -16,7 +16,7 @@
>
> / {
> model = "Advantech MX6Q B850V3 QSeven Board";
> - compatible = "adv,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
> + compatible = "ge,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
>
> chosen {
> stdout-path = &uart3;
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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 07/10] of: Add vendor prefix for General Electric Company
Am Donnerstag, den 05.11.2015, 13:13 -0500 schrieb Akshay Bhat: > This patch adds vendor prefix for General Electric Company > > Signed-off-by: Akshay Bhat This patch should move to the beginning of the series. > --- > 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 2b3c5ac..71dcbd5 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -87,6 +87,7 @@ fcs Fairchild Semiconductor > firefly Firefly > focaltechFocalTech Systems Co.,Ltd > fsl Freescale Semiconductor > +ge General Electric Company > GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. > gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. > geniatechGeniatech, Inc. -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 02/32] devicetree: bindings: scsi: HiSi SAS
On 09/11/2015 18:01, Rob Herring wrote: On Tue, Nov 10, 2015 at 12:32:07AM +0800, John Garry wrote: Add devicetree bindings for HiSilicon SAS driver. Signed-off-by: John Garry Signed-off-by: Zhangfei Gao --- .../devicetree/bindings/scsi/hisilicon-sas.txt | 81 ++ 1 file changed, 81 insertions(+) create mode 100644 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt new file mode 100644 index 000..2333cc3 --- /dev/null +++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt @@ -0,0 +1,81 @@ +* HiSilicon SAS controller + +The HiSilicon SAS controller supports SAS/SATA. + +Main node required properties: + - compatible : value should be as follows: + (a) "hisilicon,sas-controller-v1" for v1 of HiSilicon SAS controller IP Please do a more specific compatible string with the SOC part number. Same versions of IP blocks can have different integration/process features/bugs. How about "hisilicon,hip05-sas-v1"? + - sas-addr : array of 8 bytes for host SAS address + - reg : Address and length of the SAS register + - hisilicon,sas-syscon: phandle of syscon used for sas control + - ctrl-reset-reg : offset to controller reset register in ctrl reg + - ctrl-reset-sts-reg : offset to controller reset status register in ctrl reg + - ctrl-clock-ena-reg : offset to controller clock enable register in ctrl reg + - queue-count : number of delivery and completion queues in the controller + - phy-count : number of phys accessible by the controller + - interrupts : Interrupts for phys, completion queues, and fatal + sources; the interrupts are ordered in 3 groups, as follows: + - Phy interrupts + - Completion queue interrupts + - Fatal interrupts + Phy interrupts : Each phy has 3 interrupt sources: + - broadcast + - phyup + - abnormal + The phy interrupts are ordered into groups of 3 per phy + (broadcast, phyup, and abnormal) in increasing order. + Completion queue interrupts : each completion queue has 1 + interrupt source. The interrupts are ordered in + increasing order. + Fatal interrupts : the fatal interrupts are ordered as follows: + - ECC + - AXI bus + +* HiSilicon SAS syscon + +Required properties: +- compatible: should be "hisilicon,sas-ctrl", "syscon" Please add a more specific compatible here too. We plan to remove this node now as it will be defined in the platform dt bindings: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt#n174 Rob Thanks, John -- 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] extcon: add MAX3355 driver
Hello.
On 11/10/2015 2:52 AM, Chanwoo Choi wrote:
I received the reply from you after too long time (17~18day).
You better to reply it more a little more quickly
if you have the question or new patches.
I've replied as soon as I had my new idea.
MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector. On some Renesas boards, this signal is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however, we'd like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
is controlled by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
Would be Maxim enough? Or perhaps I should use Maxim Integrated
[Products]?
You haven't replied to my questions.
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31 GPIO_ACTIVE_HIGH>;
OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...
Moreover, it now says "gpios" isn't allowed for the new bindings. So I
have to strongly disagree here...
OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
Thanks, done now. I just had another idea: how about I add an optional
"enable-gpio" property to the 'extcon-usb-gpio' driver? I wouldn't need my own
driver then at all... :-)
What is meaning of 'enable-gpio' property?
You better to explain your goal about 'enable-gpio' property
This optional property would serve for enabling the valid signal on the ID
GPIO, the same way I'm using the SHDN# GPIO in the MAX3355 driver.
Also, If you think that it is generic way about
adding 'enable-gpio' property to extcon-usb-gpio.c,
you can try it.
Yes, I think it would be generic enough.
Thanks,
Chanwoo Choi
MBR, Sergei
--
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 08/32] scsi: hisi_sas: add hisi_sas_remove
+int hisi_sas_remove(struct platform_device *pdev)
+{
+ struct sas_ha_struct *sha = platform_get_drvdata(pdev);
+ struct hisi_hba *hisi_hba = sha->lldd_ha;
+
+ sas_unregister_ha(sha);
+ sas_remove_host(sha->core.shost);
+ scsi_remove_host(sha->core.shost);
scsi host should be removed before detaching SAS transport.
See more information:
http://www.spinics.net/lists/linux-scsi/msg90088.html
Thanks,
Wei
OK, I can make this minor change.
Thanks,
John
+ hisi_sas_free(hisi_hba);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hisi_sas_remove);
+
static __init int hisi_sas_init(void)
{
pr_info("hisi_sas: driver version %s\n", DRV_VERSION);
.
--
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: Print rather than WARN'ing when overlap check fails
From: Michael Ellerman > Sent: 10 November 2015 05:09 > __rmem_check_for_overlap() is called very early in boot, and on some > powerpc systems it's not safe to call WARN that early in boot. > > If the overlap check fails the system will oops instead of printing a > warning. Furthermore because it's so early in boot the console is not up > and the user doesn't see the oops, they just get a dead system. Wouldn't it be better to add the required checks to WARN()? That would stop the same problem happening elsewhere. David
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On Mon, Nov 09, 2015 at 11:41:20AM -0600, Andrew F. Davis wrote: > On 11/06/2015 03:16 PM, Mark Brown wrote: > >There are cases where it's useful where we're abstracting something and > >gaining some meaningful reuse. This really does not appear to be one of > >those cases, there are no parameters in the DT and the compatible string > >is the full device name. > As before I see no reason to make that call now and limit ourselves. To repeat *yet* *again* the point is that putting the current Linux driver model into the DT is limiting our future selves. > >You do not need to populate it. There is no value in populating it and > >as previously discussed putting the Linux driver model into DT can be > >actively harmful if we change our idea of how we should model things. > The dev passed to regulator_register needs to have of_node populated for > your OF init_data helper to work. Devices with OF tables can just pass > their own dev. Others have to use their parents' nodes, this is a > workaround, OF devices should be probed with their of_node pre-populated. This is not a workaroud, the only reason you think it is a workaround is the desire to directly represent the Linux device model in the DT. > >>>Please stop this. I don't understand why you are pushing so hard to put > >>>the Linux device model representation of the device into DT but it's > >>>getting very repetitive. > >>I'm not pushing anything, this is how other sub-nodes of MFD devices are > >Every time we go through this we finish the discussion and then you come > >back with yet another excuse for trying to push the current Linux device > >model into the DT or another version of the patch with the same problem. > I keep finding different problems, do you expect me to ignore them? You are making minor restatements of the same thing over and over again which ignore the main feedback. > >The fact that other people have merged imperfect code into the kernel is > >not a good reason to merge even more of it when we have better tools. > >Looking at that binding I'm seeing no reason why any of the subfunctions > >should have compatible strings (and if we're going down the route you're > >trying to go down we really ought to have something in the binding for > >at least an interrupt controller in there as well...). > These are not "subfunctions" they are full drivers, they only need > register accessors passed in, they do not call the core and the core > does not call them. To repeat *yet* *again* they are groupings of functionality which happen to represent the way Linux models devices right now. There's no generality in there, it's just a dump of the current Linux model of the functions into the DT. > If your problem is with the DT binding for this or other MFDs, then > nack *them* and explain to everyone why what they are doing is wrong > and why regulators should be special cases. Blocking the regulator > drivers to force a change in DT is not going to fix this issue. Of course this is a negative review of the binding! What on earth did you think my feedback meant? The driver and the binding go together. signature.asc Description: PGP signature
Re: [PATCH] of: Print rather than WARN'ing when overlap check fails
On Tue, 2015-11-10 at 16:08 +1100, Michael Ellerman wrote:
> __rmem_check_for_overlap() is called very early in boot, and on some
> powerpc systems it's not safe to call WARN that early in boot.
>
> If the overlap check fails the system will oops instead of printing a
> warning. Furthermore because it's so early in boot the console is not up
> and the user doesn't see the oops, they just get a dead system.
>
> Fix it by printing an error instead of calling WARN.
>
> Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions")
> Signed-off-by: Michael Ellerman
> ---
> drivers/of/of_reserved_mem.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
I forgot to say, I assume you're OK to merge this and get it to Linus soonish?
Otherwise I can stuff it in a fix branch and ask Linus to pull that. Let me
know which you'd prefer.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: create a partition type device tree binding
On Tue, Nov 10, 2015 at 4:26 AM, Brian Norris wrote: > On Fri, Nov 06, 2015 at 08:13:13AM -0600, Rob Herring wrote: >> Since we now have partitions contained in a sub node, how about using >> compatible for that sub node instead. > > That seems like a pretty good idea to me. Hm! That's a clever idea. I'll take a spin on that. Yours, Linus Walleij -- 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] ARM: shmobile: koelsch: Move SPI FLASH partitions to subnode
As of commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
partitions in a special 'partitions' subnode"), having partitions as
direct subnodes of an mtd device is discouraged:
spi0.0: 'partitions' subnode not found on /spi@e6b1/flash@0. Trying to
parse direct subnodes as partitions.
Hence move the SPI FLASH partitions to a "partitions" subnode.
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index f63338ba3599ebc0..2cbd5e330c032533 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -490,8 +490,6 @@
status = "okay";
flash: flash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
compatible = "spansion,s25fl512s", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <3000>;
@@ -501,19 +499,24 @@
spi-cpol;
m25p,fast-read;
- partition@0 {
- label = "loader";
- reg = <0x 0x0008>;
- read-only;
- };
- partition@8 {
- label = "user";
- reg = <0x0008 0x0058>;
- read-only;
- };
- partition@60 {
- label = "flash";
- reg = <0x0060 0x03a0>;
+ partitions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "loader";
+ reg = <0x 0x0008>;
+ read-only;
+ };
+ partition@8 {
+ label = "user";
+ reg = <0x0008 0x0058>;
+ read-only;
+ };
+ partition@60 {
+ label = "flash";
+ reg = <0x0060 0x03a0>;
+ };
};
};
};
--
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 v5 10/11] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller
Hi Rob, On 11/09/2015 09:53 PM, Rob Herring wrote: On Mon, Nov 09, 2015 at 10:56:26AM +0530, Alim Akhtar wrote: From: Seungwon Jeon This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings. Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar --- .../devicetree/bindings/ufs/ufs-exynos.txt | 104 1 file changed, 104 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt new file mode 100644 index ..08e2d1497b1b --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt @@ -0,0 +1,104 @@ +* Exynos Universal Flash Storage (UFS) Host Controller + +UFSHC nodes are defined to describe on-chip UFS host controllers. +Each UFS controller instance should have its own node. + +Required properties: +- compatible: compatible name, contains "samsung,exynos7-ufs" +- interrupts: +- reg : Should contain HCI, vendor specific, UNIPRO and + UFS protector address space +- reg-names: "hci", "vs_hci", "unipro", "ufsp"; No phy for MPHY? ufs-phy is documented, see 01/11 of this series. + +Optional properties: +- vdd-hba-supply: phandle to UFS host controller supply regulator node +- vcc-supply: phandle to VCC supply regulator node +- vccq-supply : phandle to VCCQ supply regulator node +- vccq2-supply : phandle to VCCQ2 supply regulator node +- vcc-supply-1p8: For embedded UFS devices, valid VCC range is 1.7-1.95V + or 2.7-3.6V. This boolean property when set, specifies + to use low voltage range of 1.7-1.95V. Note for external + UFS cards this property is invalid and valid VCC range is + always 2.7-3.6V. +- vcc-max-microamp : specifies max. load that can be drawn from vcc supply +- vccq-max-microamp : specifies max. load that can be drawn from vccq supply +- vccq2-max-microamp: specifies max. load that can be drawn from vccq2 supply Some of these are supplies to the flash chip, so you should make these common properties (in a common doc). Ah, yes these are duplicated, already documented in common ufshcd file Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt What is the recommended way, do I need to include it here as well? or just mentioning that "same as documented in ufshcd-pltfrm.txt"? +- -fixed-regulator : boolean property specifying that -supply is a fixed regulator This should be determined from the regulator. Same as above already documented as part of ufshcd-pltfrm binding. + +- clocks: List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. + "core", "sclk_unipro_main", "ref" and ref_parent + +- freq-table-hz: Array of operating frequencies stored in the same + order as the clocks property. If this property is not + defined or a value in the array is "0" then it is assumed + that the frequency is set by the parent clock or a + fixed rate clock source. +- pclk-freq-avail-range : specifies available frequency range(min/max) for APB clock +- ufs,pwr-attr-mode : specifies mode value for power mode change, possible values are + "FAST", "SLOW", "FAST_auto" and "SLOW_auto" ufs is not a vendor. Use a '-' rather than ','. Ok will change. +- ufs,pwr-attr-lane : specifies lane count value for power mode change + allowed values are 1 or 2 +- ufs,pwr-attr-gear : specifies gear count value for power mode change + allowed values are 1 or 2 +- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change + can be one of "HS_rate_b" or "HS_rate_a" +- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values + 3 timers supported + +- ufs,pwr-remote-l2-timer : specifies array of remote UNIPRO L2 timer values + 3 timers supported + +- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY, + this is a boolean property. +- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY, + allowed step size is 0 to 3 +- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate time of MPHY +range is 1 to 9 +- ufs-pa-granularity : specifies Granularity for PA_TActivate and PA_Hibern8Time +- ufs-pa-tacctivate : specifies time to wake-up remote M-
Re: [PATCH] ARM: dt: zynq: Add labels to cpu nodes to allow overriding OPPs.
On 11/09/2015 07:55 PM, Sören Brinkmann wrote: > On Mon, 2015-11-09 at 10:51AM -0800, Moritz Fischer wrote: >> By adding labels to the cpu nodes in the dtsi, a dts that >> includes it can change the OPPs by referencing the cpu0 >> through the label. >> >> Signed-off-by: Moritz Fischer > Reviewed-by: Sören Brinkmann Applied to zynq/dt. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
