* Re: [PATCH v3 1/2] dt-bindings: iio: stm32-dac: Add support for STM32 DAC
From: Rob Herring @ 2017-04-13 20:22 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg,
benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A,
benjamin.gaignard-qxv4g6HH51o
In-Reply-To: <1491839390-2449-2-git-send-email-fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
On Mon, Apr 10, 2017 at 05:49:49PM +0200, Fabrice Gasnier wrote:
> Document STMicroelectronics STM32 DAC (digital-to-analog converter).
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
> ---
> Changes in v2:
> - use 'reg' instead of 'st,dac-channel' property
> - remove alignment from description
> ---
> .../devicetree/bindings/iio/dac/st,stm32-dac.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v5] dt-bindings: fpga: Add bindings document for Xilinx LogiCore PR Decoupler
From: Alan Tull @ 2017-04-13 20:25 UTC (permalink / raw)
To: Rob Herring
Cc: Moritz Fischer, linux-fpga, devicetree@vger.kernel.org,
linux-kernel, Greg Kroah-Hartman, Michal Simek,
Sören Brinkmann
In-Reply-To: <20170413200728.z6t2c7e6jobpstmb@rob-hp-laptop>
On Thu, Apr 13, 2017 at 3:07 PM, Rob Herring <robh@kernel.org> wrote:
> On Sun, Apr 09, 2017 at 10:10:31AM -0700, Moritz Fischer wrote:
>> This adds the binding documentation for the Xilinx LogiCORE PR
>> Decoupler soft core.
>>
>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> Acked-by: Alan Tull <atull@kernel.org>
>> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: devicetree@vger.kernel.org
>> ---
>>
>> Changes from v4:
>> - Ssubject line
>> - Replaced 'or' by 'followed by' as suggested by Rob
>>
>> Changes from v3:
>> - Addressed Michal's comments
>> - Addressed Alan's Comments
>> - Added Alan's Acked-by
>>
>> Changes from v2:
>> - Added refence to generic fpga-region bindings
>> - Fixed up reg property in example
>> - Added fallback to "xlnx,pr-decoupler" without version
>>
>> Changes from v1:
>> - Added clock names & clock to example
>> - Merged some of the description from Michal's version
>>
>> ---
>> .../bindings/fpga/xilinx-pr-decoupler.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>> new file mode 100644
>> index 0000000..b2c58fb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>> @@ -0,0 +1,36 @@
>> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
>> +
>> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
>> +decouplers / fpga bridges.
>> +The controller can decouple/disable the bridges which prevents signal
>> +changes from passing through the bridge. The controller can also
>> +couple / enable the bridges which allows traffic to pass through the
>> +bridge normally.
>> +
>> +The Driver supports only MMIO handling. A PR region can have multiple
>> +PR Decouplers which can be handled independently or chained via decouple/
>> +decouple_status signals.
>> +
>> +Required properties:
>> +- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by
>> + "xlnx,pr-decoupler"
>> +- regs : base address and size for decoupler module
>> +- clocks : input clock to IP
>> +- clock-names : should contain "aclk"
>> +
>> +Optional properties:
>> +- bridge-enable : 0 if driver should disable bridge at startup
>> + 1 if driver should enable bridge at startup
>> + Default is to leave bridge in current state.
>
> Did this get into a common location? If so, then just "see .../?.txt" is
> enough of a description.
IIRC we went with this as is, with the intent of moving it to
a common location in a separate patch. This binding shows
up in a a few bindings docs, so one patch could move it from all
of them at the same time. That hasn't happened yet.
Alan
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020
From: Rob Herring @ 2017-04-13 20:35 UTC (permalink / raw)
To: Martin Kepplinger
Cc: Dmitry Torokhov, christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w,
linux-0h96xk9xTtrk1uMJSBkQmQ, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fd7e784f-824c-1fff-4978-858c11971999-hfTNJOUbDMh54TAoqtyWWQ@public.gmane.org>
On Thu, Apr 13, 2017 at 08:38:39AM +0200, Martin Kepplinger wrote:
>
>
> On 2017-04-12 17:40, Dmitry Torokhov wrote:
> > Hi Martin,
> >
> > On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote:
> >> ar1021_i2c simply also supports the ar1020 device we use. This is tested.
> >> They also share the same datasheet:
> >>
> >> http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf
> >>
> >> We differentiate not only to make it obvious that we support both devices,
> >> but also to be able to implement the few model specific things in the
> >> future.
[...]
> >
> > I do not see where you handle ar1020 differently from ar1021. If devices
> > are compatible, you do not need to add a new compatible to the driver,
> > simply use it in the binding:
> >
> > compatible = "microchip,ar1020-i2c", "microchip,ar1021-i2c";
> >
> > Thanks.
> >
>
> Why would you use "microchip,ar1020-i2c" in the dts if it's not
> available? people don't obviously see, by grepping or reading,
> that they have a compatible driver. ... or did I get you wrong?
>
> I don't handle anything differently now. Factory reset has to be done
> differntly though, as one example. So it'd be nice to have the option
> to add data.
Having both lets you use the current driver now and you can match on the
more specific compatible string when and if you need to. That's exactly
why we have multiple compatibles. I could imagine the driver never
supports factory reset. Add both to comments or kconfig help if you want
to make it clear that both devices are supported.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: devicetree: bindings: add bindings doc for ar1021 driver
From: Rob Herring @ 2017-04-13 20:40 UTC (permalink / raw)
To: Martin Kepplinger
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w,
linux-0h96xk9xTtrk1uMJSBkQmQ, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491906479-17639-2-git-send-email-martin.kepplinger-hfTNJOUbDMh54TAoqtyWWQ@public.gmane.org>
On Tue, Apr 11, 2017 at 12:27:58PM +0200, Martin Kepplinger wrote:
> Add a simple binding document highlighting the supported devices and
> I2C bus address.
"dt-bindings: input: ..." for the subject please.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger-hfTNJOUbDMh54TAoqtyWWQ@public.gmane.org>
> ---
> .../devicetree/bindings/input/touchscreen/ar1021.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
> new file mode 100644
> index 0000000..87a8c72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/ar1021.txt
> @@ -0,0 +1,16 @@
> +* Microchip AR1020 and AR1021 touchscreen interface (I2C)
> +
> +Required properties:
> +- compatible : use "microchip,ar1020-i2c" or "microchip,ar1021-i2c"
> +- reg : I2C slave address
> +- interrupt-parent : the phandle for the interrupt controller
> +- interrupts : touch controller interrupt
> +
> +Example:
> +
> + ar1020: ar1020@4d {
touchscreen@4d
> + compatible = "microchip,ar1020-i2c";
> + reg = <0x4d>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> + };
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Peter Rosin @ 2017-04-13 20:43 UTC (permalink / raw)
To: Javier Martinez Canillas, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Alexandre Belloni, Rob Herring, Nicolas Ferre, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170413182839.25381-6-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 2017-04-13 20:28, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> Changes in v2: None
>
> arch/arm/boot/dts/at91-linea.dtsi | 2 +-
> arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
> index 0721c8472509..9a19080fd3bf 100644
> --- a/arch/arm/boot/dts/at91-linea.dtsi
> +++ b/arch/arm/boot/dts/at91-linea.dtsi
> @@ -31,7 +31,7 @@
> status = "okay";
>
> eeprom@51 {
> - compatible = "st,24c64";
> + compatible = "st,24c64","atmel,24c64";
> reg = <0x51>;
> pagesize = <32>;
> };
> diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
> index 7a68805a4eb5..6f005c14a6b0 100644
> --- a/arch/arm/boot/dts/at91-tse850-3.dts
> +++ b/arch/arm/boot/dts/at91-tse850-3.dts
> @@ -239,7 +239,7 @@
> };
>
> eeprom@50 {
> - compatible = "nxp,24c02";
> + compatible = "nxp,24c02","atmel,24c02";
> reg = <0x50>;
> pagesize = <16>;
> };
>
Sure, in principle. But not having a space after the commas is a real OCD
trigger for me. My spine is rotating... :-)
Anyway, with those whitespace fixes (and without them too, but please):
Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] ASoC: stm32: add bindings for SAI
From: Rob Herring @ 2017-04-13 20:45 UTC (permalink / raw)
To: olivier moysan
Cc: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-F5mvAk5X5gdBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnaud.pouliquen-qxv4g6HH51o,
benjamin.gaignard-qxv4g6HH51o
In-Reply-To: <1491925646-29113-2-git-send-email-olivier.moysan-qxv4g6HH51o@public.gmane.org>
On Tue, Apr 11, 2017 at 05:47:25PM +0200, olivier moysan wrote:
> This patch adds documentation of device tree bindings for the
> STM32 SAI ASoC driver.
>
> Signed-off-by: olivier moysan <olivier.moysan-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/sound/st,stm32-sai.txt | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-sai.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> new file mode 100644
> index 0000000..c59a3d7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> @@ -0,0 +1,89 @@
> +STMicroelectronics STM32 Serial Audio Interface (SAI).
> +
> +The SAI interface (Serial Audio Interface) offers a wide set of audio protocols
> +as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97.
> +The SAI contains two independent audio sub-blocks. Each sub-block has
> +its own clock generator and I/O lines controller.
> +
> +Required properties:
> + - compatible: Should be "st,stm32f4-sai"
> + - reg: Base address and size of SAI common register set.
> + - clocks: Must contain phandle and clock specifier pairs for each entry
> + in clock-names.
> + - clock-names: Must contain "x8k" and "x11k"
> + "x8k": SAI parent clock for sampling rates multiple of 8kHz.
> + "x11k": SAI parent clock for sampling rates multiple of 11.025kHz.
> + - interrupts: cpu DAI interrupt line shared by SAI sub-blocks
> +
> +Optional properties:
> + - resets: Reference to a reset controller asserting the SAI
> +
> +SAI subnodes:
> +Two subnodes corresponding to SAI sub-block instances A et B can be defined.
> +Subnode can be omitted for unsused sub-block.
> +
> +SAI subnodes required properties:
> + - compatible: Should be "st,stm32-sai-sub-a" or "st,stm32-sai-sub-b"
> + for SAI sub-block A or B respectively.
> + - reg: Base address and size of SAI sub-block register set.
> + - clocks: Must contain one phandle and clock specifier pair
> + for sai_ck which feeds the internal clock generator.
> + - clock-names: Must contain "sai_ck".
> + - dmas: see Documentation/devicetree/bindings/dma/stm32-dma.txt
> + - dma-names: identifier string for each DMA request line
> + "tx": if sai sub-block is configured as playback DAI
> + "rx": if sai sub-block is configured as capture DAI
> + - pinctrl-names: should contain only value "default"
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> +
> +Example:
> +sound_card {
> + compatible = "audio-graph-card";
> + dais = <&sai1b_port>;
> +};
> +
> +sai1: sai1@40015800 {
> + compatible = "st,stm32f4-sai";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
It's preferred if this is not empty and it limited to the address range
needed.
> + reg = <0x40015800 0x4>;
> + clocks = <&rcc 1 CLK_SAIQ_PDIV>, <&rcc 1 CLK_I2SQ_PDIV>;
> + clock-names = "x8k", "x11k";
> + interrupts = <87>;
> +
> + sai1b: audio-controller@40015824 {
> + #sound-dai-cells = <0>;
> + compatible = "st,stm32-sai-sub-b";
> + reg = <0x40015824 0x1C>;
> + clocks = <&rcc 1 CLK_SAI2>;
> + clock-names = "sai_ck";
> + dmas = <&dma2 5 0 0x400 0x0>;
> + dma-names = "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai1b>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sai1b_port: port@0 {
Need to document how many ports and endpoints.
> + reg = <0>;
For a single port, you don't need a reg prop.
> + cpu_endpoint: endpoint {
> + remote-endpoint = <&codec_endpoint>;
> + audio-graph-card,format = "i2s";
> + audio-graph-card,bitclock-master = <&codec_endpoint>;
> + audio-graph-card,frame-master = <&codec_endpoint>;
The prefix is gone now.
> + };
> + };
> + };
> + };
> +};
> +
> +audio-codec {
> + codec_port: port {
> + codec_endpoint: endpoint {
> + remote-endpoint = <&cpu_endpoint>;
> + };
> + };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 4/8] regulator: core: Check enabling bypass respects constraints
From: Leonard Crestez @ 2017-04-13 20:46 UTC (permalink / raw)
To: Mark Brown
Cc: Sascha Hauer, Liam Girdwood, Viresh Kumar, Rafael J. Wysocki,
Shawn Guo, Robin Gong, Anson Huang, Irina Tirdea, Rob Herring,
Mark Rutland, Fabio Estevam, Octavian Purdila,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170407112212.gzv3p7ldkh62657m-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Fri, 2017-04-07 at 12:22 +0100, Mark Brown wrote:
> On Fri, Apr 07, 2017 at 01:51:52PM +0300, Leonard Crestez wrote:
> > It currently seems to work how I expect but from your statement it's
> > not clear if it's entirely intentional.
> The current behaviour of bypassed regulators is intentional.
I did not mean to imply that there is something wrong with bypassed
regulators. I just wanted more information about how regulators (non-
bypassed) pick their voltage when consumers allow a range.
After some more reading through the code it seems that the driver
itself receives the range (either through set_voltage or map_voltage)
and gets to make the choice.
So it seems fine for my concerns, sorry to bother you.
--
Regards,
Leonard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Fabio Estevam @ 2017-04-13 20:49 UTC (permalink / raw)
To: Tyler Baker
Cc: Andrey Smirnov, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CANMBJr7We9uOyE6=BCWoe9L7xRKjOG6ScgtDGEgQ-hPawPeppg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 5:13 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> I've rebased this series on the next-20170413 for sanity sake, and
> realized there doesn't appear to be a way to select CONFIG_IMX_GPCV2.
> I forced it using 'default y' and configured with imx_v6_v7_defconfig.
> Now my board is booting. Before this series is applied, it may be good
> to have CONFIG_IMX_GPCV2 selected specifically for iMX7 platform,
> otherwise there will be boot regressions.
Something like this?
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f03ef43..fe99a48 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -253,6 +253,7 @@ config RENESAS_H8S_INTC
config IMX_GPCV2
bool
+ def_bool y if SOC_IMX7D
select IRQ_DOMAIN
help
Enables the wakeup IRQs for IMX platforms with GPCv2 block
>
> I'd encounter a backtrace with next-20170413 + imx_v6_v7_defconfig +
> CONFIG_IMX_GPCV2=y
>
> Backtrace:
> [<c010c364>] (dump_backtrace) from [<c010c610>] (show_stack+0x18/0x1c)
but prior to fixing the Kconfig we need to fix this backtrace you reported.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory
From: Guenter Roeck @ 2017-04-13 21:03 UTC (permalink / raw)
To: Moritz Fischer
Cc: linux-hwmon, linux-kernel, devicetree, lee.jones, olof, jdelvare,
robh+dt, mark.rutland, Moritz Fischer
In-Reply-To: <1491602410-31518-1-git-send-email-moritz.fischer@ettus.com>
On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
> From: Moritz Fischer <mdf@kernel.org>
>
> The ChromeOS EC has mapped memory regions where things like temperature
> sensors and fan speed are stored. Provide access to those from the
> cros-ec mfd device.
>
Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?
Thanks,
Guenter
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> ---
> drivers/platform/chrome/cros_ec_proto.c | 55 +++++++++++++++++++++++++++++++++
> include/linux/mfd/cros_ec.h | 39 +++++++++++++++++++++++
> 2 files changed, 94 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c b/drivers/platform/chrome/cros_ec_proto.c
> index ed5dee7..28063de 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
> return get_keyboard_state_event(ec_dev);
> }
> EXPORT_SYMBOL(cros_ec_get_next_event);
> +
> +static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t offset,
> + void *buf, size_t size)
> +{
> + int ret;
> + struct ec_params_read_memmap *params;
> + struct cros_ec_command *msg;
> +
> + msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->version = 0;
> + msg->command = EC_CMD_READ_MEMMAP;
> + msg->insize = size;
> + msg->outsize = sizeof(*params);
> +
> + params = (struct ec_params_read_memmap *)msg->data;
> + params->offset = offset;
> + params->size = size;
> +
> + ret = cros_ec_cmd_xfer(ec, msg);
> + if (ret < 0 || msg->result != EC_RES_SUCCESS) {
> + dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
> + ret, msg->result);
> + goto out_free;
> + }
> +
> + memcpy(buf, msg->data, size);
> +
> +out_free:
> + kfree(msg);
> + return ret;
> +}
> +
> +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
> + uint32_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
> +
> +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
> + uint16_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
> +
> +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
> + uint8_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index b3d04de..c2de878 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -190,6 +190,45 @@ struct cros_ec_dev {
> };
>
> /**
> + * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
> + uint8_t *data);
> +
> +/**
> + * cros_ec_read_mapped_mem16 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
> + uint16_t *data);
> +
> +/**
> + * cros_ec_read_mapped_mem32 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
> + uint32_t *data);
> +
> +/**
> * cros_ec_suspend - Handle a suspend operation for the ChromeOS EC device
> *
> * This can be called by drivers to handle a suspend event.
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON
From: Guenter Roeck @ 2017-04-13 21:07 UTC (permalink / raw)
To: Rob Herring
Cc: Moritz Fischer, linux-hwmon, linux-kernel, devicetree, lee.jones,
olof, jdelvare, mark.rutland, Moritz Fischer
In-Reply-To: <20170413200140.lcynmsv255ktoiyl@rob-hp-laptop>
On Thu, Apr 13, 2017 at 03:01:40PM -0500, Rob Herring wrote:
> On Fri, Apr 07, 2017 at 03:00:09PM -0700, Moritz Fischer wrote:
> > From: Moritz Fischer <mdf@kernel.org>
> >
> > Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
> > allows monitoring of temperature sensors and fans attached to the
> > EC.
> >
> > Signed-off-by: Moritz Fischer <mdf@kernel.org>
> > ---
> > .../devicetree/bindings/hwmon/cros-ec-hwmon.txt | 25 ++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> > new file mode 100644
> > index 0000000..4c94869
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> > @@ -0,0 +1,25 @@
> > +Chromium Embedded Controller EC temperature and fan control
> > +-----------------------------------------------------------
> > +
> > +Google's Chromium EC HWMON is a hwmon implemented byimplemented by the Chromium EC
> > +firmware attached to the Embedded Controller (EC) and controlled via a host-command
> > +interface.
> > +
> > +An EC HWMON node should be only found as a sub-node of the EC node (see
> > +Documentation/devicetree/bindings/mfd/cros-ec.txt).
> > +
> > +Required properties:
> > +- compatible: Must contain "google,cros-ec-hwmon"
> > +
> > +Example:
> > + embedded-controller@1e {
> > + reg = <0x1e>;
> > + compatible = "google,cros-ec-i2c";
> > + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-parent = <&gpio0>;
> > +
> > + hwmon {
> > + compatible = "google,cros-ec-hwmon";
>
> This is sufficient for all devices? I don't see that DT provides
> anything here other than instantiating a device, but the parent device
> can just as easily do that.
>
The parent driver (drivers/mfd/cros_ec_i2c.c) calls cros_ec_register(),
which uses uses of_platform_populate() to populate all sub-devices.
There are various examples in the dts files (look for "google,cros-ec").
Does it really make sense to start a second method for instantiating
sub-devices ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 21:09 UTC (permalink / raw)
To: Peter Rosin, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
Alexandre Belloni, Rob Herring, Nicolas Ferre, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Geert Uytterhoeven
In-Reply-To: <869a0f44-6c97-2109-776b-6da9b86c732a-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Hello Peter,
On 04/13/2017 05:43 PM, Peter Rosin wrote:
> On 2017-04-13 20:28, Javier Martinez Canillas wrote:
[snip]
>>
>> eeprom@50 {
>> - compatible = "nxp,24c02";
>> + compatible = "nxp,24c02","atmel,24c02";
>> reg = <0x50>;
>> pagesize = <16>;
>> };
>>
>
> Sure, in principle. But not having a space after the commas is a real OCD
> trigger for me. My spine is rotating... :-)
>
Right, Geert already pointed out. It's something I missed in my sed script
so I got it wrong in all the DTS :(
I'll fix my script and send a v2.
> Anyway, with those whitespace fixes (and without them too, but please):
> Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>
Thanks for the review!
> Cheers,
> peda
>
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Andrey Smirnov @ 2017-04-13 21:19 UTC (permalink / raw)
To: Tyler Baker
Cc: Shawn Guo, Andrey Yurovsky, Sascha Hauer, Fabio Estevam,
Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel
In-Reply-To: <CANMBJr5sFeVxVq2w2uUd-ehXi9SpaJ7W9S_PTS_VN25YZEdXvQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 12:03 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Andrey,
>
> On 13 April 2017 at 06:32, Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Add node for GPC and specify as a parent interrupt controller for SoC bus.
>>
>> Cc: yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/imx7s.dtsi | 27 ++++++++++++++++++++++++++-
>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
>> index 8fee299..1a7058f 100644
>> --- a/arch/arm/boot/dts/imx7s.dtsi
>> +++ b/arch/arm/boot/dts/imx7s.dtsi
>> @@ -42,6 +42,7 @@
>> */
>>[0
>> #include <dt-bindings/clock/imx7d-clock.h>
>> +#include <dt-bindings/power/imx7-power.h>
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> @@ -119,7 +120,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "simple-bus";
>> - interrupt-parent = <&intc>;
>> + interrupt-parent = <&gpc>;
>
> I've been testing your GPC/PCIe patch sets against v4.11-rc5 on my
> imx7d-cl-som-imx7, but hit a bit of a wall. When gpc is set as the
> interrupt-parent for the soc, the kernel seems to hang and not produce
> any output on the serial port[0]. I tried to enable earlyprintk, but
> no luck getting a trace. Reversing this change, gets the board
> booting[1], but obviously isn't using the gpc which is needed for PCIe
> support as I understand it. I assume you've tested these changes on a
> imx7d-sdb and are not seeing a similar issue? You can find the patches
> I've picked on top of v4.11-rc5 here[2], any idea what might be the
> issue?
Hmm, this is something new and I don't think I've seen it(neither that
nor the backtrace from your following e-mail). Here's the kernel tree
as I've been testing it:
https://github.com/ndreys/linux/commits/imx7d/pcie-support-v8
note, however, that it is based on d0ec4e6 (tip of pci/next when I was
rebasing) of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git,
which is not exactly v4.11-rc5
I'll rebase on top v4.11-r5 and see if I can get the same backtrace
you are getting and see if I can fix it.
Thanks and sorry for breaking things for you,
Andrey Smirnov
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Andrey Smirnov @ 2017-04-13 21:20 UTC (permalink / raw)
To: Fabio Estevam
Cc: Tyler Baker, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
Andrey Yurovsky
In-Reply-To: <CAOMZO5BjzSJws7zjJ5+aZkfeF+15twEu9zS3V+g6wQrtUiNyqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 1:49 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 5:13 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> I've rebased this series on the next-20170413 for sanity sake, and
>> realized there doesn't appear to be a way to select CONFIG_IMX_GPCV2.
>> I forced it using 'default y' and configured with imx_v6_v7_defconfig.
>> Now my board is booting. Before this series is applied, it may be good
>> to have CONFIG_IMX_GPCV2 selected specifically for iMX7 platform,
>> otherwise there will be boot regressions.
>
> Something like this?
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index f03ef43..fe99a48 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -253,6 +253,7 @@ config RENESAS_H8S_INTC
>
> config IMX_GPCV2
> bool
> + def_bool y if SOC_IMX7D
> select IRQ_DOMAIN
> help
> Enables the wakeup IRQs for IMX platforms with GPCv2 block
>
FWIW, there's a patch for this that I haven't submitted yet (I plan to
submit it tomorrow):
https://github.com/ndreys/linux/commit/bd2de5be5c74bb35a0b8090f473862c9298a48b3
Thanks,
Andrey Smirnov
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Alexandre Belloni @ 2017-04-13 21:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Peter Rosin, linux-kernel, Wolfram Sang, devicetree, Russell King,
Rob Herring, Nicolas Ferre, Mark Rutland, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <dd93eb32-ca1e-5041-051e-c4f072f0f9a2@osg.samsung.com>
On 13/04/2017 at 18:09:56 -0300, Javier Martinez Canillas wrote:
> Hello Peter,
>
> On 04/13/2017 05:43 PM, Peter Rosin wrote:
> > On 2017-04-13 20:28, Javier Martinez Canillas wrote:
>
> [snip]
>
> >>
> >> eeprom@50 {
> >> - compatible = "nxp,24c02";
> >> + compatible = "nxp,24c02","atmel,24c02";
> >> reg = <0x50>;
> >> pagesize = <16>;
> >> };
> >>
> >
> > Sure, in principle. But not having a space after the commas is a real OCD
> > trigger for me. My spine is rotating... :-)
> >
>
> Right, Geert already pointed out. It's something I missed in my sed script
> so I got it wrong in all the DTS :(
>
> I'll fix my script and send a v2.
>
That would be v3, right? ;)
> > Anyway, with those whitespace fixes (and without them too, but please):
> > Acked-by: Peter Rosin <peda@axentia.se>
> >
>
> Thanks for the review!
>
I'd like to be copied on the first patches to ensure they are applied
before applying that one. (Also, it is probably too late for 4.12 anyway
because we are past rc6).
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: dt: i2c: Add Altera I2C Controller
From: Rob Herring @ 2017-04-13 21:22 UTC (permalink / raw)
To: thor.thayer-VuQAYsv1563Yd54FQh9/CA
Cc: wsa-z923LK4zBo2bacvFa/9K2g, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491926547-29510-3-git-send-email-thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Tue, Apr 11, 2017 at 11:02:26AM -0500, thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org wrote:
> From: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Add the documentation to support the Altera I2C Controller.
"dt-bindings: i2c: ..." for the subject.
>
> Signed-off-by: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> .../devicetree/bindings/i2c/i2c-altera.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-altera.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-altera.txt b/Documentation/devicetree/bindings/i2c/i2c-altera.txt
> new file mode 100644
> index 0000000..a67241c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-altera.txt
> @@ -0,0 +1,37 @@
> +* Altera I2C Controller
This is the only one? For synthesizable logic or a hard block in
socfpga?
> +
> +Required properties :
> + - compatible : should be "altr,sip-i2c"
Seems kind of generic.
> + - reg : Offset and length of the register set for the device
> + - interrupts : <IRQ> where IRQ is the interrupt number.
> + - clocks : phandles to input clocks.
Need to specify how many clocks.
> + - #address-cells = <1>;
> + - #size-cells = <0>;
> +
> +Recommended properties :
> + - clock-frequency : desired I2C bus clock frequency in Hz.
> +
> +Optional properties :
> + - altr,fifo-size : Size of the RX and TX FIFOs.
in bytes?
Just "fifo-size" is already fairly common, so drop the vendor prefix.
> + - Child nodes conforming to i2c bus binding
> +
> +Example :
> +
> + i2c@100080000 {
> + compatible = "altr,sip-i2c";
> + reg = <0x00000001 0x00080000 0x00000040>;
> + interrupt-parent = <&intc>;
> + interrupts = <0 43 4>;
> + clocks = <&clk_0>;
> + clock-frequency = <100000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + altr,fifo-size = <4>;
> +
> + eeprom@51 {
> + compatible = "atmel,24c32";
> + reg = <0x51>;
> + pagesize = <32>;
> + };
> + };
> +
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: at91: use correct compatible for the gpio mux controller
From: Peter Rosin @ 2017-04-13 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Nicolas Ferre, Alexandre Belloni, Rob Herring,
Mark Rutland, Russell King, linux-arm-kernel, devicetree
The compatible string for a gpio based mux controller is "gpio-mux",
and nothing else.
Fixes: 29dd89418007 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi!
The compatible string for the gpio based mux changed along the way (on
request from Rob) but I failed to update the implementation in the
gpio-mux driver when I made that change. Consequently, I didn't notice
that I didn't update the compatible string here either, since it all
continued to work in my tests...
The compatible string in the gpio-mux driver is being fixed to match
documentation, so this of course needs fixing too. No TSE-850 devices
are affected, except for the one on my desk.
Sorry for the churn.
Cheers,
peda
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
index 6a724cfb5389..168665e56a56 100644
--- a/arch/arm/boot/dts/at91-tse850-3.dts
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -204,7 +204,7 @@
};
mux: mux-controller {
- compatible = "mux-gpio";
+ compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v5] dt-bindings: fpga: Add bindings document for Xilinx LogiCore PR Decoupler
From: Rob Herring @ 2017-04-13 21:24 UTC (permalink / raw)
To: Alan Tull
Cc: Moritz Fischer, linux-fpga-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Greg Kroah-Hartman, Michal Simek, Sören Brinkmann
In-Reply-To: <CANk1AXQGXdAY_vz5GzujQL1ziqa5W23bGvkUPU2u5BaJKhBzrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 3:25 PM, Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 3:07 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Sun, Apr 09, 2017 at 10:10:31AM -0700, Moritz Fischer wrote:
>>> This adds the binding documentation for the Xilinx LogiCORE PR
>>> Decoupler soft core.
>>>
>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> Acked-by: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> ---
>>>
>>> Changes from v4:
>>> - Ssubject line
>>> - Replaced 'or' by 'followed by' as suggested by Rob
>>>
>>> Changes from v3:
>>> - Addressed Michal's comments
>>> - Addressed Alan's Comments
>>> - Added Alan's Acked-by
>>>
>>> Changes from v2:
>>> - Added refence to generic fpga-region bindings
>>> - Fixed up reg property in example
>>> - Added fallback to "xlnx,pr-decoupler" without version
>>>
>>> Changes from v1:
>>> - Added clock names & clock to example
>>> - Merged some of the description from Michal's version
>>>
>>> ---
>>> .../bindings/fpga/xilinx-pr-decoupler.txt | 36 ++++++++++++++++++++++
>>> 1 file changed, 36 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> new file mode 100644
>>> index 0000000..b2c58fb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> @@ -0,0 +1,36 @@
>>> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
>>> +
>>> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
>>> +decouplers / fpga bridges.
>>> +The controller can decouple/disable the bridges which prevents signal
>>> +changes from passing through the bridge. The controller can also
>>> +couple / enable the bridges which allows traffic to pass through the
>>> +bridge normally.
>>> +
>>> +The Driver supports only MMIO handling. A PR region can have multiple
>>> +PR Decouplers which can be handled independently or chained via decouple/
>>> +decouple_status signals.
>>> +
>>> +Required properties:
>>> +- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by
>>> + "xlnx,pr-decoupler"
>>> +- regs : base address and size for decoupler module
>>> +- clocks : input clock to IP
>>> +- clock-names : should contain "aclk"
>>> +
>>> +Optional properties:
>>> +- bridge-enable : 0 if driver should disable bridge at startup
>>> + 1 if driver should enable bridge at startup
>>> + Default is to leave bridge in current state.
>>
>> Did this get into a common location? If so, then just "see .../?.txt" is
>> enough of a description.
>
> IIRC we went with this as is, with the intent of moving it to
> a common location in a separate patch. This binding shows
> up in a a few bindings docs, so one patch could move it from all
> of them at the same time. That hasn't happened yet.
Okay, I'll trust you to do that.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] hwmon: cros-ec-hwmon: Add Chromium-EC HWMON driver
From: Guenter Roeck @ 2017-04-13 21:34 UTC (permalink / raw)
To: Moritz Fischer
Cc: linux-hwmon, linux-kernel, devicetree, lee.jones, olof, jdelvare,
robh+dt, mark.rutland, Moritz Fischer
In-Reply-To: <1491602410-31518-3-git-send-email-moritz.fischer@ettus.com>
On Fri, Apr 07, 2017 at 03:00:10PM -0700, Moritz Fischer wrote:
> From: Moritz Fischer <mdf@kernel.org>
>
> This adds a hwmon driver for the Chromium EC's fans
> and temperature sensors.
>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> ---
>
> This one still needs some work, but I figured some early feedback might not hurt.
> Specifically I was wondering if using the devm_hwmon_register_with_info() is
> preferable to the devm_hwmon_register_with_groups().
>
Please use devm_hwmon_register_with_info().
> The EC has a bunch of additional features such as setting thermal limits etc,
> which I'd still like to add but I figured I'll get some feedback on what I got so far.
>
Those would probably be more appropriate for a thermal driver.
> Thanks,
>
> Moritz
>
> ---
> drivers/hwmon/Kconfig | 8 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/cros-ec-hwmon.c | 244 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 253 insertions(+)
> create mode 100644 drivers/hwmon/cros-ec-hwmon.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0649d53f3..3b9155f 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1254,6 +1254,14 @@ config SENSORS_PCF8591
> These devices are hard to detect and rarely found on mainstream
> hardware. If unsure, say N.
>
> +config SENSORS_CROS_EC
> + tristate "ChromeOS EC hwmon"
> + depends on MFD_CROS_EC
> + help
> + If you say yes here you get hwmon support that will expose the
> + ChromeOS internal sensors for fanspeed and temperature to the
> + Linux hwmon subsystem.
> +
> source drivers/hwmon/pmbus/Kconfig
>
> config SENSORS_PWM_FAN
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 5509edf..e59b5da 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -134,6 +134,7 @@ obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> +obj-$(CONFIG_SENSORS_CROS_EC) += cros-ec-hwmon.o
> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> diff --git a/drivers/hwmon/cros-ec-hwmon.c b/drivers/hwmon/cros-ec-hwmon.c
> new file mode 100644
> index 0000000..29d8b06
> --- /dev/null
> +++ b/drivers/hwmon/cros-ec-hwmon.c
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (c) 2017, National Instruments Corp.
> + *
> + * Chromium EC Fan speed and temperature sensor driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/sysfs.h>
> +#include <linux/spi/spi.h>
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/of_platform.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/bitops.h>
> +#include <linux/mfd/cros_ec.h>
> +
> +struct cros_ec_hwmon_priv {
> + struct cros_ec_device *ec;
> + struct device *hwmon_dev;
> +
> + struct attribute **attrs;
> +
> + struct attribute_group attr_group;
> + const struct attribute_group *groups[2];
> +};
> +
> +#define KELVIN_TO_MILLICELSIUS(x) (((x) - 273) * 1000)
> +
> +static int __cros_ec_hwmon_probe_fans(struct cros_ec_hwmon_priv *priv)
> +{
> + int err, idx;
> + uint16_t data;
> +
> + for (idx = 0; idx < EC_FAN_SPEED_ENTRIES; idx++) {
> + err = cros_ec_read_mapped_mem16(priv->ec,
> + EC_MEMMAP_FAN + 2 * idx,
> + &data);
Kind of interesting. ectool and ec code all assume that there is an
endianness match. Guess we can do the same. Just add a respective comment.
> + if (err)
> + return err;
> +
> + if (data == EC_FAN_SPEED_NOT_PRESENT)
> + break;
> + }
> +
> + return idx;
> +}
> +
> +static int __cros_ec_hwmon_probe_temps(struct cros_ec_hwmon_priv *priv)
> +{
> + uint8_t data;
> + int err, idx;
> +
> + err = cros_ec_read_mapped_mem8(priv->ec, EC_MEMMAP_THERMAL_VERSION,
> + &data);
> +
> + /* if we have a read error, or EC_MEMMAP_THERMAL_VERSION is not set,
> + * most likely we don't have temperature sensors ...
> + */
> + if (err || !data)
> + return 0;
> +
> + for (idx = 0; idx < EC_TEMP_SENSOR_ENTRIES; idx++) {
This doesn't cover EC_MEMMAP_THERMAL_VERSION >= 2 which supports
an additional set of thermal sensors.
> + err = cros_ec_read_mapped_mem8(priv->ec,
> + EC_MEMMAP_TEMP_SENSOR + idx,
> + &data);
You can read all data in one go using the provided callback function.
> + if (err)
> + return idx;
> +
> + /* this assumes that they're all good up to idx */
> + switch (data) {
> + case EC_TEMP_SENSOR_NOT_PRESENT:
> + case EC_TEMP_SENSOR_ERROR:
> + case EC_TEMP_SENSOR_NOT_POWERED:
> + case EC_TEMP_SENSOR_NOT_CALIBRATED:
Not sure if we can assume sensors to be in sequential order.
ectool doesn't make that assumption (it only does it for fans).
It might be safer to generate attributes for all possible sensors
and then use the is_visible function to determine which ones are
enabled.
> + return idx;
> + default:
> + continue;
> + };
> + }
> +
> + return idx;
> +}
> +
> +static ssize_t cros_ec_hwmon_read_fan_rpm(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + uint16_t data;
> + int err;
> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> +
> + err = cros_ec_read_mapped_mem16(priv->ec,
> + EC_MEMMAP_FAN + 2 * sattr->index,
> + &data);
> + if (err)
> + return err;
> +
Watch out for EC_FAN_SPEED_STALLED.
> + return sprintf(buf, "%d\n", data);
> +}
> +
> +static ssize_t cros_ec_hwmon_read_temp(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + uint8_t data;
> + int err, tmp;
> +
> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> +
> + err = cros_ec_read_mapped_mem8(priv->ec,
> + EC_MEMMAP_TEMP_SENSOR + 1 * sattr->index,
> + &data);
> + if (err)
> + return err;
> +
> + switch (data) {
> + case EC_TEMP_SENSOR_NOT_PRESENT:
> + case EC_TEMP_SENSOR_ERROR:
> + case EC_TEMP_SENSOR_NOT_POWERED:
> + case EC_TEMP_SENSOR_NOT_CALIBRATED:
> + dev_info(priv->ec->dev, "Failure: result=%d\n", data);
Please no logging noise.
> + return -EIO;
> + }
> +
> + /* make sure we don't overflow when adding offset*/
> + tmp = data + EC_TEMP_SENSOR_OFFSET;
> +
> + return sprintf(buf, "%d\n", KELVIN_TO_MILLICELSIUS(tmp));
Overall, a REG_TO_MILLICELSIUS() macro might be easier.
> +}
> +
> +static int cros_ec_hwmon_probe(struct platform_device *pdev)
> +{
> + struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
> + struct cros_ec_hwmon_priv *ec_hwmon;
> + struct sensor_device_attribute *attr;
> + int num_fans, num_temps, i;
> +
> + ec_hwmon = devm_kzalloc(&pdev->dev, sizeof(*ec_hwmon), GFP_KERNEL);
> + if (!ec_hwmon)
> + return -ENOMEM;
> + ec_hwmon->ec = ec;
> +
> + num_fans = __cros_ec_hwmon_probe_fans(ec_hwmon);
> + if (num_fans < 0)
> + return num_fans;
> +
> + num_temps = __cros_ec_hwmon_probe_temps(ec_hwmon);
> + if (num_fans < 0)
> + return num_temps;
> +
> + ec_hwmon->attrs = devm_kzalloc(&pdev->dev,
> + sizeof(*ec_hwmon->attrs) *
> + (num_fans + num_temps + 1),
> + GFP_KERNEL);
> + if (!ec_hwmon->attrs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_fans; i++) {
> + attr = devm_kzalloc(&pdev->dev, sizeof(*attr), GFP_KERNEL);
> + if (!attr)
> + return -ENOMEM;
> + sysfs_attr_init(&attr->dev_attr.attr);
> + attr->dev_attr.attr.name = devm_kasprintf(&pdev->dev,
> + GFP_KERNEL,
> + "fan%d_input",
> + i);
> + if (!attr->dev_attr.attr.name)
> + return -ENOMEM;
> +
> + attr->dev_attr.show = cros_ec_hwmon_read_fan_rpm;
> + attr->dev_attr.attr.mode = S_IRUGO;
> + attr->index = i;
> + ec_hwmon->attrs[i] = &attr->dev_attr.attr;
> +
> + }
> +
> + for (i = 0; i < num_temps; i++) {
> + attr = devm_kzalloc(&pdev->dev, sizeof(*attr), GFP_KERNEL);
> + if (!attr)
> + return -ENOMEM;
> + sysfs_attr_init(&attr->dev_attr.attr);
> + attr->dev_attr.attr.name = devm_kasprintf(&pdev->dev,
> + GFP_KERNEL,
> + "temp%d_input",
> + i);
> + if (!attr->dev_attr.attr.name)
> + return -ENOMEM;
> +
> + attr->dev_attr.show = cros_ec_hwmon_read_temp;
> + attr->dev_attr.attr.mode = S_IRUGO;
> + attr->index = i;
> + ec_hwmon->attrs[i + num_fans] = &attr->dev_attr.attr;
> +
> + }
> +
> + ec_hwmon->attr_group.attrs = ec_hwmon->attrs;
> + ec_hwmon->groups[0] = &ec_hwmon->attr_group;
> +
> + ec_hwmon->hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev,
> + "ec_hwmon", ec_hwmon, ec_hwmon->groups);
> +
hwmon_dev is only used in this function. There is no need to store it in
ec_hwmon.
> + if (IS_ERR(ec_hwmon->hwmon_dev))
> + return PTR_ERR(ec_hwmon->hwmon_dev);
> +
return PTR_ERR_OR_ZERO(hwmon_dev);
> + platform_set_drvdata(pdev, ec_hwmon);
> +
I don't see where this is used.
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id cros_ec_hwmon_of_match[] = {
> + { .compatible = "google,cros-ec-hwmon" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, cros_ec_hwmon_of_match);
> +#endif
> +
> +static struct platform_driver cros_ec_hwmon_driver = {
> + .probe = cros_ec_hwmon_probe,
> + .driver = {
> + .name = "cros-ec-hwmon",
> + .of_match_table = of_match_ptr(cros_ec_hwmon_of_match),
> + },
> +};
> +module_platform_driver(cros_ec_hwmon_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("ChromeOS EC Hardware Monitor driver");
> +MODULE_ALIAS("platform:cros-ec-hwmon");
> +MODULE_AUTHOR("Moritz Fischer <mdf@kernel.org>");
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Tyler Baker @ 2017-04-13 21:35 UTC (permalink / raw)
To: Fabio Estevam
Cc: Andrey Smirnov, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CAOMZO5BjzSJws7zjJ5+aZkfeF+15twEu9zS3V+g6wQrtUiNyqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 13 April 2017 at 13:49, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 5:13 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> I've rebased this series on the next-20170413 for sanity sake, and
>> realized there doesn't appear to be a way to select CONFIG_IMX_GPCV2.
>> I forced it using 'default y' and configured with imx_v6_v7_defconfig.
>> Now my board is booting. Before this series is applied, it may be good
>> to have CONFIG_IMX_GPCV2 selected specifically for iMX7 platform,
>> otherwise there will be boot regressions.
>
> Something like this?
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index f03ef43..fe99a48 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -253,6 +253,7 @@ config RENESAS_H8S_INTC
>
> config IMX_GPCV2
> bool
> + def_bool y if SOC_IMX7D
> select IRQ_DOMAIN
> help
> Enables the wakeup IRQs for IMX platforms with GPCv2 block
Exactly. LGTM.
>> I'd encounter a backtrace with next-20170413 + imx_v6_v7_defconfig +
>> CONFIG_IMX_GPCV2=y
>>
>> Backtrace:
>> [<c010c364>] (dump_backtrace) from [<c010c610>] (show_stack+0x18/0x1c)
>
> but prior to fixing the Kconfig we need to fix this backtrace you reported.
I dug into this a bit, and lockdep is unhappy about spin locks not
being initialized before use.
The following patch fixes the backtrace on my board. I'll submit this
patch in a moment.
From: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 13 Apr 2017 14:29:49 -0700
Subject: [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
Call raw_spin_lock_init() before the spinlocks are used to prevent a
lockdep splat.
Signed-off-by: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/irqchip/irq-imx-gpcv2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index e13236f..9463f35 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init(struct
device_node *node,
return -ENOMEM;
}
+ raw_spin_lock_init(&cd->rlock);
+
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
pr_err("fsl-gpcv2: unable to map gpc registers\n");
--
2.9.3
Cheers,
Tyler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Andrew Lunn @ 2017-04-13 21:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <6fdcec91-829b-70c9-8780-992b67f6831a@gmail.com>
> The DT binding is in tree and provides an example of how the switch
> looks like, below is the example, but I am also adding the MDIO bus and
> the PHYs just so you can see how things wind up:
>
> switch_top@f0b00000 {
> compatible = "simple-bus";
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0 0xf0b00000 0x40804>;
>
> ethernet_switch@0 {
> compatible = "brcm,bcm7445-switch-v4.0";
> #size-cells = <0>;
> #address-cells = <1>;
> reg = <0x0 0x40000
> 0x40000 0x110
> 0x40340 0x30
> 0x40380 0x30
> 0x40400 0x34
> 0x40600 0x208>;
> reg-names = "core", "reg", intrl2_0", "intrl2_1",
> "fcb, "acb";
> interrupts = <0 0x18 0
> 0 0x19 0>;
> brcm,num-gphy = <1>;
> brcm,num-rgmii-ports = <2>;
> brcm,fcb-pause-override;
> brcm,acb-packets-inflight;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> label = "gphy";
> reg = <0>;
> phy-handle = <&phy5>;
> };
>
> sw0port1: port@1 {
> label = "rgmii_1";
> reg = <1>;
> phy-mode = "rgmii";
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> }
> };
> };
>
> mdio@403c0 {
> reg = <0x403c0 0x8 0x40300 0x18>;
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "brcm,unimac-mdio";
> reg-names = "mdio", "mdio_indir_rw";
>
> switch: switch@0 {
> broken-turn-around;
> reg = <0x0>;
> compatible = "brcm,bcm53125";
> #address-cells = <1>;
> #size-cells = <0>;
>
> ports {
> ..
> port@8 {
> ethernet = <&sw0port1>;
> };
> ...
> };
> };
>
> phy5: ethernet-phy@5 {
> reg = <0x5>;
> compatible = "ethernet-phy-ieee802.3-c22";
> };
> };
> };
So phy5 is connected to the internal switch with a phy-handle. But
because of your double usage of this node, it also can be mapped into
the external switches port 5?
Is that your problem?
It seems like you should add an mdio node inside your switch node, and
list your external switch internal/external phys there if needed.
Andrew
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Fabio Estevam @ 2017-04-13 22:00 UTC (permalink / raw)
To: Tyler Baker
Cc: Andrey Smirnov, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CANMBJr4mci5LyuBNT50dupxSVz+t-5mhWv8a7LBvY4MgupomVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 6:35 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> The following patch fixes the backtrace on my board. I'll submit this
> patch in a moment.
>
> From: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Thu, 13 Apr 2017 14:29:49 -0700
> Subject: [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
>
> Call raw_spin_lock_init() before the spinlocks are used to prevent a
> lockdep splat.
>
> Signed-off-by: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yes, it makes sense:
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node
From: Fabio Estevam @ 2017-04-13 22:20 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170413133242.5068-7-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Andrey,
On Thu, Apr 13, 2017 at 10:32 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
> reg = <0x80000000 0x80000000>;
> };
>
> + spi4 {
Here you use spi4 label...
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
and here spi1, which is a bit confusing.
> + status = "okay";
> + gpio-sck = <&gpio1 13 0>;
> + gpio-mosi = <&gpio1 9 0>;
> + cs-gpios = <&gpio1 12 0>;
You could use GPIO_ACTIVE_HIGH flag for better readability.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Fabio Estevam @ 2017-04-13 22:23 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, yurovsky-Re5JQEeQqe8AvxtiuMwx3w, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170413133242.5068-9-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Apr 13, 2017 at 10:32 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> +&pcie {
> + pinctrl-names = "default";
> + reset-gpio = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <&gpio_spi 0 GPIO_ACTIVE_LOW>;
I don't see this property in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory
From: Moritz Fischer @ 2017-04-13 22:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Moritz Fischer, linux-hwmon, Linux Kernel Mailing List,
Devicetree List, Lee Jones, olof, jdelvare, Rob Herring,
Mark Rutland
In-Reply-To: <20170413210354.GA17134@roeck-us.net>
Hi Guenter,
On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
>> From: Moritz Fischer <mdf@kernel.org>
>>
>> The ChromeOS EC has mapped memory regions where things like temperature
>> sensors and fan speed are stored. Provide access to those from the
>> cros-ec mfd device.
>>
>
> Turns out struct cros_ec_device already provides a cmd_readmem callback,
> which is widely used by other drivers. Why don't you just use it ?
This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs
emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.
Thanks for the feedback!
Moritz
^ permalink raw reply
* Re: [PATCHv4 0/2] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-13 23:19 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, Rob Herring, Pavel Machek,
Linux Bluetooth, devicetree, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3CE124E5-09B7-423D-B979-73564EB3BC6C-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi Marcel,
On Thu, Apr 13, 2017 at 10:33:58AM +0200, Marcel Holtmann wrote:
> > Here is the fourth revision of the nokia bluetooth patchset. Compared
> > to the previous one the following things have changed:
> >
> > * Drop patch 1-8 (applied by Marcel) and update Cc/To for patchset
> > * Order includes in the driver alphabetically
> > * Explicitly include <linux/of.h> in the nokia bluetooth driver
> >
> > -- Sebastian
> >
> > Sebastian Reichel (2):
> > dt-bindings: net: bluetooth: Add nokia-bluetooth
> > Bluetooth: add nokia driver
>
> both patches have been applied to bluetooth-next tree.
Thanks.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox