* [PATCHv3 0/8] Add support for STM32 RTC
From: Amelie Delaunay @ 2017-01-05 13:43 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez,
Amelie Delaunay
v3:
- rework set_alarm
- return platform_get_irq error code instead of -ENOENT
v2:
- remove clock-names and interrupt-names from bindings
- remove unuseful headers
- clean stm32_rtc structure
- replace stm32_rtc_readl/_writel by readl/writel_relaxed
- use threaded IRQ
- rework set_alarm
- add various comments
- select COMPILE_TEST and REGMAP_MMIO
This patchset adds support for the STM32 Real-Time Clock.
This RTC is an independent BCD timer/counter and provides a time-of-day
clock/calendar with programmable alarm interrupt.
RTC calendar can be driven by three clock sources LSE, LSI or HSE.
Amelie Delaunay (8):
ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
dt-bindings: document the STM32 RTC bindings
rtc: add STM32 RTC driver
ARM: dts: stm32: Add RTC support for STM32F429 MCU
ARM: dts: stm32: enable RTC on stm32f429-disco
ARM: dts: stm32: enable RTC on stm32f469-disco
ARM: dts: stm32: enable RTC on stm32429i-eval
ARM: configs: stm32: Add RTC support in STM32 defconfig
.../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 +
arch/arm/boot/dts/stm32429i-eval.dts | 4 +
arch/arm/boot/dts/stm32f429-disco.dts | 6 +
arch/arm/boot/dts/stm32f429.dtsi | 16 +
arch/arm/boot/dts/stm32f469-disco.dts | 4 +
arch/arm/configs/stm32_defconfig | 2 +
drivers/rtc/Kconfig | 11 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-stm32.c | 776 +++++++++++++++++++++
9 files changed, 847 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
create mode 100644 drivers/rtc/rtc-stm32.c
--
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: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2017-01-05 13:39 UTC (permalink / raw)
To: Boris Brezillon, Cyrille Pitchen
Cc: Mark Rutland, devicetree, Richard Weinberger, Marek Vasut,
Rob Herring, linux-mtd, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <20170104185005.7fcafd2d@bbrezillon>
Hello Cyrille, Boris
On 01/04/2017 06:50 PM, Boris Brezillon wrote:
> Cyrille, Cédric,
>
> On Wed, 4 Jan 2017 15:52:07 +0100
> Cyrille Pitchen <cyrille.pitchen@atmel.com> wrote:
>
>>>
>>>> Anyway, since the review is done now, on my side I won't ask you to remove
>>>> or split the support of the 'Command' mode in a separated patch.
>>>> I let you do as you want, if it help you to introduce some part of the
>>>> support of this 'Command' mode now even if not completed yet, no problem on
>>>> my side :)
>>>>
>>>> I was just giving you some pieces of advice for the next time if you want
>>>> to speed up the review of another patch introducing new features.
>>>>
>>>> However, I will just ask you one more version handling the dummy cycles
>>>> properly as it would help us for the global maintenance of the spi-nor
>>>> subsystem. This is the only mandatory modification I ask you, after that I
>>>> think it would be ok for me and since Marek has already reviewed your
>>>> driver, it would be ready to be merged into the spi-nor tree.
>>>
>>> Sending a v5 which should address your comments.
>>>
>>> I have removed the label property and will start a new thread in the
>>> topic. Any hints on which binding we could add this label prop ?
>>>
>>
>> Here I will provide just few thoughts about this new DT property. I don't
>> pretend this is what should be done. I still think other mtd maintainers
>> should be involved to discuss this topic.
>>
>> First the DT property name "label" sounds good to me: it is consistent with
>> "label" DT property used to name mtd partitions. However, I don't think it
>> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
>> the purpose of this new DT property seems very close to the "label"
>> property of partition nodes: let's think about some hard-disk device
>> (/dev/sda) and its partition devices (/dev/sdaX).
yes this is very similar. I first looked at introducing a name to
an overall containing partition but the partition binding is not
designed for that. There are constraints on the start address and
the size which does not fit the purpose.
> Hm, partition.txt may not be appropriate here. We're not documenting
> the MTD partition binding, but the MTD device one. Maybe we should
> create mtd.txt and put all generic MTD dev properties here.
>>
>> Besides, the concept of this memory label is not limited to SPI NOR but
>> could also apply to NAND memories or any other MTD handled memories.
>
> Definitely. Actually I think I'll need that for the Atmel NAND
> controller driver rework I'm currently working on, to keep mtdparts
> parser happy even after changing the NAND device naming scheme.
>
>> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
>> being handled by spi-nor.c or by each SPI NOR memory controller driver.
>
> Actually, that could be done at the mtdcore level in
> mtd_set_dev_defaults() [1].
that would be perfect.
>> Finally, I guess we should take time to discuss and all agree what should
>> be done precisely before introducing a new DT property because one general
>> rule with DTB files is that users should be able to update their kernel
>> image (zImage, uImage, ...) without changing their DTB: device trees should
>> be backward compatible. Hence if we make a wrong choice today, we are
>> likely to have to live with it and keep supporting that bad choice.
>
> Rob already acked the patch, so, if all MTD maintainers agree that this
> new property is acceptable, we should be fine ;-).
yes but we would need to move the binding property to another file.
What I sent applied to "jedec,spi-nor" and we want to generalize the
property to other devices.
>> Anyway, maybe you could describe a little bit your use case; what you
>> intend to do with this label from you userspace application.
>
> Here is mine: I want the mtdparts parser to work correctly with
> existing bootloaders even after changing the NAND device naming scheme
> to allow one NAND controller to expose multiple devices.
>
> Current naming scheme: NAND device name is always atmel_nand
> New naming sheme: atmel-nand.%d where %d is replaced by the CS line
> number the NAND device is connected too.
>
> Also note that it's easier to refer to a flash device by it's purpose
> (like System-firmware in Cedric's example) rather than the controller
> CS line this device is connected to.
Yes this is what we use. There are possibly other ways but adding
a label property at the flash device level is a practical solution [1]
So here's our need. Systems can have multiple chips for different
purposes :
- BMC Firmware
- BMC Firmware golden image
- Host Firmware
- Video Firmware
- etc
The goal is to simplify the identification of a specific chip for
userspace tools or daemons which need to select the appropriate
mtd device.
Thanks,
C.
[1] https://github.com/openbmc/linux/blob/dev-4.7/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts#L36
> Regards,
>
> Boris
>
> [1]http://code.bulix.org/p019ah-107877
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH] iio: accel: st_accel: handle deprecated bindings
From: Linus Walleij @ 2017-01-05 13:32 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA
The earlier deployed LIS3LV02DL driver had already defined a few
DT bindings that need to be supported by the new more generic
driver and listed as compatible but deprecated bindings in the
documentation.
After this we can start to activate the new driver with the old
systems where applicable.
As part of this enablement: make us depend on the old drivers
not being in use so we don't get a kernel with two competing
drivers.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/iio/accel/lis302.txt | 2 +-
Documentation/devicetree/bindings/iio/st-sensors.txt | 2 ++
drivers/iio/accel/Kconfig | 2 ++
drivers/iio/accel/st_accel_i2c.c | 5 +++++
drivers/iio/accel/st_accel_spi.c | 9 +++++++++
5 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
index 2a19bff9693f..dfdce67826ba 100644
--- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
+++ b/Documentation/devicetree/bindings/iio/accel/lis302.txt
@@ -5,7 +5,7 @@ that apply in on the generic device (independent from the bus).
Required properties for the SPI bindings:
- - compatible: should be set to "st,lis3lv02d_spi"
+ - compatible: should be set to "st,lis3lv02d-spi"
- reg: the chipselect index
- spi-max-frequency: maximal bus speed, should be set to 1000000 unless
constrained by external circuitry
diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt
index c040c9ad1889..eaa8fbba34e2 100644
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -27,6 +27,8 @@ standard bindings from pinctrl/pinctrl-bindings.txt.
Valid compatible strings:
Accelerometers:
+- st,lis3lv02d (deprecated, use st,lis3lv02dl-accel)
+- st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel)
- st,lis3lv02dl-accel
- st,lsm303dlh-accel
- st,lsm303dlhc-accel
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index c68bdb649005..ea295fe0f561 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -140,11 +140,13 @@ config IIO_ST_ACCEL_3AXIS
config IIO_ST_ACCEL_I2C_3AXIS
tristate
+ depends on !SENSORS_LIS3_I2C
depends on IIO_ST_ACCEL_3AXIS
depends on IIO_ST_SENSORS_I2C
config IIO_ST_ACCEL_SPI_3AXIS
tristate
+ depends on !SENSORS_LIS3_SPI
depends on IIO_ST_ACCEL_3AXIS
depends on IIO_ST_SENSORS_SPI
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index c0f8867aa1ea..99a7cdbe3d5d 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -21,6 +21,11 @@
#ifdef CONFIG_OF
static const struct of_device_id st_accel_of_match[] = {
{
+ /* An older compatible */
+ .compatible = "st,lis3lv02d",
+ .data = LIS3LV02DL_ACCEL_DEV_NAME,
+ },
+ {
.compatible = "st,lis3lv02dl-accel",
.data = LIS3LV02DL_ACCEL_DEV_NAME,
},
diff --git a/drivers/iio/accel/st_accel_spi.c b/drivers/iio/accel/st_accel_spi.c
index c25ac50d4600..29a15f27a51b 100644
--- a/drivers/iio/accel/st_accel_spi.c
+++ b/drivers/iio/accel/st_accel_spi.c
@@ -65,9 +65,18 @@ static const struct spi_device_id st_accel_id_table[] = {
};
MODULE_DEVICE_TABLE(spi, st_accel_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id lis302dl_spi_dt_ids[] = {
+ { .compatible = "st,lis302dl-spi" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, lis302dl_spi_dt_ids);
+#endif
+
static struct spi_driver st_accel_driver = {
.driver = {
.name = "st-accel-spi",
+ .of_match_table = of_match_ptr(lis302dl_spi_dt_ids),
},
.probe = st_accel_spi_probe,
.remove = st_accel_spi_remove,
--
2.9.3
--
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: [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Andrew Lunn @ 2017-01-05 13:09 UTC (permalink / raw)
To: Chris Packham
Cc: Mark Rutland, Geert Uytterhoeven, Michael Turquette,
Laxman Dewangan, linux-clk@vger.kernel.org, Florian Fainelli,
Juri Lelli, Russell King, Thierry Reding, Linus Walleij,
Sebastian Hesselbarth, devicetree@vger.kernel.org, Jason Cooper,
Arnd Bergmann, Kalyan Kinthada, Rob Herring, Gregory Clement,
linux-arm-kernel@lists.infradead.org, Thomas Petazzoni
In-Reply-To: <185147a37cab4d7eaea5f79d86cc9451@svr-chch-ex1.atlnz.lc>
> I'd love to see a switchdev driver but it's a huge task (and no I'm not
> committing to writing it). As it stands Marvell ship a switch SDK
> largely executes in userspace with a small kernel module providing some
> linkage to the underlying hardware.
Is there any similarity to the mv88e6xxx family?
If it was similar registers, just a different access mechanising, we
could probably extend the mv88e6xxx to support MMIO as well as MDIO.
Andrew
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: armada388-clearfog: add phy reset gpio-hog
From: Gregory CLEMENT @ 2017-01-05 13:04 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20170105103134.GS14217@n2100.armlinux.org.uk>
Hi Russell King,
On jeu., janv. 05 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Thu, Jan 05, 2017 at 11:29:48AM +0100, Gregory CLEMENT wrote:
>> Hi Russell King,
>>
>> On jeu., janv. 05 2017, Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
>>
>> > On Wed, Jan 04, 2017 at 05:26:08PM +0100, Gregory CLEMENT wrote:
>> >> Hi Russell,
>> >>
>> >> On lun., janv. 02 2017, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>> >>
>> >>
>> >> It would be nice to have some word here about this patch. Especially why
>> >> we need it now. I guess it is for being less dependent on the
>> >> initialization done by the bootloader but maybe you have other reasons.
>> >
>> > I'm not sure I follow. This is adding it to the new platform, not the
>> > old one. I guess I should've rolled this into the patch creating the
>> > clearfog-base dts file, and this question wouldn't have come up.
>> >
>>
>> Indeed I missed the fact that it was on the new board as all the other
>> patches were related to the common part.
>>
>> Do you agree that I squash this patch into the "ARM: dts:
>> armada388-clearfog: add base model DTS file" patch?
>
> Yep, thanks.
It's done and it is also part of mvebu/for-next now.
Gregory
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Gregory CLEMENT @ 2017-01-05 12:55 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <5a40436a-ebad-8a94-c5c5-546ba33ba545-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Florian,
On mer., janv. 04 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/04/2017 09:23 AM, Gregory CLEMENT wrote:
>> Hi Florian,
>>
>> On lun., janv. 02 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
>>> dsa: Document new binding"). The legacy binding node is kept included, but is
>>> marked disabled.
>>>
>>
>> I tested this patch on mvebu/dt (I needed to reduce the context to apply
>> the patch due to the changes made by Russell King on this file). I also
>> set the status of the old binding to "disable" (instead of "okay").
>
> Yes, that needs fixing, thanks for mentioning that.
>
>>
>> It seems to work with the limited test did:
>> ifconfig eth1 up
>> udhcpc -i lan1
>> iperf -c mylaptop
>>
>> (same for lan4)
>>
>> However is there a way to be sure that the new binding is used?
>
> The best way is probably to make sure that your switch device appears
> parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
> Alternatively, if you see a message like:
>
> DSA: switch 0 0 parsed
>
> in your dmesg, that would also be indicative of using the new binding
> and corresponding code.
So it's OK I had this message.
Gregory
>
> Thanks a lot for trying that out!
> --
> Florian
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 v5 1/4] clk: rockchip: add dt-binding header for rk3328
From: Heiko Stuebner @ 2017-01-05 12:54 UTC (permalink / raw)
To: Elaine Zhang
Cc: mark.rutland-5wv7dgnIgG8, huangtao-TNX95d0MmH7DzftRWevZcw,
xf-TNX95d0MmH7DzftRWevZcw, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, xxx-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA, cl-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <6625105.hZYF0iglUL@phil>
Am Donnerstag, 5. Januar 2017, 13:39:38 CET schrieb Heiko Stuebner:
> Am Donnerstag, 29. Dezember 2016, 10:45:08 CET schrieb Elaine Zhang:
> > Add the dt-bindings header for the rk3328, that gets shared between
> > the clock controller and the clock references in the dts.
> > Add softreset ID for rk3328.
> >
> > Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> applied, after moving the clock-ids a bit more together [0],
> as limiting the number of empty entries in the clk-id array saves us a bit
> of space. But please double check and shout if something looks wrong :-)
forgot to add, that I also moved your mac2phy clock-ids into the regular sclk-
area, as we want to add them via the muxgrf clktype.
> Thanks
> Heiko
>
> [0]
> https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commi
> t/?id=6cc1aef0ad0daea0c6ba5432a8a6fe1c30661e4c
^ permalink raw reply
* Re: [PATCH v5 4/4] clk: rockchip: add clock controller for rk3328
From: Heiko Stuebner @ 2017-01-05 12:53 UTC (permalink / raw)
To: Elaine Zhang
Cc: mturquette, sboyd, xf, robh+dt, mark.rutland, linux-clk, huangtao,
xxx, cl, linux-rockchip, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <1482979511-6847-5-git-send-email-zhangqing@rock-chips.com>
Am Donnerstag, 29. Dezember 2016, 10:45:11 CET schrieb Elaine Zhang:
> Add the clock tree definition for the new rk3328 SoC.
>
> Changes in v5:
> fix up some code style, remove grf clk init and cru dump.
> Changes in v4:
> adjust the pacth 3 and 4 order.
> Changes in v3:
> fix up the pll parent only xin24m.
> Changes in v2:
> fix up these *_sample error description.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.11.
You might also want to readd your mac2phy grf clocks via the newly
introduced muxgrf clock-type [0] in a follow-up-patch.
Heiko
[0] https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=cb1d9f6ddaa436f2dce2710740b7a3546700949c
^ permalink raw reply
* Re: [PATCH 1/1] spi: imx: support to set watermark level via DTS
From: Vladimir Zapolskiy @ 2017-01-05 12:48 UTC (permalink / raw)
To: Jiada Wang, broonie-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170105061015.7816-1-jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Jiada,
On 01/05/2017 08:10 AM, Jiada Wang wrote:
> Previously watermark level is configured to fifosize/2,
> DMA mode can be used only when transfer length can be divided
> by 'watermark level * bpw', which makes DMA mode not practical.
>
> This patch adds new DTS property 'dma-wml', user can configure
> DMA watermark level, by specify 'dma-wml' in corresponding ecspi
> node.
>
> Signed-off-by: Jiada Wang <jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 2 ++
> drivers/spi/spi-imx.c | 12 ++++++++++--
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> index 8bc95e2..1e9345f 100644
> --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> @@ -19,6 +19,7 @@ See the clock consumer binding,
> - dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
> Documentation/devicetree/bindings/dma/dma.txt
> - dma-names: DMA request names should include "tx" and "rx" if present.
> +- dma-wml: Specifies DMA watermark level
It is supposed to be an optional property, please add a new section.
I'm not sure about the property naming, the property may be considered
as a generic one and then it should not have 'fsl' prefix like yours one,
but then its description should be moved to bindings/spi/spi-bus.txt.
On the other hand for a kind of generic property it might be desirable
to have two properties, DMA RX and DMA TX watermark (threshold) levels.
And the property may be defined as a combined DMA RX / DMA TX watermark
specific to the Freescale ECSPI controller (however I would propose to
separate them, since the hardware allows to do it), but then please add
'fsl' prefix.
>
> Obsolete properties:
> - fsl,spi-num-chipselects : Contains the number of the chipselect
> @@ -35,4 +36,5 @@ ecspi@70010000 {
> <&gpio3 25 0>; /* GPIO3_25 */
> dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
> dma-names = "rx", "tx";
> + dma-wml = <16>;
Please use tab symbols for indentation.
> };
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index deb782f..5c0ce19 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -929,8 +929,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
> if (of_machine_is_compatible("fsl,imx6dl"))
> return 0;
>
> - spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
> -
> /* Prepare for TX DMA: */
> master->dma_tx = dma_request_slave_channel_reason(dev, "tx");
> if (IS_ERR(master->dma_tx)) {
> @@ -1155,6 +1153,7 @@ static int spi_imx_probe(struct platform_device *pdev)
> struct spi_imx_data *spi_imx;
> struct resource *res;
> int i, ret, irq;
> + u32 wml;
>
> if (!np && !mxc_platform_info) {
> dev_err(&pdev->dev, "can't get the platform data\n");
> @@ -1177,6 +1176,15 @@ static int spi_imx_probe(struct platform_device *pdev)
> spi_imx->devtype_data = of_id ? of_id->data :
> (struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
>
> + if (of_property_read_u32(np, "dma-wml", &wml) == 0) {
> + if (wml > spi_imx_get_fifosize(spi_imx) || wml == 0) {
> + dev_warn(&pdev->dev, "mis-configured dma-wml\n");
> + spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
> + } else
> + spi_imx->wml = wml;
checkpatch should complain regarding missing bracers on the "else" branch.
> + } else
> + spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
> +
Same is here.
Since the setting depends on the availability of DMA feature, it would be
better to read the property out from spi_imx_sdma_init():
spi_imx->wml = spi_imx_get_fifosize(spi_imx) / 2;
if (!of_property_read_u32(np, "dma-wml", &wml)) {
if (!wml || wml > spi_imx_get_fifosize(spi_imx)) /* power of 2 also? */
dev_warn(&pdev->dev, "mis-configured dma-wml\n");
else
spi_imx->wml = wml;
}
> if (mxc_platform_info) {
> master->num_chipselect = mxc_platform_info->num_chipselect;
> master->cs_gpios = devm_kzalloc(&master->dev,
>
For v2 please add to cc list:
* Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
* Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
* Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v5 6/7] i2c: designware: enable SLAVE in platform module
From: Andy Shevchenko @ 2017-01-05 12:43 UTC (permalink / raw)
To: Luis Oliveira, wsa, robh+dt, mark.rutland, jarkko.nikula,
mika.westerberg, linux-i2c, devicetree, linux-kernel
Cc: Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <9747bb4d-9a52-789d-32e9-ddbef9e129e4@synopsys.com>
On Thu, 2017-01-05 at 12:13 +0000, Luis Oliveira wrote:
> On 28-Dec-16 18:10, Luis Oliveira wrote:
> > On 28-Dec-16 17:10, Andy Shevchenko wrote:
> > > On Wed, 2016-12-28 at 16:41 +0000, Luis Oliveira wrote:
> > > > On 28-Dec-16 16:31, Andy Shevchenko wrote:
> > > So, ACPI has a property to support slave mode for I2CSerialBus()
> > > macro.
> > >
> > > I would propose to create a helper function in i2c-core.c which
> > > will be
> > > responsible for mode detection
> > >
> > > ... i2c_slave_mode_detect()
> > > {
> > > ...
> > > if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> > > ... (use of_*() here) ...
> > > } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
> > > dev_dbg(..., "ACPI slave is not supported yet\n");
> > > ... to master ...
> > > } else {
> > > ... default to master ...
> > > }
> > > }
> > > EXPORT_...();
> > >
> > > Make it as a separate patch.
> > >
> >
> > Oh I see, yes it looks good. I will check it. Thanks
> >
>
> Hi Andy,
>
> I implemented a helper function as you proposed and it looks like
> this:
>
> int i2c_slave_mode_detect(struct device *dev)
> {
> struct device_node *child;
> u32 reg;
>
> if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> for_each_child_of_node(dev->of_node, child) {
> of_property_read_u32(child, "reg", ®);
> if (reg & I2C_OWN_SLAVE_ADDRESS)
> return 1;
> }
> } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
> dev_dbg(dev, "ACPI slave is not supported yet\n");
Curly braces here as well.
> else
> return 0;
For now this is not needed
> return 0;
> }
>
> Before I submit the patch to the i2c-core.c I wonder if I could have
> some
> comment on the implementation.
Glad you did it. See above. Otherwise looks good to me.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v5 2/4] dt-bindings: add bindings for rk3328 clock controller
From: Heiko Stuebner @ 2017-01-05 12:42 UTC (permalink / raw)
To: Elaine Zhang
Cc: mturquette, sboyd, xf, robh+dt, mark.rutland, linux-clk, huangtao,
xxx, cl, linux-rockchip, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <1482979511-6847-3-git-send-email-zhangqing@rock-chips.com>
Am Donnerstag, 29. Dezember 2016, 10:45:09 CET schrieb Elaine Zhang:
> Add devicetree bindings for Rockchip cru which found on
> Rockchip SoCs.
>
> Changes in v4:
> dropping the "rockchip,cru" and "syscon" properties for bindings of rk3328
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
applied for 4.11 with Rob's Ack
^ permalink raw reply
* Re: [PATCH v5 1/4] clk: rockchip: add dt-binding header for rk3328
From: Heiko Stuebner @ 2017-01-05 12:39 UTC (permalink / raw)
To: Elaine Zhang
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
xf-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA,
huangtao-TNX95d0MmH7DzftRWevZcw, xxx-TNX95d0MmH7DzftRWevZcw,
cl-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1482979511-6847-2-git-send-email-zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 29. Dezember 2016, 10:45:08 CET schrieb Elaine Zhang:
> Add the dt-bindings header for the rk3328, that gets shared between
> the clock controller and the clock references in the dts.
> Add softreset ID for rk3328.
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
applied, after moving the clock-ids a bit more together [0],
as limiting the number of empty entries in the clk-id array saves us a bit of
space. But please double check and shout if something looks wrong :-)
Thanks
Heiko
[0] https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=6cc1aef0ad0daea0c6ba5432a8a6fe1c30661e4c
--
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] i2c: do not enable fall back to Host Notify by default
From: Pali Rohár @ 2017-01-05 12:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Wolfram Sang, Rob Herring, Benjamin Tissoires,
Michał Kępień, Jean Delvare, Takashi Iwai,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20170105045722.GA17958@dtor-ws>
On Wednesday 04 January 2017 20:57:22 Dmitry Torokhov wrote:
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
>
> For DT-based systems we introduce "host-notify" property that we convert
> to I2C_CLIENT_HOST_NOTIFY board flag.
>
> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* RE: [RFC PATCH] usb: dwc3: host: add support for OTG in DWC3 host driver
From: Manish Narani @ 2017-01-05 12:24 UTC (permalink / raw)
To: Felipe Balbi, robh+dt@kernel.org, mark.rutland@arm.com,
catalin.marinas@arm.com, will.deacon@arm.com,
michal.simek@xilinx.com, Soren Brinkmann,
gregkh@linuxfoundation.org, mathias.nyman@intel.com,
agraf@suse.de, Bharat Kumar Gogada, Punnaiah Choudary Kalluri,
dhdang@apm.com, marc.zyngier@arm.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Cc: Anurag Kumar Vulisha, Anirudha Sarangi
In-Reply-To: <87o9znvtl3.fsf@linux.intel.com>
Hi Felipe,
> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@kernel.org]
> Sent: Wednesday, January 04, 2017 7:03 PM
>
> Hi,
>
> Manish Narani <manish.narani@xilinx.com> writes:
> > This patch adds support for OTG host mode initialization in DWC3 host
> > driver. Before the host initialization sequence begins. The driver has
> > to make sure the no OTG peripheral mode is enabled.
> >
> > Signed-off-by: Manish Narani <mnarani@xilinx.com>
> > ---
> > drivers/usb/dwc3/host.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index
> > 487f0ff..4caa3fe 100644
> > --- a/drivers/usb/dwc3/host.c
> > +++ b/drivers/usb/dwc3/host.c
> > @@ -16,6 +16,8 @@
> > */
> >
> > #include <linux/platform_device.h>
> > +#include <linux/usb.h>
> > +#include <linux/usb/hcd.h>
> >
> > #include "core.h"
> >
> > @@ -111,6 +113,18 @@ int dwc3_host_init(struct dwc3 *dwc)
> > phy_create_lookup(dwc->usb3_generic_phy, "usb3-phy",
> > dev_name(dwc->dev));
> >
> > + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> > + struct usb_phy *phy;
> > + /* Switch otg to host mode */
> > + phy = usb_get_phy(USB_PHY_TYPE_USB3);
> > + if (!IS_ERR(phy)) {
> > + if (phy && phy->otg)
> > + otg_set_host(phy->otg,
> > + (struct usb_bus *)(long)1);
> > + usb_put_phy(phy);
> > + }
> > + }
>
> NAK. Don't change default mode for everybody. Default mode should actually
> be peripheral, but let's not touch whatever HW designer has set; at least for
> now.
Yes, The default mode is Peripheral. The above is to initialize the host related stuff in OTG driver before sensing the OTG ID and get to the respective mode.
- Manish
^ permalink raw reply
* Re: [PATCH v7 2/4] drm/exynos: mic: Fix parse_dt function
From: Andrzej Hajda @ 2017-01-05 12:16 UTC (permalink / raw)
To: Hoegeun Kwon, robh, thierry.reding, airlied, kgene, krzk,
inki.dae
Cc: devicetree, linux-samsung-soc, linux-kernel, dri-devel,
jh80.chung, cw00.choi
In-Reply-To: <1483611609-23522-3-git-send-email-hoegeun.kwon@samsung.com>
On 05.01.2017 11:20, Hoegeun Kwon wrote:
> The OF graph is not necessary because the panel is a child of
> dsi. therefore, the parse_dt function of dsi does not need to
> check the remote_node connected to the panel. and the whole
> parse_dt function should be refactored later.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Add NAND device tree for Arria10
From: Dinh Nguyen @ 2017-01-05 12:16 UTC (permalink / raw)
To: devicetree
Cc: Dinh Nguyen, dinguyen, s.trumtrar, linux-arm-kernel, Graham Moore
From: Graham Moore <grmoore@opensource.altera.com>
Add socfpga_arria10_socdk_nand.dts board file for supporting NAND.
Signed-off-by: Graham Moore <grmoore@opensource.altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
v2: move nand dts node to socfpga_arria10.dtsi
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga_arria10.dtsi | 13 ++++++++++
arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts | 31 ++++++++++++++++++++++++
3 files changed, 45 insertions(+)
create mode 100644 arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..380d9bb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -717,6 +717,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_arria5_socdk.dtb \
+ socfpga_arria10_socdk_nand.dtb \
socfpga_arria10_socdk_qspi.dtb \
socfpga_arria10_socdk_sdmmc.dtb \
socfpga_cyclone5_mcvevk.dtb \
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 3ceb4e4..1139d3b2 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -614,6 +614,19 @@
status = "disabled";
};
+ nand: nand@ffb90000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "denali,denali-nand-dt", "altr,socfpga-denali-nand";
+ reg = <0xffb90000 0x72000>,
+ <0xffb80000 0x10000>;
+ reg-names = "nand_data", "denali_reg";
+ interrupts = <0 99 4>;
+ dma-mask = <0xffffffff>;
+ clocks = <&nand_clk>;
+ status = "disabled";
+ };
+
ocram: sram@ffe00000 {
compatible = "mmio-sram";
reg = <0xffe00000 0x40000>;
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts b/arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts
new file mode 100644
index 0000000..d14f9cc
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk_nand.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2015 Altera Corporation. All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/dts-v1/;
+#include "socfpga_arria10_socdk.dtsi"
+
+&nand {
+ status = "okay";
+
+ partition@nand-boot {
+ label = "Boot and fpga data";
+ reg = <0x0 0x1C00000>;
+ };
+ partition@nand-rootfs {
+ label = "Root Filesystem - JFFS2";
+ reg = <0x1C00000 0x6400000>;
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 6/7] i2c: designware: enable SLAVE in platform module
From: Luis Oliveira @ 2017-01-05 12:13 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira, wsa, robh+dt, mark.rutland,
jarkko.nikula, mika.westerberg, linux-i2c, devicetree,
linux-kernel
Cc: Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
In-Reply-To: <b27405b9-b768-34e7-d61a-433100f9856d@synopsys.com>
On 28-Dec-16 18:10, Luis Oliveira wrote:
> On 28-Dec-16 17:10, Andy Shevchenko wrote:
>> On Wed, 2016-12-28 at 16:41 +0000, Luis Oliveira wrote:
>>> On 28-Dec-16 16:31, Andy Shevchenko wrote:
>>>> On Wed, 2016-12-28 at 15:53 +0000, Luis Oliveira wrote:
>>>>> On 28-Dec-16 15:44, Andy Shevchenko wrote:
>>>>>> On Wed, 2016-12-28 at 14:43 +0000, Luis Oliveira wrote:
>>>>>>> - Slave mode selected in platform module (devicetree support
>>>>>>> only)
>>>>>>> - Check for ACPI - not supported in SLAVE mode:
>>>>>>> - Changed the ifndef style to the use of ACPI_HANDLE that
>>>>>>> returns
>>>>>>> NULL
>>>>>>> if the device was not enumerated from ACPI namespace.
>>>>>>
>>>>>> I'm not sure what is wrong with ACPI?
>>>>>
>>>>> I dont have a way to test it. Just that.
>>>>
>>>> Okay, can you provide an excerpt to see how it will look like in
>>>> DTS?
>>>
>>> Yes, it looks like this now:
>>>
>>> i2c@0x2000 {
>>> compatible = "snps,designware-i2c";
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> reg = <0x2000 0x100>;
>>> clock-frequency = <400000>;
>>> clocks = <&i2cclk>;
>>> interrupts = <0>;
>>>
>>> eeprom@64 {
>>> compatible = "linux,slave-24c02";
>>> reg = <0x40000064>;
>>> };
>>> };
>>
>> +1 to Carlos' comment.
>
> Agree, I'm on it.
>
>>
>>>>
>>>>>>> - dev->functionality = I2C_FUNC_10BIT_ADDR |
>>>>>>> DW_IC_DEFAULT_FUNCTIONALITY;
>>>>>>> -
>>>>>>> - i2c_dw_configure_master(pdev);
>>>>>>> + if (ACPI_HANDLE(&pdev->dev) == NULL) {
>>>>>>
>>>>>> I don't think you need this at all.
>>>>>
>>>>> This is to avoid the use of the "ifdef" style I used before.
>>>>
>>>> My point is to drop it completely.
>>>>
>>>>>>
>>>>>>> + device_for_each_child_node(&pdev->dev, child)
>>>>>>> {
>>>>>>
>>>>>> This is resource agnostic.
>>>>>>
>>>>>>> + fwnode_property_read_u32(child,
>>>>>>> "reg",
>>>>>>> ®);
>>>>>>
>>>>>> This is as well.
>>>>>
>>>>> Are you suggesting I use of_ functions?
>>>>
>>>> Nope. See above.
>>
>> So, ACPI has a property to support slave mode for I2CSerialBus() macro.
>>
>> I would propose to create a helper function in i2c-core.c which will be
>> responsible for mode detection
>>
>> ... i2c_slave_mode_detect()
>> {
>> ...
>> if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
>> ... (use of_*() here) ...
>> } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
>> dev_dbg(..., "ACPI slave is not supported yet\n");
>> ... to master ...
>> } else {
>> ... default to master ...
>> }
>> }
>> EXPORT_...();
>>
>> Make it as a separate patch.
>>
>
> Oh I see, yes it looks good. I will check it. Thanks
>
Hi Andy,
I implemented a helper function as you proposed and it looks like this:
int i2c_slave_mode_detect(struct device *dev)
{
struct device_node *child;
u32 reg;
if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
for_each_child_of_node(dev->of_node, child) {
of_property_read_u32(child, "reg", ®);
if (reg & I2C_OWN_SLAVE_ADDRESS)
return 1;
}
} else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev))
dev_dbg(dev, "ACPI slave is not supported yet\n");
else
return 0;
return 0;
}
Before I submit the patch to the i2c-core.c I wonder if I could have some
comment on the implementation.
Thanks,
Luis
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Mark Rutland @ 2017-01-05 12:08 UTC (permalink / raw)
To: Will Deacon
Cc: Rob Clark, iommu, linux-arm-msm, Sricharan R, Jordan Crouse, robh,
devicetree
In-Reply-To: <20170105115528.GG679@arm.com>
On Thu, Jan 05, 2017 at 11:55:29AM +0000, Will Deacon wrote:
> On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> > TODO maybe we want two options, one to enable stalling, and 2nd to punt
> > handling to wq? I haven't needed to use mm APIs from fault handler yet
> > (although it is something that I think we'll want some day). Perhaps
> > stalling support is limited to just letting driver dump some extra
> > debugging information otherwise. Threaded handling probably only useful
> > with stalling, but inverse may not always be true.
>
> I'd actually like to see this stuck on a worker thread, because I think
> that's more generally useful and I don't want to have a situation where
> sometimes the IOMMU fault notifier is run in IRQ context and sometimes it's
> not.
>
> >
> > Signed-off-by: Rob Clark <robdclark@gmail.com>
> > ---
> > .../devicetree/bindings/iommu/arm,smmu.txt | 3 ++
> > drivers/iommu/arm-smmu.c | 42 ++++++++++++++++++----
> > 2 files changed, 39 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index ef465b0..5f405a6 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -68,6 +68,9 @@ conditions.
> > aliases of secure registers have to be used during
> > SMMU configuration.
> >
> > +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> > + and resume after fault is handled
The wording here seems to describe a policy rather than a property.
Can you elaborate on when/why this is required/preferred/valid?
> > static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> > @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> >
> > /* SCTLR */
> > reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> > + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> > + reg |= SCTLR_CFCFG;
>
> I wonder if this should also be predicated on the compatible string, so
> that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> the compatible string isn't specific enough to identify an implementation
> with the required SS behaviour? On the other hand, it feels pretty
> redundant and a single "stalling works" property is all we need.
Can you elaborate on what "stalling works" entails? Is that just the SS
bit behaviour? are there integration or endpoint-specific things that we
need to care about?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] iio: misc: add a generic regulator driver
From: Mark Brown @ 2017-01-05 12:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Lars-Peter Clausen, Bartosz Golaszewski, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald-Stadler, Rob Herring, Mark Rutland,
linux-iio-u79uwXL29TY76Z2rM5mHXA, linux-devicetree, LKML,
Kevin Hilman, Patrick Titiano, Neil Armstrong, Liam Girdwood
In-Reply-To: <CAMuHMdXnzDUYcr8qiUTwE2peBdjwuVWPRUkms2J8AHFaQ=SHHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
On Fri, Dec 23, 2016 at 01:56:11PM +0100, Geert Uytterhoeven wrote:
> On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> wrote:
> > cooperation between kernel- and userspace. Kernelspace offering an interface
> > to export a device for userspace access and userspace making use of that
> > interface to request access to a device. In a similar way to how vfio is
> > structured.
...
> We do not have bindings to describe GPIOs connected to e.g. relays.
Well, it depends what the relays are doing in the system of course...
> Switching external devices (the internals of those devices not described
> itself in DT, like in an industrial context), sounds more like something to
> be handled by IIO, doesn't it?
The BayLibre ACME systems have a case like this with their power
metering stuff (I've got a similar but more overenginered board I'm in
theory working on with actual relays). The system itself is controlling
a power line, it knows nothing about what's connected. It seems like
this is coming up often enough that someone should probably just write
an external system control binding, also tying in things like references
to the console and so on.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 11:55 UTC (permalink / raw)
To: Rob Clark
Cc: mark.rutland-5wv7dgnIgG8, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <1483479056-15202-2-git-send-email-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
> TODO maybe we want two options, one to enable stalling, and 2nd to punt
> handling to wq? I haven't needed to use mm APIs from fault handler yet
> (although it is something that I think we'll want some day). Perhaps
> stalling support is limited to just letting driver dump some extra
> debugging information otherwise. Threaded handling probably only useful
> with stalling, but inverse may not always be true.
I'd actually like to see this stuck on a worker thread, because I think
that's more generally useful and I don't want to have a situation where
sometimes the IOMMU fault notifier is run in IRQ context and sometimes it's
not.
>
> Signed-off-by: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/iommu/arm,smmu.txt | 3 ++
> drivers/iommu/arm-smmu.c | 42 ++++++++++++++++++----
> 2 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index ef465b0..5f405a6 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -68,6 +68,9 @@ conditions.
> aliases of secure registers have to be used during
> SMMU configuration.
>
> +- arm,smmu-enable-stall : Enable stall mode to stall memory transactions
> + and resume after fault is handled
> +
> ** Deprecated properties:
>
> - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index d505432..a71cb8f 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -350,6 +350,7 @@ struct arm_smmu_device {
> u32 features;
>
> #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> +#define ARM_SMMU_OPT_ENABLE_STALL (1 << 1)
> u32 options;
> enum arm_smmu_arch_version version;
> enum arm_smmu_implementation model;
> @@ -425,6 +426,7 @@ static bool using_legacy_binding, using_generic_binding;
>
> static struct arm_smmu_option_prop arm_smmu_options[] = {
> { ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
> + { ARM_SMMU_OPT_ENABLE_STALL, "arm,smmu-enable-stall" },
> { 0, NULL},
> };
>
> @@ -676,7 +678,8 @@ static struct iommu_gather_ops arm_smmu_gather_ops = {
>
> static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> {
> - u32 fsr, fsynr;
> + int flags, ret;
> + u32 fsr, fsynr, resume;
> unsigned long iova;
> struct iommu_domain *domain = dev;
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> @@ -690,15 +693,40 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> if (!(fsr & FSR_FAULT))
> return IRQ_NONE;
>
> + if (fsr & FSR_IGN)
> + dev_err_ratelimited(smmu->dev,
> + "Unexpected context fault (fsr 0x%x)\n",
> + fsr);
> +
> fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
> - iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
> + flags = fsynr & FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ;
>
> - dev_err_ratelimited(smmu->dev,
> - "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cb=%d\n",
> - fsr, iova, fsynr, cfg->cbndx);
> + iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
> + if (!report_iommu_fault(domain, smmu->dev, iova, flags)) {
> + ret = IRQ_HANDLED;
> + resume = RESUME_RETRY;
> + } else {
> + dev_err_ratelimited(smmu->dev,
> + "Unhandled context fault: iova=0x%08lx, fsynr=0x%x, cb=%d\n",
> + iova, fsynr, cfg->cbndx);
> + ret = IRQ_NONE;
> + resume = RESUME_TERMINATE;
> + }
>
> + /* Clear the faulting FSR */
> writel(fsr, cb_base + ARM_SMMU_CB_FSR);
> - return IRQ_HANDLED;
> +
> + /* Retry or terminate any stalled transactions */
> + if (fsr & FSR_SS) {
> + /* Should we care about ending up w/ a stalled transaction
> + * when we didn't ask for it? I guess for now best to call
> + * attention to it and resume anyways.
> + */
> + WARN_ON(!(smmu->options & ARM_SMMU_OPT_ENABLE_STALL));
I don't think we need to care about this. If we're getting stall faults
with CFCFG clear, then something has gone drastically wrong in the hardware
and we'll probably see "Unhandled context fault" anyway.
> + writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
> + }
> +
> + return ret;
> }
>
> static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
> @@ -824,6 +852,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>
> /* SCTLR */
> reg = SCTLR_CFIE | SCTLR_CFRE | SCTLR_AFE | SCTLR_TRE | SCTLR_M;
> + if (smmu->options & ARM_SMMU_OPT_ENABLE_STALL)
> + reg |= SCTLR_CFCFG;
I wonder if this should also be predicated on the compatible string, so
that the "arm,smmu-enable-stall" property is ignored (with a warning) if
the compatible string isn't specific enough to identify an implementation
with the required SS behaviour? On the other hand, it feels pretty
redundant and a single "stalling works" property is all we need.
I added the devicetree folks to CC for an opinion..
Will
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Johannes Berg @ 2017-01-05 11:51 UTC (permalink / raw)
To: Rob Herring, Rafał Miłecki
Cc: linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CAL_JsqLg5YkC-YUHg6mQ35nmGaG7SC33VJB++fgtZsu1fRV-7Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Do I take that to mean that we'll merge it through the subsystem tree,
and not go through some common DT tree?
Thanks,
johannes
--
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 V5 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Johannes Berg @ 2017-01-05 11:50 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6ryzk958T0by_4F96hJxUCR5VsKJjrsjByFO96+HcfmXqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> > But just setting orig_flags also won't work, since it'd be
> > overwritten again by wiphy_register(), no?
>
> I told you I successfully tested it, didn't I? Well, I quickly
> checked wiphy_register and couldn't understand how it was possible it
> worked for me...
I guess I didn't believe it ;-)
> OK, so after some debugging I understood why I got this working. It's
> the way brcmfmac handles channels.
>
> At the beginning all channels are disabled: see __wl_2ghz_channels &
> __wl_5ghz_channels. They have IEEE80211_CHAN_DISABLED set in "flags"
> for every channel.
>
> In early phase brcmfmac calls wiphy_read_of_freq_limits which sets
> IEEE80211_CHAN_DISABLED in "orig_flags" for unavailable channels.
>
> Then brcmf_construct_chaninfo kicks in. Normally it removes
> IEEE80211_CHAN_DISABLED from "flags" for most of channels, but it
> doesn't happen anymore due to my change:
> if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
> continue;
>
> Then brcmfmac calls wiphy_apply_custom_regulatory which sets some
> bits like IEEE80211_CHAN_NO_80MHZ and IEEE80211_CHAN_NO_160MHZ in
> "flags".
>
> Finally wiphy_register is called which copies "flags" to
> "original_flags". As brcmfmac /respected/ IEEE80211_CHAN_DISABLED set
> in orig_flags, it also left IEEE80211_CHAN_DISABLED in flags. This
> way I got IEEE80211_CHAN_DISABLED in orig_flags after overwriting
> that field inside wiphy_register.
>
> That's quite crazy, right?
Yeah, that was pretty crazy.
> I guess you're right after all, I should set IEEE80211_CHAN_DISABLED
> in "flags" field, let wiphy_register copy that to "orig_flags" and
> sanitize brcmfmac.
Makes sense to me. That would also match the way it works when no
custom regulatory notifier is used, which makes the OF function more
widely applicable.
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 08/12] ARM: dts: socfpga: Add NAND device tree for Arria10
From: Dinh Nguyen @ 2017-01-05 11:42 UTC (permalink / raw)
To: Steffen Trumtrar; +Cc: devicetree, dinguyen, linux-arm-kernel, Graham Moore
In-Reply-To: <73a8b5ga1v.fsf@pengutronix.de>
On 01/05/2017 02:55 AM, Steffen Trumtrar wrote:
>> +#include "socfpga_arria10_socdk.dtsi"
>> +
>> +/ {
>> + soc {
>> + nand: nand@ffb90000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + status = "okay";
>> +
>> + compatible = "denali,denali-nand-dt", "altr,socfpga-denali-nand";
>> + reg = <0xffb90000 0x72000>, <0xffb80000 0x10000>;
>> + reg-names = "nand_data", "denali_reg";
>> + interrupts = <0 99 4>;
>> + dma-mask = <0xffffffff>;
>> + clocks = <&nand_clk>;
>
> This belongs into the socfpga_arria10.dtsi.
>
Ah yes, you're right. Thanks for the review.
Dinh
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: phy: introduce new optional property to specify drive impedance
From: Heiko Stübner @ 2017-01-05 11:15 UTC (permalink / raw)
To: Shawn Lin
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Kishon Vijay Abraham I
In-Reply-To: <1483608682-226716-1-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi Shawn,
Am Donnerstag, 5. Januar 2017, 17:31:21 schrieb Shawn Lin:
> We need to modify the drive impedance according to the
> different hardware condition. So let's expose this to
> the DT.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt index
> e3ea557..731aeb9 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
> @@ -14,6 +14,11 @@ specified by name:
> access to it), it is strongly suggested.
> - clocks: Should have a phandle to the card clock exported by the SDHCI
> driver.
>
> +Optional Properties:
> +- drive_impedance: Must be one of 33, 40, 50, 66, 100. This property allows
> + different boards to specify their own drive impedance depending on the
> + hardware condition.
In what unit are your 33, 40 etc values?
It is recommended that properties should specify their unit, see all the
properties ending in "-ma", "-ns" and so on and also
Documentation/devicetree/bindings/property-units.txt
Also properties should use dashes ("-") not underscores.
Judging by the second patch, these are Ohm, so combining the above you
probably want
drive-impedance-ohms
as property name.
Also the patch subject is slightly misleading and should probably specify the
rockchip-emmc as well :-)
Heiko
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Anup Patel @ 2017-01-05 11:07 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: Mark Rutland, devicetree, Anup Patel, Scott Branden, Ray Jui,
linux-kernel, Pramod KUMAR, bcm-kernel-feedback-list, Rob Rice,
linux-arm-kernel
In-Reply-To: <1483614475-3442-1-git-send-email-anup.patel@broadcom.com>
This patch adds device tree bindings document for the FlexRM
ring manager found on Broadcom iProc SoCs.
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
---
.../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
new file mode 100644
index 0000000..752ae6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
@@ -0,0 +1,59 @@
+Broadcom FlexRM Ring Manager
+============================
+The Broadcom FlexRM ring manager provides a set of rings which can be
+used to submit work to offload engines. An SoC may have multiple FlexRM
+hardware blocks. There is one device tree entry per FlexRM block. The
+FlexRM driver will create a mailbox-controller instance for given FlexRM
+hardware block where each mailbox channel is a separate FlexRM ring.
+
+Required properties:
+--------------------
+- compatible: Should be "brcm,iproc-flexrm-mbox"
+- reg: Specifies base physical address and size of the FlexRM
+ ring registers
+- msi-parent: Phandles (and potential Device IDs) to MSI controllers
+ The FlexRM engine will send MSIs (instead of wired
+ interrupts) to CPU. There is one MSI for each FlexRM ring.
+ Refer devicetree/bindings/interrupt-controller/msi.txt
+- #mbox-cells: Specifies the number of cells needed to encode a mailbox
+ channel. This should be 3.
+
+ The 1st cell is the mailbox channel number.
+
+ The 2nd cell contains MSI completion threshold. This is the
+ number of completion messages for which FlexRM will inject
+ one MSI interrupt to CPU.
+
+ The 3nd cell contains MSI timer value representing time for
+ which FlexRM will wait to accumulate N completion messages
+ where N is the value specified by 2nd cell above. If FlexRM
+ does not get required number of completion messages in time
+ specified by this cell then it will inject one MSI interrupt
+ to CPU provided atleast one completion message is available.
+
+Optional properties:
+--------------------
+- dma-coherent: Present if DMA operations made by the FlexRM engine (such
+ as DMA descriptor access, access to buffers pointed by DMA
+ descriptors and read/write pointer updates to DDR) are
+ cache coherent with the CPU.
+
+Example:
+--------
+crypto_mbox: mbox@67000000 {
+ compatible = "brcm,iproc-flexrm-mbox";
+ reg = <0x67000000 0x200000>;
+ msi-parent = <&gic_its 0x7f00>;
+ #mbox-cells = <3>;
+};
+
+crypto@672c0000 {
+ compatible = "brcm,spu2-v2-crypto";
+ reg = <0x672c0000 0x1000>;
+ mboxes = <&crypto_mbox 0 0x1 0xffff>,
+ <&crypto_mbox 1 0x1 0xffff>,
+ <&crypto_mbox 16 0x1 0xffff>,
+ <&crypto_mbox 17 0x1 0xffff>,
+ <&crypto_mbox 30 0x1 0xffff>,
+ <&crypto_mbox 31 0x1 0xffff>;
+};
--
2.7.4
^ permalink raw reply related
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