* [PATCH v2 2/3] dt-bindings: mtd: add a common label property to all mtd devices
From: Cédric Le Goater @ 2017-01-16 14:56 UTC (permalink / raw)
To: linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Cédric Le Goater, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <1484573225-19095-3-git-send-email-clg@kaod.org>
This can be used to easily identify a specific chip on a system with
multiple chips.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Documentation/devicetree/bindings/mtd/common.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/common.txt
diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
new file mode 100644
index 000000000000..fc068b923d7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -0,0 +1,15 @@
+* Common properties of all MTD devices
+
+Optional properties:
+- label: user-defined MTD device name. Can be used to assign user
+ friendly names to MTD devices (instead of the flash model or flash
+ controller based name) in order to ease flash device identification
+ and/or describe what they are used for.
+
+Example:
+
+ flash@0 {
+ label = "System-firmware";
+
+ /* flash type specific properties */
+ };
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver
From: Philipp Zabel @ 2017-01-16 15:03 UTC (permalink / raw)
To: Steve Longerbeam
Cc: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, laurent.pinchart+renesas,
bparrot, geert, arnd, sudipm.mukherjee, minghsiu.tsai,
tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, devicetree, linux-kernel,
linux-arm-kernel, linux-media, devel, Steve Longerbeam
In-Reply-To: <1483755102-24785-18-git-send-email-steve_longerbeam@mentor.com>
On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
s/Serial/Sensor/
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> drivers/staging/media/imx/Kconfig | 13 +
> drivers/staging/media/imx/Makefile | 2 +
> drivers/staging/media/imx/imx-csi.c | 644 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 659 insertions(+)
> create mode 100644 drivers/staging/media/imx/imx-csi.c
>
> diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
> index bfde58d..ce2d2c8 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -6,3 +6,16 @@ config VIDEO_IMX_MEDIA
> Say yes here to enable support for video4linux media controller
> driver for the i.MX5/6 SOC.
>
> +if VIDEO_IMX_MEDIA
> +menu "i.MX5/6 Media Sub devices"
> +
> +config VIDEO_IMX_CAMERA
s/CAMERA/CSI/ ?
> + tristate "i.MX5/6 Camera driver"
i.MX5/6 Camera Sensor Interface driver
> + depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
> + select VIDEOBUF2_DMA_CONTIG
> + default y
> + ---help---
> + A video4linux camera capture driver for i.MX5/6.
> +
> +endmenu
> +endif
> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
> index ef9f11b..133672a 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -4,3 +4,5 @@ imx-media-objs := imx-media-dev.o imx-media-fim.o imx-media-internal-sd.o \
> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> +
> diff --git a/drivers/staging/media/imx/imx-csi.c b/drivers/staging/media/imx/imx-csi.c
> new file mode 100644
> index 0000000..64ef862
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-csi.c
> @@ -0,0 +1,644 @@
> +/*
> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <video/imx-ipu-v3.h>
> +#include "imx-media.h"
> +
> +#define CSI_NUM_PADS 2
> +
> +struct csi_priv {
> + struct device *dev;
> + struct ipu_soc *ipu;
> + struct imx_media_dev *md;
> + struct v4l2_subdev sd;
> + struct media_pad pad[CSI_NUM_PADS];
> + struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
> + struct v4l2_mbus_config sensor_mbus_cfg;
> + struct v4l2_rect crop;
> + struct ipu_csi *csi;
> + int csi_id;
> + int input_pad;
> + int output_pad;
> + bool power_on; /* power is on */
> + bool stream_on; /* streaming is on */
> +
> + /* the sink for the captured frames */
> + struct v4l2_subdev *sink_sd;
> + enum ipu_csi_dest dest;
> + struct v4l2_subdev *src_sd;
src_sd is not used except that its presence marks an enabled input link.
-> could be changed to bool.
> + struct v4l2_ctrl_handler ctrl_hdlr;
> + struct imx_media_fim *fim;
> +
> + /* the attached sensor at stream on */
> + struct imx_media_subdev *sensor;
> +};
> +
> +static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
> +{
> + return container_of(sdev, struct csi_priv, sd);
> +}
> +
> +/* Update the CSI whole sensor and active windows */
> +static int csi_setup(struct csi_priv *priv)
> +{
> + struct v4l2_mbus_framefmt infmt;
> +
> + ipu_csi_set_window(priv->csi, &priv->crop);
> +
> + /*
> + * the ipu-csi doesn't understand ALTERNATE, but it only
> + * needs to know whether the stream is interlaced, so set
> + * to INTERLACED if infmt field is ALTERNATE.
> + */
> + infmt = priv->format_mbus[priv->input_pad];
> + if (infmt.field == V4L2_FIELD_ALTERNATE)
> + infmt.field = V4L2_FIELD_INTERLACED;
That should be SEQ_TB/BT depending on video standard.
> + ipu_csi_init_interface(priv->csi, &priv->sensor_mbus_cfg, &infmt);
> +
> + ipu_csi_set_dest(priv->csi, priv->dest);
> +
> + ipu_csi_dump(priv->csi);
> +
> + return 0;
> +}
> +
> +static int csi_start(struct csi_priv *priv)
> +{
> + int ret;
> +
> + if (!priv->sensor) {
> + v4l2_err(&priv->sd, "no sensor attached\n");
> + return -EINVAL;
> + }
> +
> + ret = csi_setup(priv);
> + if (ret)
> + return ret;
> +
> + /* start the frame interval monitor */
> + if (priv->fim) {
> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
> + if (ret)
> + return ret;
> + }
> +
> + ret = ipu_csi_enable(priv->csi);
> + if (ret) {
> + v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
> + goto fim_off;
> + }
> +
> + return 0;
> +
> +fim_off:
> + if (priv->fim)
> + imx_media_fim_set_stream(priv->fim, priv->sensor, false);
> + return ret;
> +}
> +
> +static void csi_stop(struct csi_priv *priv)
> +{
> + /* stop the frame interval monitor */
> + if (priv->fim)
> + imx_media_fim_set_stream(priv->fim, priv->sensor, false);
> +
> + ipu_csi_disable(priv->csi);
> +}
> +
> +static int csi_s_stream(struct v4l2_subdev *sd, int enable)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + int ret = 0;
> +
> + if (!priv->src_sd || !priv->sink_sd)
> + return -EPIPE;
> +
> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
These could be silenced a bit.
[...]
> +static int csi_s_power(struct v4l2_subdev *sd, int on)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + int ret = 0;
> +
> + v4l2_info(sd, "power %s\n", on ? "ON" : "OFF");
> +
> + if (priv->fim && on != priv->power_on)
> + ret = imx_media_fim_set_power(priv->fim, on);
> +
> + if (!ret)
> + priv->power_on = on;
> + return ret;
> +}
Is this called multiple times? I'd expect a poweron during open and a
poweroff during close, so no need for priv->power_on.
> +static int csi_link_setup(struct media_entity *entity,
> + const struct media_pad *local,
> + const struct media_pad *remote, u32 flags)
> +{
> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + struct v4l2_subdev *remote_sd;
> +
> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
> + local->entity->name);
> +
> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
> +
> + if (local->flags & MEDIA_PAD_FL_SINK) {
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (priv->src_sd)
> + return -EBUSY;
> + priv->src_sd = remote_sd;
> + } else {
> + priv->src_sd = NULL;
> + }
> +
> + return 0;
> + }
> +
> + if (flags & MEDIA_LNK_FL_ENABLED) {
> + if (priv->sink_sd)
> + return -EBUSY;
> + priv->sink_sd = remote_sd;
> + } else {
> + priv->sink_sd = NULL;
> + return 0;
> + }
> +
> + /* set CSI destination */
> + switch (remote_sd->grp_id) {
> + case IMX_MEDIA_GRP_ID_SMFC0:
> + case IMX_MEDIA_GRP_ID_SMFC1:
> + case IMX_MEDIA_GRP_ID_SMFC2:
> + case IMX_MEDIA_GRP_ID_SMFC3:
With removal of the SMFC entities, CSI0 could be fixed to SMFC0 and CSI1
to the SMFC2 channel.
[...]
> +static int csi_set_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *sdformat)
> +{
> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
> + struct v4l2_mbus_framefmt *infmt, *outfmt;
> + struct v4l2_rect crop;
> + int ret;
> +
> + if (sdformat->pad >= CSI_NUM_PADS)
> + return -EINVAL;
> +
> + if (priv->stream_on)
> + return -EBUSY;
> +
> + infmt = &priv->format_mbus[priv->input_pad];
> + outfmt = &priv->format_mbus[priv->output_pad];
> +
> + if (sdformat->pad == priv->output_pad) {
> + sdformat->format.code = infmt->code;
> + sdformat->format.field = infmt->field;
> + crop.left = priv->crop.left;
> + crop.top = priv->crop.top;
> + crop.width = sdformat->format.width;
> + crop.height = sdformat->format.height;
> + ret = csi_try_crop(priv, &crop);
> + if (ret)
> + return ret;
> + sdformat->format.width = crop.width;
> + sdformat->format.height = crop.height;
> + }
> +
> + if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
Should there be some limitations on the format here?
regards
Philipp
^ permalink raw reply
* Re: [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-16 15:06 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, xypron.glpk-Mmb7MZpHnFY,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <7fcb8d94-840a-de2c-f43b-9123ccc65514-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil,
Am 16.01.2017 um 11:39 schrieb Neil Armstrong:
> On 01/15/2017 03:43 PM, Andreas Färber wrote:
>> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>>> Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
>>>
>>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>>> this patch adds this reserved zone and redefines the usable memory range.
>>>>
>>>> The memory node is also moved from the dtsi files into the proper dts files
>>>> to handle variants memory sizes.
>>>>
>>>> This patch also fixes the memory sizes for the following platforms :
>>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>
>>> Queued for v4.10-rc.
>>
>> What is the motivation for this change? I have a local U-Boot patch to
>> detect the amount of memory available as done downstream, but U-Boot
>> only updates the reg property that you seem to be abandoning here...
>>
>> So for devices that come in multiple RAM configurations - like R-Box Pro
>> - this would require separate .dts files now! This looks very wrong to
>> me, especially since I am not aware of other platforms doing the same.
>> Instead, there's memory reservations for top and bottom done in U-Boot
>> for reg, plus reserved-memory nodes for anything in the middle.
>>
>> Another thing to consider is that uEFI boot (bootefi) handles memory
>> reservation differently yet again, on the bootloader level. I have had
>> that working fine on Odroid-C2 and Vega S95.
>>
>> So if there's no bug this is fixing (none mentioned in commit message) I
>> strongly object to this patch.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
[snip]
Let's not copy&paste replies, see my response there.
> Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
> their advices.
My point is, this should be thought through _before_ merging the patch,
not after.
It is the bootloader's task to deliver the correct memory _size_, with
kernel .dts having the minimum. If there's 1G and 2G models then the
linux.git .dts will have 1G, so that it can run on both, should the
bootloader fail to update it.
The consequence of your change would be that U-Boot needs to set
different $fdtfile values based on memory size, which is a plain stupid
idea for the reasons I already gave. And it has been fought by DT
maintainers in previous cases, such as FPGA configurations or
daughter-boards. Amlogic's vendor U-Boot does have the "fdt" command
available, for any user to adequately tweak a loaded .dtb for use with
mainline Linux (e.g., add linux,usable-memory there) - it can be
automated via environment variables or for lack of "source" command
maybe via "autoscr".
The reason that there are three vega-s95 .dts files never was the
differing memory reg size (which gets overridden), but rather connector
and Wifi chipset features as well as them simply having different names
and therefore different compatible strings.
Ideally I expect to be able to use one .dts for both R-Box Pro models as
well as for both Khadas Vim models - they are not marketed with
differing names, so the differences should hopefully be minor,
especially when we're using brcm,bcm4329-fmac for any chipset anyway.
> Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
> running stock u-boot version on various shipped products and Amlogic's own development boards.
>
> The bug is easily triggered by running :
> # stress --vm 4 --vm-bytes 128M --timeout 10s &
First, that should've gone into the commit message please.
But this is what I get for that command line:
flag provided but not defined: -vm
Usage of stress:
-failure regexp
fail only if output matches regexp
-ignore regexp
ignore failure if output matches regexp
-kill
kill timed out processes if true, otherwise just print pid (to
attach with gdb) (default true)
-p N
run N processes in parallel (default 8)
-timeout duration
timeout each process after duration (default 10m0s)
The only "stress" I found is in golang-org-x-tools package.
> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
>
> Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
> crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
I have been running "large" KVM guests on a Vega S95 Telos, with vendor
U-Boot as well as mainline U-Boot, and did not run into such a problem.
What I did run into yesterday during a large system update was multiple:
INFO: task grub2-probe:22018 blocked for more than 120 seconds.
Not tainted 4.10.0-rc3-next-20170113+ #58
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
grub2-probe D 0 22018 22017 0x00000000
Call trace:
[<ffffff8008085628>] __switch_to+0x90/0xa8
[<ffffff8008746238>] __schedule+0x188/0x570
[<ffffff8008746658>] schedule+0x38/0xa0
[<ffffff80081fb234>] wb_wait_for_completion+0x4c/0x80
[<ffffff80081fb2f0>] __writeback_inodes_sb_nr+0x88/0xa0
[<ffffff80081fb34c>] writeback_inodes_sb+0x2c/0x38
[<ffffff80081ff494>] sync_filesystem+0x3c/0xa8
[<ffffff8008208688>] fsync_bdev+0x20/0x70
[<ffffff80083508e8>] blkdev_ioctl+0x8b0/0x9d8
[<ffffff800820801c>] block_ioctl+0x34/0x40
[<ffffff80081e2d04>] do_vfs_ioctl+0xa4/0x748
[<ffffff80081e3434>] SyS_ioctl+0x8c/0xa0
[<ffffff8008082f30>] el0_svc_naked+0x24/0x28
I'm assuming that's an unrelated linux-next regression.
I have also been running vendor U-Boot on the R-Box Pro, without problems.
On the Odroid-C2 however the bootloader is provided on SD by the user,
so there is no excuse really for the user to use a broken bootloader.
Even if not using the mainline version for lack of MMC drivers, the
Hardkernel branch can easily be patched if necessary.
> Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
> and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
Whatever the issue is, this patch is clearly wrong by design. Please
revert it ASAP!
For starters, have you tried simply adding a reserved-memory node for
0..0x01000000? v1 did not have that and instead messed with reg.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
From: Tero Kristo @ 2017-01-16 15:19 UTC (permalink / raw)
To: Tony Lindgren, Michael Turquette, Stephen Boyd
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Rob Herring
In-Reply-To: <20170109234226.9449-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 10/01/17 01:42, Tony Lindgren wrote:
> Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> clock controller instance for each interconnect target module. The clkctrl
> controls functional and interface clocks for the module.
>
> The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> With this binding and a related clock device driver we can start moving the
> clkctrl clock handling to live in drivers/clk/ti.
>
> For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> Mapping Summary" for example. It show one instance of a clkctrl clock
> controller with multiple clkctrl registers.
>
> Note that this binding allows keeping the clockdomain related parts out of
> drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> driver needs to know it's clocks, we can just set the the clkctrl device
> instances to be children of the related clockdomain device.
>
> On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> So we need to shift the clock index to avoid index conflict for the clock
> consumer binding with the next clkctrl offset on omap4.
>
> Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>
> So here's what I was able to come up for the clkctr binding based on
> all we've discussed so far. Can you guys please take a look and see
> if it looks OK to you before we do the device driver?
>
> Also, does anybody have better suggestions for addressing the optional
> clocks in each clkctrl register?
>
> ---
> .../devicetree/bindings/clock/ti-clkctrl.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ti-clkctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt
> @@ -0,0 +1,56 @@
> +Texas Instruments clkctrl clock binding
> +
> +Texas Instruments SoCs can have a clkctrl clock controller for each
> +interconnect target module. The clkctrl clock controller manages functional
> +and interface clocks for each module. Each clkctrl controller can also
> +gate one or more optional functional clocks for a module. The clkctrl
> +clock controller is typical for omap3 and later variants.
> +
> +The clock consumers can specify the index of the clkctrl clock using
> +the hardware offset from the clkctrl instance register space. The optional
> +functional clocks can be specified by clkctrl hardware offset plus the
> +index of the optional clock. Please see the Linux clock framework binding
> +at Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> +Required properties :
> +- compatible : shall be "ti,clkctrl"
> +- #clock-cells : shall contain 1
> +
> +Optional properties :
> +- "ti,modulemode-auto" : list of clkctrl offsets using automatic gating
> +
> +Example: Clock controller node:
> +
> +&cm_l4per {
> + cm_l4per_clkctrl: clk@20 {
> + compatible = "ti,clkctrl";
> + reg = <0x20 0x1b0>;
> + #clock-cells = 1;
> + ti,modulemode-auto = <OMAP4_GPIO2_CLKCTRL>;
> + };
> +};
So, in this example, what would cm_l4per be? Is it a clockdomain? Or is
it just an arbitrary interconnect instance, and the clockdomain would
also be a separate node under cm_l4per?
Shall we add power-domains = <&cm_l4per_clkdm>; entry under the
cm_l4per_clkctrl in this example? (My thinking is that we will represent
both OMAP clock and power domains as generic power domains within kernel
/ DT.)
-Tero
> +
> +Example: Preprocessor helper macros in dt-bindings/ti-clkctrl.h
> +
> +#define OMAP4_CLKCTRL_OFFSET 0x20
> +
> +#define OMAP_CLKCTRL_INDEX(offset) \
> + (((offset) - OMAP4_CLKCTRL_OFFSET) << 8)
> +
> +#define OMAP_CLKCTRL_OPT_INDEX(offset, optclk) \
> + (OMAP_CLKCTRL_INDEX(offset) + (optclk))
> +
> +#define OMAP4_GPTIMER10_CLKTRL OMAP_CLKCTRL_INDEX(0x28)
> +#define OMAP4_GPTIMER11_CLKTRL OMAP_CLKCTRL_INDEX(0x30)
> +#define OMAP4_GPTIMER2_CLKTRL OMAP_CLKCTRL_INDEX(0x38)
> +...
> +#define OMAP4_GPIO2_CLKCTRL OMAP_CLKCTRL_INDEX(0x60)
> +#define OMAP4_GPIO2_CLKCTRL_DBCLK OMAP_CLKCTRL_OPT_INDEX(0x60, 1)
> +...
> +
> +Example: Clock consumer node for GPIO2:
> +
> +&gpio2 {
> + clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL
> + &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK>;
> +};
>
--
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 v1 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
From: Jun Nie @ 2017-01-16 15:25 UTC (permalink / raw)
To: Baoyou Xie, wim-IQzOog9fTRqzQB+pC5nmwQ,
linux-0h96xk9xTtrk1uMJSBkQmQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1484540395-3335-3-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 2017年01月16日 12:19, Baoyou Xie wrote:
> This patch adds watchdog controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/watchdog/Kconfig | 10 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/zx2967_wdt.c | 405 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 416 insertions(+)
> create mode 100644 drivers/watchdog/zx2967_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 3eb58cb..79027da 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called aspeed_wdt.
>
> +config ZX2967_WATCHDOG
> + tristate "ZTE zx2967 SoCs watchdog support"
> + depends on ARCH_ZX
> + select WATCHDOG_CORE
> + help
> + Say Y here to include support for the watchdog timer
> + in ZTE zx2967 SoCs.
> + To compile this driver as a module, choose M here: the
> + module will be called zx2967_wdt.
> +
> # AVR32 Architecture
>
> config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index caa9f4a..ea08925 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
> obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
> obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
> obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> +obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
>
> # AVR32 Architecture
> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
> new file mode 100644
> index 0000000..8791dd2
> --- /dev/null
> +++ b/drivers/watchdog/zx2967_wdt.c
> @@ -0,0 +1,405 @@
> +/*
> + * watchdog driver for ZTE's zx2967 family
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/reboot.h>
> +#include <linux/reset.h>
> +#include <linux/watchdog.h>
> +
> +#define ZX2967_WDT_CFG_REG 0x4
> +#define ZX2967_WDT_LOAD_REG 0x8
> +#define ZX2967_WDT_REFRESH_REG 0x18
> +#define ZX2967_WDT_START_REG 0x1c
> +
> +#define ZX2967_WDT_REFRESH_MASK 0x3f
> +
> +#define ZX2967_WDT_CFG_DIV(n) ((((n)&0xff) - 1) << 8)
> +#define ZX2967_WDT_START_EN 0x1
> +
> +#define ZX2967_WDT_WRITEKEY 0x12340000
> +
> +#define ZX2967_WDT_DIV_DEFAULT 16
> +#define ZX2967_WDT_DEFAULT_TIMEOUT 32
> +#define ZX2967_WDT_MIN_TIMEOUT 1
> +#define ZX2967_WDT_MAX_TIMEOUT 500
> +#define ZX2967_WDT_MAX_COUNT 0xffff
> +
> +#define ZX2967_WDT_FLAG_REBOOT_MON (1 << 0)
> +
> +#define ZX2967_RESET_MASK_REG 0xb0
> +
> +#define zx2967_wdt_write_reg(v, r) \
> + writel((v) | ZX2967_WDT_WRITEKEY, r)
> +#define zx2967_wdt_read_reg(r) readl(r)
For writel and readl, *_relaxed is recommended.
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +static unsigned int timeout = ZX2967_WDT_DEFAULT_TIMEOUT;
> +
> +struct zx2967_wdt {
> + struct device *dev;
> + struct clk *clock;
> + void __iomem *reg_base;
> + unsigned int conf;
> + unsigned int load;
> + unsigned int flags;
> + spinlock_t lock;
> + struct watchdog_device wdt_device;
> + struct notifier_block restart_handler;
> + struct notifier_block reboot_handler;
> +};
> +
> +static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
> +{
> + unsigned int val;
> +
> + spin_lock(&wdt->lock);
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> + val ^= ZX2967_WDT_REFRESH_MASK;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> +
> + spin_unlock(&wdt->lock);
> +}
> +
> +static void __zx2967_wdt_stop(struct zx2967_wdt *wdt)
> +{
> + unsigned int val;
> +
> + spin_lock(&wdt->lock);
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
> + val &= ~(ZX2967_WDT_START_EN);
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
> +
> + spin_unlock(&wdt->lock);
> +}
> +
> +static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
> +{
> + unsigned int val;
> +
> + spin_lock(&wdt->lock);
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
> + val |= ZX2967_WDT_START_EN;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
> +
> + spin_unlock(&wdt->lock);
> +}
> +
> +static unsigned int
> +__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
> +{
> + unsigned int freq = clk_get_rate(wdt->clock);
> + unsigned int divisor = ZX2967_WDT_DIV_DEFAULT, count;
> +
> + count = timeout * freq;
> + if (count > divisor * ZX2967_WDT_MAX_COUNT)
> + divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
> + count = DIV_ROUND_UP(count, divisor);
> + zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
> + wdt->reg_base + ZX2967_WDT_CFG_REG);
> + zx2967_wdt_write_reg(count, wdt->reg_base + ZX2967_WDT_LOAD_REG);
No spin lock here. Do we really need the spin lock?
> + zx2967_wdt_refresh(wdt);
> +
> + wdt->load = count;
> + dev_info(wdt->dev, "count=%d, timeout=%d, divisor=%d\n",
> + count, timeout, divisor);
> +
> + return (count * divisor) / freq;
> +}
> +
> +static int zx2967_wdt_set_timeout(struct watchdog_device *wdd,
> + unsigned int timeout)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + if (watchdog_timeout_invalid(&wdt->wdt_device, timeout)) {
> + dev_err(wdt->dev, "timeout %d is invalid\n", timeout);
> +
> + return -EINVAL;
> + }
> +
> + wdd->timeout = __zx2967_wdt_set_timeout(wdt, timeout);
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_start(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + __zx2967_wdt_stop(wdt);
> + zx2967_wdt_set_timeout(wdd, wdd->timeout);
> + __zx2967_wdt_start(wdt);
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + __zx2967_wdt_stop(wdt);
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_keepalive(struct watchdog_device *wdd)
> +{
> + struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> + zx2967_wdt_refresh(wdt);
> +
> + return 0;
> +}
> +
> +#define ZX2967_WDT_OPTIONS \
> + (WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE)
> +static const struct watchdog_info zx2967_wdt_ident = {
> + .options = ZX2967_WDT_OPTIONS,
> + .firmware_version = 0,
> + .identity = "zx2967 watchdog",
> +};
> +
> +static struct watchdog_ops zx2967_wdt_ops = {
> + .owner = THIS_MODULE,
> + .start = zx2967_wdt_start,
> + .stop = zx2967_wdt_stop,
> + .ping = zx2967_wdt_keepalive,
> + .set_timeout = zx2967_wdt_set_timeout,
> +};
> +
> +static void zx2967_wdt_fix_sysdown(struct zx2967_wdt *wdt)
> +{
> + __zx2967_wdt_stop(wdt);
> + __zx2967_wdt_set_timeout(wdt, 15);
> + __zx2967_wdt_start(wdt);
> +}
> +
> +static int zx2967_wdt_notify_sys(struct notifier_block *this,
> + unsigned long code, void *unused)
> +{
> + struct zx2967_wdt *wdt = container_of(this, struct zx2967_wdt,
> + reboot_handler);
> +
> + wdt->flags |= ZX2967_WDT_FLAG_REBOOT_MON;
> + switch (code) {
> + case SYS_HALT:
> + case SYS_POWER_OFF:
> + case SYS_RESTART:
> + zx2967_wdt_fix_sysdown(wdt);
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int zx2967_wdt_restart(struct notifier_block *this,
> + unsigned long mode, void *cmd)
> +{
> + struct zx2967_wdt *wdt;
> +
> + wdt = container_of(this, struct zx2967_wdt, restart_handler);
> +
> + zx2967_wdt_stop(&wdt->wdt_device);
> +
> + zx2967_wdt_write_reg(0x80, wdt->reg_base + ZX2967_WDT_LOAD_REG);
> + zx2967_wdt_refresh(wdt);
> + zx2967_wdt_write_reg(ZX2967_WDT_START_EN,
> + wdt->reg_base + ZX2967_WDT_START_REG);
> +
> + zx2967_wdt_start(&wdt->wdt_device);
> + /* wait for reset*/
> + mdelay(500);
> +
> + return NOTIFY_DONE;
> +}
> +
> +static void zx2967_reset_mask_config(struct device *dev)
> +{
> + struct device_node *np = NULL;
> + void __iomem *reg;
> + unsigned int val, mask, config, size;
> + const unsigned int *prop;
> +
> + prop = of_get_property(dev->of_node, "reset-mask-config", &size);
> + if (size < (sizeof(*prop) * 2)) {
> + dev_err(dev, "bad data for reset-mask-config");
> + return;
> + }
> + config = be32_to_cpup(prop++);
> + mask = be32_to_cpup(prop);
> + np = of_find_compatible_node(NULL, NULL, "zte,aon-sysctrl");
> + if (!np) {
> + dev_err(dev, "Cannot found pcu device node\n");
> + return;
> + }
> + reg = of_iomap(np, 0) + ZX2967_RESET_MASK_REG;
> + of_node_put(np);
> +
> + val = readl(reg);
> + val &= ~mask;
> + val |= config;
> + writel(val, reg);
> +}
> +
> +static int zx2967_wdt_probe(struct platform_device *pdev)
> +{
> + struct device *dev;
> + struct zx2967_wdt *wdt;
> + struct resource *base;
> + int err, ret = 0;
> + unsigned int rate, val;
> +
> + struct reset_control *rstc;
> +
> + dev = &pdev->dev;
> +
> + wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
> + if (!wdt) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + platform_set_drvdata(pdev, wdt);
> +
> + wdt->dev = dev;
> + spin_lock_init(&wdt->lock);
> +
> + wdt->wdt_device.info = &zx2967_wdt_ident;
> + wdt->wdt_device.ops = &zx2967_wdt_ops;
> + wdt->wdt_device.timeout = ZX2967_WDT_DEFAULT_TIMEOUT;
> + wdt->wdt_device.max_timeout = ZX2967_WDT_MAX_TIMEOUT;
> + wdt->wdt_device.min_timeout = ZX2967_WDT_MIN_TIMEOUT;
> + wdt->wdt_device.parent = &pdev->dev;
> +
> + base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + wdt->reg_base = devm_ioremap_resource(dev, base);
> +
> + if (of_find_property(dev->of_node, "reset-mask-config", NULL))
> + zx2967_reset_mask_config(dev);
> +
> + wdt->reboot_handler.notifier_call = zx2967_wdt_notify_sys;
> + ret = register_reboot_notifier(&wdt->reboot_handler);
> + wdt->clock = devm_clk_get(dev, "wdtclk");
> + if (IS_ERR(wdt->clock)) {
> + dev_err(dev, "failed to find watchdog clock source\n");
> + ret = PTR_ERR(wdt->clock);
> + goto out;
> + }
> + ret = clk_prepare_enable(wdt->clock);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable clock\n");
> + goto out;
> + }
> +
> + rate = clk_get_rate(wdt->clock);
> + if (rate == 24000000)
> + ret = clk_set_rate(wdt->clock, 32768);
> + rate = clk_get_rate(wdt->clock);
Do you want to check rate again? Or you want to just check set_rate
return value?
> +
> + rstc = devm_reset_control_get(dev, "wdtrst");
> + if (!rstc) {
> + dev_info(dev, "rstc get failed");
dev_err() may be more feasible.
> + } else {
> + reset_control_assert(rstc);
> + mdelay(10);
> + reset_control_deassert(rstc);
> + }
> +
> + watchdog_set_drvdata(&wdt->wdt_device, wdt);
> +
> + watchdog_init_timeout(&wdt->wdt_device, timeout, &pdev->dev);
> + watchdog_set_nowayout(&wdt->wdt_device, nowayout);
> +
> + zx2967_wdt_stop(&wdt->wdt_device);
> +
> + err = watchdog_register_device(&wdt->wdt_device);
> + if (unlikely(err)) {
> + ret = err;
> + goto fail_register;
> + }
> +
> + wdt->restart_handler.notifier_call = zx2967_wdt_restart;
> + wdt->restart_handler.priority = 128;
> + ret = register_restart_handler(&wdt->restart_handler);
> + if (ret) {
> + pr_err("cannot register restart handler, %d\n", ret);
> + goto fail_restart;
> + }
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
> + dev_info(&pdev->dev, "watchdog enabled (timeout=%d sec, nowayout=%d)",
> + wdt->wdt_device.timeout, nowayout);
> +
> + return 0;
> +
> +fail_restart:
> + watchdog_unregister_device(&wdt->wdt_device);
> +fail_register:
> + clk_disable_unprepare(wdt->clock);
> +out:
> + return ret;
> +}
> +
> +static int zx2967_wdt_remove(struct platform_device *pdev)
> +{
> + struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
> +
> + unregister_restart_handler(&wdt->restart_handler);
> + watchdog_unregister_device(&wdt->wdt_device);
> + clk_disable_unprepare(wdt->clock);
> +
> + return 0;
> +}
> +
> +static void zx2967_wdt_shutdown(struct platform_device *pdev)
> +{
> + struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
> +
> + if (!(wdt->flags & ZX2967_WDT_FLAG_REBOOT_MON))
> + zx2967_wdt_stop(&wdt->wdt_device);
> +}
> +
> +static const struct of_device_id zx2967_wdt_match[] = {
> + { .compatible = "zte,zx296718-wdt", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, zx2967_wdt_match);
> +
> +static const struct platform_device_id zx2967_wdt_ids[] = {
> + { .name = "zx2967-wdt", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(platform, zx2967_wdt_ids);
> +
> +static struct platform_driver zx2967_wdt_driver = {
> + .probe = zx2967_wdt_probe,
> + .remove = zx2967_wdt_remove,
> + .shutdown = zx2967_wdt_shutdown,
> + .id_table = zx2967_wdt_ids,
> + .driver = {
> + .name = "zx2967-wdt",
> + .of_match_table = of_match_ptr(zx2967_wdt_match),
> + },
> +};
> +module_platform_driver(zx2967_wdt_driver);
> +
> +MODULE_AUTHOR("Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>");
> +MODULE_DESCRIPTION("ZTE zx2967 Watchdog Device Driver");
> +MODULE_LICENSE("GPL");
>
--
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] of: Add EXPORT_SYMBOL for of_device_compatible_match
From: Rob Herring @ 2017-01-16 15:37 UTC (permalink / raw)
To: Neil Armstrong
Cc: Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1484572311-6005-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Mon, Jan 16, 2017 at 7:11 AM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Add missing EXPORT_SYMBOL for of_device_compatible_match function.
It's not missing because no modules use it. It's generally preferred
to use a match table and of_match_node.
Rob
>
> Fixes: b9c13fe32faa ("dt: Add of_device_compatible_match()")
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/of/base.c | 1 +
> 1 file changed, 1 insertion(+)
--
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: [v2 2/3] ARM: dts: STM32 Add USB FS host mode support
From: Bruno Herrera @ 2017-01-16 15:41 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Rob Herring, Mark Rutland, Maxime Coquelin, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <21fbf365-7d15-04be-f6a5-451aedac05b5-qxv4g6HH51o@public.gmane.org>
On Mon, Jan 16, 2017 at 9:47 AM, Alexandre Torgue
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
>
>
> On 01/16/2017 11:26 AM, Bruno Herrera wrote:
>>
>> Hi Alex,
>>
>> On Mon, Jan 16, 2017 at 6:57 AM, Alexandre Torgue
>> <alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
>>>
>>> Hi Bruno,
>>>
>>> On 01/16/2017 03:09 AM, Bruno Herrera wrote:
>>>>
>>>>
>>>> This patch adds the USB pins and nodes for USB HS/FS cores working at FS
>>>> speed,
>>>> using embedded PHY.
>>>>
>>>> Signed-off-by: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>
>>>
>>>
>>> Sorry, but what is patch 1 & pacth 3 status ?
>>
>>
>> My bad, I'll add the status of the patch series version 3.
>>>
>>>
>>> For this one, can split it in 3 patches (one patch for SOC and one for
>>> each
>>> board) please.
>>>
>>
>> No problem.
>>>
>>>
>>>
>>>> ---
>>>> arch/arm/boot/dts/stm32f429-disco.dts | 30
>>>> ++++++++++++++++++++++++++++++
>>>> arch/arm/boot/dts/stm32f429.dtsi | 35
>>>> ++++++++++++++++++++++++++++++++++-
>>>> arch/arm/boot/dts/stm32f469-disco.dts | 30
>>>> ++++++++++++++++++++++++++++++
>>>> 3 files changed, 94 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
>>>> b/arch/arm/boot/dts/stm32f429-disco.dts
>>>> index 7d0415e..374c5ed 100644
>>>> --- a/arch/arm/boot/dts/stm32f429-disco.dts
>>>> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
>>>> @@ -88,6 +88,16 @@
>>>> gpios = <&gpioa 0 0>;
>>>> };
>>>> };
>>>> +
>>>> + /* This turns on vbus for otg for host mode (dwc2) */
>>>> + vcc5v_otg: vcc5v-otg-regulator {
>>>> + compatible = "regulator-fixed";
>>>> + gpio = <&gpioc 4 0>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&usbotg_pwren_h>;
>>>> + regulator-name = "vcc5_host1";
>>>> + regulator-always-on;
>>>> + };
>>>> };
>>>>
>>>> &clk_hse {
>>>> @@ -99,3 +109,23 @@
>>>> pinctrl-names = "default";
>>>> status = "okay";
>>>> };
>>>> +
>>>> +&usbotg_hs {
>>>> + compatible = "st,stm32-fsotg", "snps,dwc2";
>>>> + dr_mode = "host";
>>>> + pinctrl-0 = <&usbotg_fs_pins_b>;
>>>> + pinctrl-names = "default";
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&pinctrl {
>>>> + usb-host {
>>>> + usbotg_pwren_h: usbotg-pwren-h {
>>>> + pins {
>>>> + pinmux = <STM32F429_PC4_FUNC_GPIO>;
>>>> + bias-disable;
>>>> + drive-push-pull;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>
>>>
>>>
>>> Pinctrl muxing has to be defined/declared in stm32f429.dtsi
>>>
>> This is board specific logic and it vary from board to board, should
>> it be defined here?
>
>
> Pinmuxing definition is a SOC part (as it is a possibility offered by SOC).
> Pinmuxing choice is board specific.
>
> Regarding your code, it should not boot. Ex for disco:
>
> + gpio = <&gpiob 2 0>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&usbotg_pwren_h>;
>
> +
>
> usb-host {
>>>> + usbotg_pwren_h: usbotg-pwren-h {
>>>> + pins {
>>>> + pinmux = <STM32F429_PB2_FUNC_GPIO>;
>
> Indeed, you are declaring two time the pin PB2 (one time through pinctrl and
> one other time through gpiolib). in strict mode you can't request 2 times
> the same Pin.
> I assume that your driver want controls this GPIO (request/set direction /
> set, get value ...). in this case you only need to declare this part:
>
> gpio = <&gpiob 2 0>;
>
> The GPIO lib will deal with pinctrl framework for you.
> And in this case, yes gpio declaration is board specific so this part will
> be in board file.
>
> Let me know, if I'm not enough clear.
Thats very clear! Thanks for bringing.
I'll retest without the pinctrl.
br,
Bruno
>
> Regards
> Alex
>
>
>
>
>
>>>
>>>
>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>>> index e4dae0e..bc07aa8 100644
>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>>> @@ -206,7 +206,7 @@
>>>> reg = <0x40007000 0x400>;
>>>> };
>>>>
>>>> - pin-controller {
>>>> + pinctrl: pin-controller {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "st,stm32f429-pinctrl";
>>>> @@ -316,6 +316,30 @@
>>>> };
>>>> };
>>>>
>>>> + usbotg_fs_pins_a: usbotg_fs@0 {
>>>> + pins {
>>>> + pinmux =
>>>> <STM32F429_PA10_FUNC_OTG_FS_ID>,
>>>> +
>>>> <STM32F429_PA11_FUNC_OTG_FS_DM>,
>>>> +
>>>> <STM32F429_PA12_FUNC_OTG_FS_DP>;
>>>> + bias-disable;
>>>> + drive-push-pull;
>>>> + slew-rate = <2>;
>>>> + };
>>>> + };
>>>> +
>>>> + usbotg_fs_pins_b: usbotg_fs@1 {
>>>> + pins {
>>>> + pinmux =
>>>> <STM32F429_PB12_FUNC_OTG_HS_ID>,
>>>> +
>>>> <STM32F429_PB14_FUNC_OTG_HS_DM>,
>>>> +
>>>> <STM32F429_PB15_FUNC_OTG_HS_DP>;
>>>> + bias-disable;
>>>> + drive-push-pull;
>>>> + slew-rate = <2>;
>>>> + };
>>>> + };
>>>> +
>>>> +
>>>> +
>>>> usbotg_hs_pins_a: usbotg_hs@0 {
>>>> pins {
>>>> pinmux =
>>>> <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
>>>> @@ -420,6 +444,15 @@
>>>> status = "disabled";
>>>> };
>>>>
>>>> + usbotg_fs: usb@50000000 {
>>>> + compatible = "st,stm32f4xx-fsotg", "snps,dwc2";
>>>> + reg = <0x50000000 0x40000>;
>>>> + interrupts = <67>;
>>>> + clocks = <&rcc 0 39>;
>>>> + clock-names = "otg";
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> rng: rng@50060800 {
>>>> compatible = "st,stm32-rng";
>>>> reg = <0x50060800 0x400>;
>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> index 8877c00..8ae6763 100644
>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>>> @@ -68,6 +68,17 @@
>>>> soc {
>>>> dma-ranges = <0xc0000000 0x0 0x10000000>;
>>>> };
>>>> +
>>>> + /* This turns on vbus for otg for host mode (dwc2) */
>>>> + vcc5v_otg: vcc5v-otg-regulator {
>>>> + compatible = "regulator-fixed";
>>>> + enable-active-high;
>>>> + gpio = <&gpiob 2 0>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&usbotg_pwren_h>;
>>>> + regulator-name = "vcc5_host1";
>>>> + regulator-always-on;
>>>> + };
>>>> };
>>>>
>>>> &rcc {
>>>> @@ -81,3 +92,22 @@
>>>> &usart3 {
>>>> status = "okay";
>>>> };
>>>> +
>>>> +&usbotg_fs {
>>>> + dr_mode = "host";
>>>> + pinctrl-0 = <&usbotg_fs_pins_a>;
>>>> + pinctrl-names = "default";
>>>> + status = "okay";
>>>> +};
>>>> +
>>>> +&pinctrl {
>>>> + usb-host {
>>>> + usbotg_pwren_h: usbotg-pwren-h {
>>>> + pins {
>>>> + pinmux = <STM32F429_PB2_FUNC_GPIO>;
>>>> + bias-disable;
>>>> + drive-push-pull;
>>>> + };
>>>> + };
>>>> + };
>>>> +};
>>>
>>>
>>> Same. Note that if you have 2 configuration for one feature (like it is
>>> here
>>> for "usbotg_pwren_h"), you could index it. Not that I'm adding a
>>> dedidacted
>>> pinctroller for stm32f469.
>>>
>> Sorry, but I dont know what you mean by index here.
>> The usbotg_pwren_h (VBUS ENABLE) is attached in different port/pins
>> for each board.
>>
>> Br.,
>>
>>
>>> Br
>>> Alex
>>>>
>>>>
>>>>
>>>
>>>
>
--
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 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions
From: Christoph Hellwig @ 2017-01-16 15:51 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, Joao Pinto, Arnd Bergmann, linux-doc, linux-pci,
linux-arm-msm, nsekhar, linux-kernel, linux-arm-kernel,
Christoph Hellwig, linux-samsung-soc, Jingoo Han, Bjorn Helgaas,
linux-omap, linuxppc-dev, linux-arm-kernel
In-Reply-To: <587C61B3.3070107@ti.com>
On Mon, Jan 16, 2017 at 11:31:23AM +0530, Kishon Vijay Abraham I wrote:
> Actually not all devices have hardcoded headers. E.g the platform I'm using
> doesn't have hardcoded headers and it can be configured based on the function
> the user would like to use. If the devices are hardcoded, then using configfs
> can be skipped altogether. In such cases, APIs like pci_epf_create() can
> directly be used by the drivers instead of going via configfs.
That's exactly what I meant - the IDs need to be set by the driver for
the implemented PCI device, and it's not up to the gadget core to configur
e them, it's up to the implementation of the PCIe device which PCI it
exposes.
^ permalink raw reply
* Re: [PATCH v1 5/7] ARM: dts: stm32f429: Add ltdc support
From: Alexandre Torgue @ 2017-01-16 15:58 UTC (permalink / raw)
To: Yannick Fertre, Thierry Reding, David Airlie, Maxime Coquelin,
Russell King, Mark Rutland, Rob Herring, Arnd Bergmann
Cc: Philippe Cornu, Mickael Reulier, Gabriel FERNANDEZ,
kernel-F5mvAk5X5gdBDgjK7y7TUQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484573344-11609-6-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
Hi,
On 01/16/2017 02:29 PM, Yannick Fertre wrote:
> Add LTDC (Lcd-tft Display Controller) support.
>
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
Can you change commit header by: "ARM: dts: stm32: Add ltdc support on
stm32f429 MCU" please
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 25 ++++++++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 336ee4f..fc43415 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -185,7 +185,7 @@
> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> };
>
> - pin-controller {
> + pinctrl: pin-controller {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "st,stm32f429-pinctrl";
> @@ -404,6 +404,29 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + st-display-subsystem {
> + compatible = "st,display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + dma-ranges;
> +
> + ltdc_host: stm32-ltdc@40016800 {
> + compatible = "st,ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = <&rcc 314>;
> + clocks = <&rcc 1 8>;
> + clock-names = "clk-lcd";
> + status = "disabled";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> };
> };
>
>
--
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 v1 6/7] ARM: dts: stm32429i-eval: Enable ltdc & simple panel on Eval board
From: Alexandre Torgue @ 2017-01-16 16:02 UTC (permalink / raw)
To: Yannick Fertre, Thierry Reding, David Airlie, Maxime Coquelin,
Russell King, Mark Rutland, Rob Herring, Arnd Bergmann
Cc: devicetree, kernel, Philippe Cornu, dri-devel, Mickael Reulier,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1484573344-11609-7-git-send-email-yannick.fertre@st.com>
Hi
On 01/16/2017 02:29 PM, Yannick Fertre wrote:
> Enable ltdc & enable am-480272h3tmqw-t01h panel.
>
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
Can you please change commit header with:
"ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board"
> arch/arm/boot/dts/stm32429i-eval.dts | 58 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
> index 2de6487..f987ca5 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -88,6 +88,52 @@
> clocks = <&rcc 0 30>;
> clock-names = "main_clk";
> };
> +
> + panel_rgb: panel-rgb {
> + compatible = "ampire,am-480272h3tmqw-t01h";
> + status = "okay";
> + port {
> + panel_in_rgb: endpoint {
> + remote-endpoint = <<dc_out_rgb>;
> + };
> + };
> + };
> +};
> +
> +&pinctrl {
> + pinctrl_ltdc: ltdc@0 {
> + pins {
Pinmuxing definition is SOC specific. Please move it in stm32f429.dtsi
file. Note that a development is ongoing to define pinmuxing in a
dedicated pinctrl-stm32f4.dtsi file.
> + pinmux = <STM32F429_PI12_FUNC_LCD_HSYNC>,
> + <STM32F429_PI13_FUNC_LCD_VSYNC>,
> + <STM32F429_PI14_FUNC_LCD_CLK>,
> + <STM32F429_PI15_FUNC_LCD_R0>,
> + <STM32F429_PJ0_FUNC_LCD_R1>,
> + <STM32F429_PJ1_FUNC_LCD_R2>,
> + <STM32F429_PJ2_FUNC_LCD_R3>,
> + <STM32F429_PJ3_FUNC_LCD_R4>,
> + <STM32F429_PJ4_FUNC_LCD_R5>,
> + <STM32F429_PJ5_FUNC_LCD_R6>,
> + <STM32F429_PJ6_FUNC_LCD_R7>,
> + <STM32F429_PJ7_FUNC_LCD_G0>,
> + <STM32F429_PJ8_FUNC_LCD_G1>,
> + <STM32F429_PJ9_FUNC_LCD_G2>,
> + <STM32F429_PJ10_FUNC_LCD_G3>,
> + <STM32F429_PJ11_FUNC_LCD_G4>,
> + <STM32F429_PJ12_FUNC_LCD_B0>,
> + <STM32F429_PJ13_FUNC_LCD_B1>,
> + <STM32F429_PJ14_FUNC_LCD_B2>,
> + <STM32F429_PJ15_FUNC_LCD_B3>,
> + <STM32F429_PK0_FUNC_LCD_G5>,
> + <STM32F429_PK1_FUNC_LCD_G6>,
> + <STM32F429_PK2_FUNC_LCD_G7>,
> + <STM32F429_PK3_FUNC_LCD_B4>,
> + <STM32F429_PK4_FUNC_LCD_B5>,
> + <STM32F429_PK5_FUNC_LCD_B6>,
> + <STM32F429_PK6_FUNC_LCD_B7>,
> + <STM32F429_PK7_FUNC_LCD_DE>;
> + slew-rate = <2>;
> + };
> + };
> };
>
> &clk_hse {
> @@ -123,3 +169,15 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +<dc_host{
> + status = "okay";
> + pinctrl-0 = <&pinctrl_ltdc>;
> + pinctrl-names = "default";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + remote-endpoint = <&panel_in_rgb>;
> + };
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH v1 0/7] DRM: add LTDC support for STM32F4
From: Neil Armstrong @ 2017-01-16 16:02 UTC (permalink / raw)
To: Yannick Fertre, Alexandre TORGUE, Thierry Reding, David Airlie,
Maxime Coquelin, Russell King, Mark Rutland, Rob Herring,
Arnd Bergmann
Cc: devicetree, kernel, Philippe Cornu, dri-devel, Mickael Reulier,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1484573344-11609-1-git-send-email-yannick.fertre@st.com>
On 01/16/2017 02:28 PM, Yannick Fertre wrote:
> The purpose of this set of patches is to add a new driver for stm32f429.
> This driver was developed and tested on evaluation board stm32429i.
>
> Stm32f4 is a MCU platform which don't have MMU so the last patches developed
> by Benjamin Gaignard regarding "DRM: allow to use mmuless devices"
> are necessary.
>
> The board stm429i embeds a Ampire AM-480272H3TMQW-T01H screen.
> A new simple panel am-480272h3tmqw-t01h have been added to support it.
>
> Yannick Fertre (7):
> dt-bindings: display: add STM32 LTDC driver
> drm/st: Add STM32 LTDC driver
> dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
> drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
> ARM: dts: stm32f429: Add ltdc support
> ARM: dts: stm32429i-eval: Enable ltdc & simple panel on Eval board
> ARM: configs: Add STM32 LTDC support in STM32 defconfig
>
> .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 +
> .../devicetree/bindings/display/st,ltdc.txt | 57 +
> arch/arm/boot/dts/stm32429i-eval.dts | 58 +
> arch/arm/boot/dts/stm32f429.dtsi | 25 +-
> arch/arm/configs/stm32_defconfig | 5 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/panel/panel-simple.c | 29 +
> drivers/gpu/drm/st/Kconfig | 14 +
> drivers/gpu/drm/st/Makefile | 7 +
> drivers/gpu/drm/st/drv.c | 279 ++++
> drivers/gpu/drm/st/drv.h | 25 +
> drivers/gpu/drm/st/ltdc.c | 1438 ++++++++++++++++++++
> drivers/gpu/drm/st/ltdc.h | 20 +
> 14 files changed, 1966 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> create mode 100644 drivers/gpu/drm/st/Kconfig
> create mode 100644 drivers/gpu/drm/st/Makefile
> create mode 100644 drivers/gpu/drm/st/drv.c
> create mode 100644 drivers/gpu/drm/st/drv.h
> create mode 100644 drivers/gpu/drm/st/ltdc.c
> create mode 100644 drivers/gpu/drm/st/ltdc.h
>
Hi Yannick,
Shouldn't be more logical to use stm32 for the driver instead of st ?
It would eventually collude with the other STMicroelectronics SoCs and
will be aligned with other drivers like stm32-rtc, stm32-i2c, ...
Neil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 7/7] ARM: configs: Add STM32 LTDC support in STM32 defconfig
From: Alexandre Torgue @ 2017-01-16 16:03 UTC (permalink / raw)
To: Yannick Fertre, Thierry Reding, David Airlie, Maxime Coquelin,
Russell King, Mark Rutland, Rob Herring, Arnd Bergmann
Cc: devicetree, kernel, Philippe Cornu, dri-devel, Mickael Reulier,
Gabriel FERNANDEZ, linux-arm-kernel
In-Reply-To: <1484573344-11609-8-git-send-email-yannick.fertre@st.com>
Hi
On 01/16/2017 02:29 PM, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
> ---
commit header "ARM: configs: stm32: ADD LDTC support"
> arch/arm/configs/stm32_defconfig | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index 29068f5..e3974d9 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -71,3 +71,8 @@ CONFIG_MAGIC_SYSRQ=y
> # CONFIG_FTRACE is not set
> CONFIG_CRC_ITU_T=y
> CONFIG_CRC7=y
> +CONFIG_DRM=y
> +CONFIG_DRM_ST=y
> +CONFIG_DRM_PANEL=y
> +CONFIG_DRM_PANEL_SIMPLE=y
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
>
^ permalink raw reply
* Re: [PATCH] mtd: spi-nor: add dt support for Everspin MRAMs
From: Marek Vasut @ 2017-01-16 16:08 UTC (permalink / raw)
To: Rafał Miłecki, Uwe Kleine-König
Cc: Marek Vasut, Mark Rutland, devicetree@vger.kernel.org,
Masahiko Iwamoto, linux-mtd@lists.infradead.org, Sascha Hauer,
Geert Uytterhoeven, Cyrille Pitchen, Jagan Teki
In-Reply-To: <CACna6ryLDwr0S=e-uUt+ZGcY8mNDnUtBPg_RmqtSVBziJkZd5w@mail.gmail.com>
On 01/16/2017 02:55 PM, Rafał Miłecki wrote:
> On 16 January 2017 at 14:35, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>> The MR25 family doesn't support JEDEC, so they need explicit mentioning
>> in the list of supported spi IDs. This makes it possible to add these
>> using for example:
>>
>> compatible = "everspin,mr25h40";
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> Hello,
>>
>> independent of the decision if -nonjedec is ok for m25p, this is needed
>> to make Everspin's MRAMs work.
>>
>> Best regards
>> Uwe
>>
>> drivers/mtd/devices/m25p80.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
>> {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
>> {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
>>
>> + /* Everspin MRAMs without JEDEC support */
>> + { "mr25h256" }, /* 256 kib, 40 MHz */
>
> A trivial thing: I think it should be Kib
> https://en.wikipedia.org/wiki/Binary_prefix
>
Except for that, it looks good IMO.
--
Best regards,
Marek Vasut
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-16 16:09 UTC (permalink / raw)
To: Boris Brezillon, Rob Herring, Mark Rutland
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Russell King,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170116094032.6f471f11@bbrezillon>
On 01/16/2017 09:40 AM, Boris Brezillon wrote:
> On Sun, 15 Jan 2017 01:23:48 +0100
> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 01/14/2017 09:29 AM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 18:33:40 +0100
>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> On 01/13/2017 05:56 PM, Boris Brezillon wrote:
>>>>> On Fri, 13 Jan 2017 17:44:12 +0100
>>>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>
>>>>>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
>>>>>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>>>>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>
>>>>>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>>>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Add Mediatek nor flash node.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>>>>>> ---
>>>>>>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>>>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>>>>>>>> 2 files changed, 37 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>>>>>> @@ -24,6 +24,31 @@
>>>>>>>>>>> };
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> +&nor_flash {
>>>>>>>>>>> + pinctrl-names = "default";
>>>>>>>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>>>>>>>> + status = "okay";
>>>>>>>>>>> + flash@0 {
>>>>>>>>>>> + compatible = "jedec,spi-nor";
>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>> + };
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> +&pio {
>>>>>>>>>>> + nor_pins_default: nor {
>>>>>>>>>>> + pins1 {
>>>>>>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>>>>>>>> + bias-pull-up;
>>>>>>>>>>> + };
>>>>>>>>>>> + };
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>> &uart0 {
>>>>>>>>>>> status = "okay";
>>>>>>>>>>> };
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> index bdf8954..1eefce4 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>>>>>> @@ -227,6 +227,18 @@
>>>>>>>>>>> status = "disabled";
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>> + nor_flash: spi@11014000 {
>>>>>>>>>>> + compatible = "mediatek,mt2701-nor",
>>>>>>>>>>> + "mediatek,mt8173-nor";
>>>>>>>>>>
>>>>>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think even if the ip block is the same, we should provide both
>>>>>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>>>>>
>>>>>>>>> We can drop the mt2701-nor in the bindings definition if you want.
>>>>>>>
>>>>>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>>>>>> list/support all possible compatibles, maybe you should just put one
>>>>>>> compatible in your DT and patch your driver (+ binding doc) to define
>>>>>>> all of them.
>>>>>>
>>>>>> Uh, what ? I lost you here :-)
>>>
>>> I mean adding a new entry in the mtk_nor_of_ids table (in
>>> mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
>>> matched directly, and you won't need to define 2 compatible strings in
>>> your device tree.
>>
>> But then you grow the table in the driver, is that what we want if we
>> can avoid that ?
>
> The space you save by not growing the mtk_nor_of_ids table is lost in
> your dtbs, so I'm not sure the size argument is relevant here. Also,
> note that distros are shipping a lot of dtbs, and you're likely to have
> several boards based on the mt2701 SoC, so, for this specific use case,
> it's better to make the in-driver of-id table grow than specifying 2
> compatibles in the DT. But as I said, I'm not sure we should rely on
> this argument to decide which approach to choose (we're talking about a
> few bytes here).
>
>>
>>>>>>
>>>>>>>> This exactly. We should have a DT compat in the form:
>>>>>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>>>>>> Then if we find a problem in the future, we can match on the
>>>>>>>> "vendor,<soc>-block" and still support the old DTs.
>>>>>>>
>>>>>>> Not sure it's only in term of whose IP appeared first. My understanding
>>>>>>> is that it's a way to provide inheritance. For example:
>>>>>>>
>>>>>>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>>>>>
>>>>>>> BTW, which one is the oldest between mt8173 and mt2701? :-)
>>>>>>
>>>>>> And that's another thing and I agree with you, but I don't think that's
>>>>>> what we're discussing in this thread. But (!), OT, I think we should
>>>>>> codify the rules in Documentation/ . This discussion came up multiple
>>>>>> times recently.
>>>>>>
>>>>>> And my question still stands, what do we put into the DT here, IMO
>>>>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>>>>>
>>>>> I'd say
>>>>>
>>>>> compatible = "mediatek,mt8173-nor";
>>>>>
>>>>> because both compatible are referring to very specific IP version. It's
>>>>> not the same as
>>>>
>>>> But then you don't have the ability to handle a block in this particular
>>>> SoC in case there's a bug found in it in the future,
>>>> so IMO it should be:
>>>>
>>>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>>>
>>> Sorry again, I meant
>>>
>>> compatible = "mediatek,mt2701-nor";
>>>
>>>>
>>>>> compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
>>>>
>>>> This doesn't look right, since here we add two new compatibles ...
>>>
>>> That was just an example to describe how compatible inheritance works
>>> (at least that's my understanding of it), it does not apply to this
>>> particular use case.
>>
>> Well this is OK I guess, but then you can also use "mediatek,mt8173-nor"
>> as the oldest supported compatible and be done with it, no ? It looks a
>> bit crappy though, I admit that ...
>>
>
> Let's stop bikeshedding and wait for DT maintainers feedback
> before taking a decision ;-).
+1 :)
> Rob, Mark, any opinion?
>
--
Best regards,
Marek Vasut
--
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] mtd: spi-nor: add SPI_NOR_DUAL_READ to mx66l51235l
From: Marek Vasut @ 2017-01-16 16:15 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Robert Lippert, Robert Lippert
In-Reply-To: <1484573225-19095-4-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On 01/16/2017 02:27 PM, Cédric Le Goater wrote:
> From: Robert Lippert <roblip-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1) Commit message missing
2) This is unrelated to the rest of the series, send separately please
> Signed-off-by: Robert Lippert <rlippert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index da7cd69d4857..775788f9828a 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -876,7 +876,7 @@ static const struct flash_info spi_nor_ids[] = {
> { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
> { "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, SECT_4K) },
> { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
> - { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) },
> + { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "mx66l1g55g", INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },
>
> /* Micron */
>
--
Best regards,
Marek Vasut
--
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] mtd: spi-nor: add SPI_NOR_DUAL_READ to mx66l51235l
From: Cédric Le Goater @ 2017-01-16 16:39 UTC (permalink / raw)
To: Marek Vasut, linux-mtd
Cc: Mark Rutland, Boris Brezillon, Robert Lippert, devicetree,
Richard Weinberger, Robert Lippert, Rob Herring, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <57b7480d-4b5a-c420-d790-b22445eec723@gmail.com>
Hello Marek,
On 01/16/2017 05:15 PM, Marek Vasut wrote:
> On 01/16/2017 02:27 PM, Cédric Le Goater wrote:
>> From: Robert Lippert <roblip@gmail.com>
>
> 1) Commit message missing
> 2) This is unrelated to the rest of the series, send separately please
ok. I will do that. Rob, I will take ownership if you don't mind.
Thanks,
C.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH v3 0/13] arm64: allwinner: a64: Enable MMC support
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: devicetree, Andre Przywara, linux-mmc, linux-kernel, Rob Herring,
linux-arm-kernel
Hi,
Here is a new attempt at getting the MMC controllers running, following the
work done by Andre.
This has been tested on a board with one SDIO device (a Marvell WiFi chip)
and a Kingston eMMC with 1.8V IOs.
For SDIO, the HS DDR mode works just fine. That serie also enables the
SDR104 mode to work on the devices that are capable of this.
For the eMMC, HS200 with the voltage switch works. HS400 doesn't at the
moment, but since it's significantly more complex, and at the same time
Allwinner recommends to limit its frequency to 100MHz, this doesn't have
any benefits. If there's any at some point, this can be added later.
Let me know what you think,
Maxime
Changes from v2:
- Enabled SDR104, limited the frequency to 150MHz. 200MHz was too high.
- Added more fixes to the gating and frequency rate change sequence
- Added one more patch to mask DATA0 when updating the clock that was
needed to get SDR104 to run
- Added the patches to enable it on a few boards done by Andre
- Amended the comments as suggested by Andre.
- Added some tags
Andre Przywara (4):
arm64: allwinner: a64: Add MMC nodes
arm64: allwinner: pine64: add MMC support
arm64: allwinner: a64: add UART1 pin nodes
arm64: allwinner: add BananaPi-M64 support
Maxime Ripard (9):
mmc: sunxi: Fix clock frequency change sequence
mmc: sunxi: Gate the clock when rate is 0
mmc: sunxi: Always set signal delay to 0 for A64
mmc: sunxi: Enable the new timings for the A64 MMC controllers
mmc: sunxi: Mask DATA0 when updating the clock
mmc: sunxi: Add EMMC (MMC2) controller compatible
mmc: sunxi: Add more debug messages
arm64: allwinner: a64: Add MMC pinctrl nodes
arm64: allwinner: a64: Increase the MMC max frequency
arch/arm64/boot/dts/allwinner/Makefile | 1 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 120 +++++++-
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 20 +-
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 77 ++++-
drivers/mmc/host/sunxi-mmc.c | 101 +++---
5 files changed, 278 insertions(+), 41 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
base-commit: bc34c1af0a280e27eafe3f86b9ad87fe0c9ea715
--
git-series 0.8.11
^ permalink raw reply
* [PATCH v3 1/13] mmc: sunxi: Fix clock frequency change sequence
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: devicetree, Andre Przywara, linux-mmc, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
The MMC and SD specifications documents that the clock frequency should
only be changed once gated.
The current code first modifies the parent clock, gates it and then
modifies the internal divider. This means that since the parent clock rate
might be changed, the bus clock might be changed as well before it is
gated, which breaks the specification.
Move the gating before the parent rate modification.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index b1d1303389a7..ab4324e6eb74 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -761,6 +761,10 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
u32 rval, clock = ios->clock;
int ret;
+ ret = sunxi_mmc_oclk_onoff(host, 0);
+ if (ret)
+ return ret;
+
/* 8 bit DDR requires a higher module clock */
if (ios->timing == MMC_TIMING_MMC_DDR52 &&
ios->bus_width == MMC_BUS_WIDTH_8)
@@ -783,10 +787,6 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
return ret;
}
- ret = sunxi_mmc_oclk_onoff(host, 0);
- if (ret)
- return ret;
-
/* clear internal divider */
rval = mmc_readl(host, REG_CLKCR);
rval &= ~0xff;
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 2/13] mmc: sunxi: Gate the clock when rate is 0
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: Rob Herring, devicetree, linux-arm-kernel, linux-kernel,
linux-mmc, Andre Przywara
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
The MMC core assumes that the code will gate the clock when the bus
frequency is set to 0, which we've been ignoring so far.
Handle that.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index ab4324e6eb74..019f95e8e7c5 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -765,6 +765,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
if (ret)
return ret;
+ if (!ios->clock)
+ return 0;
+
/* 8 bit DDR requires a higher module clock */
if (ios->timing == MMC_TIMING_MMC_DDR52 &&
ios->bus_width == MMC_BUS_WIDTH_8)
@@ -882,7 +885,7 @@ static void sunxi_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmc_writel(host, REG_GCTRL, rval);
/* set up clock */
- if (ios->clock && ios->power_mode) {
+ if (ios->power_mode) {
host->ferror = sunxi_mmc_clk_set_rate(host, ios);
/* Android code had a usleep_range(50000, 55000); here */
}
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 3/13] mmc: sunxi: Always set signal delay to 0 for A64
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: devicetree, Andre Przywara, linux-mmc, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
Experience have shown that the using the autocalibration could severely
degrade the performances of the MMC bus.
Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
Remove the calibration code for now, and add comments to document our
findings.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 50 ++++++++++++-------------------------
1 file changed, 17 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 019f95e8e7c5..b9c8a62bc212 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -683,41 +683,19 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host, int reg_off)
{
- u32 reg = readl(host->reg_base + reg_off);
- u32 delay;
- unsigned long timeout;
-
if (!host->cfg->can_calibrate)
return 0;
- reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
- reg &= ~SDXC_CAL_DL_SW_EN;
-
- writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
-
- dev_dbg(mmc_dev(host->mmc), "calibration started\n");
-
- timeout = jiffies + HZ * SDXC_CAL_TIMEOUT;
-
- while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE)) {
- if (time_before(jiffies, timeout))
- cpu_relax();
- else {
- reg &= ~SDXC_CAL_START;
- writel(reg, host->reg_base + reg_off);
-
- return -ETIMEDOUT;
- }
- }
-
- delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
-
- reg &= ~SDXC_CAL_START;
- reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
-
- writel(reg, host->reg_base + reg_off);
-
- dev_dbg(mmc_dev(host->mmc), "calibration ended, reg is 0x%x\n", reg);
+ /*
+ * FIXME:
+ * This is not clear how the calibration is supposed to work
+ * yet. The best rate have been obtained by simply setting the
+ * delay to 0, as Allwinner does in its BSP.
+ *
+ * The only mode that doesn't have such a delay is HS400, that
+ * is in itself a TODO.
+ */
+ writel(SDXC_CAL_DL_SW_EN, host->reg_base + reg_off);
return 0;
}
@@ -809,7 +787,13 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
if (ret)
return ret;
- /* TODO: enable calibrate on sdc2 SDXC_REG_DS_DL_REG of A64 */
+ /*
+ * FIXME:
+ *
+ * In HS400 we'll also need to calibrate the data strobe
+ * signal. This should only happen on the MMC2 controller (at
+ * least on the A64).
+ */
return sunxi_mmc_oclk_onoff(host, 1);
}
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 4/13] mmc: sunxi: Enable the new timings for the A64 MMC controllers
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: devicetree, Andre Przywara, linux-mmc, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
The A64 MMC controllers need to set a "new timings" bit when a new rate is
set.
The actual meaning of that bit is not clear yet, but not setting it leads
to some corner-case issues, like the CMD53 failing, which is used to
implement SDIO packet aggregation.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 6 ++++++
1 file changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index b9c8a62bc212..51d6388a194e 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -253,6 +253,8 @@ struct sunxi_mmc_cfg {
/* does the IP block support autocalibration? */
bool can_calibrate;
+
+ bool needs_new_timings;
};
struct sunxi_mmc_host {
@@ -779,6 +781,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
}
mmc_writel(host, REG_CLKCR, rval);
+ if (host->cfg->needs_new_timings)
+ mmc_writel(host, REG_SD_NTSR, SDXC_2X_TIMING_MODE);
+
ret = sunxi_mmc_clk_set_phase(host, ios, rate);
if (ret)
return ret;
@@ -1076,6 +1081,7 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.idma_des_size_bits = 16,
.clk_delays = NULL,
.can_calibrate = true,
+ .needs_new_timings = true,
};
static const struct of_device_id sunxi_mmc_of_match[] = {
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 5/13] mmc: sunxi: Mask DATA0 when updating the clock
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: Rob Herring, devicetree, linux-arm-kernel, linux-kernel,
linux-mmc, Andre Przywara
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
The A64 MMC controllers need DATA0 to be masked while updating the clock,
otherwise any subsequent command will result in a timeout.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 51d6388a194e..6bbe61397b7c 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -101,6 +101,7 @@
(SDXC_SOFT_RESET | SDXC_FIFO_RESET | SDXC_DMA_RESET)
/* clock control bits */
+#define SDXC_MASK_DATA0 BIT(31)
#define SDXC_CARD_CLOCK_ON BIT(16)
#define SDXC_LOW_POWER_ON BIT(17)
@@ -254,6 +255,9 @@ struct sunxi_mmc_cfg {
/* does the IP block support autocalibration? */
bool can_calibrate;
+ /* Does DATA0 needs to be masked while the clock is updated */
+ bool mask_data0;
+
bool needs_new_timings;
};
@@ -657,10 +661,12 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
u32 rval;
rval = mmc_readl(host, REG_CLKCR);
- rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
+ rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON | SDXC_MASK_DATA0);
if (oclk_en)
rval |= SDXC_CARD_CLOCK_ON;
+ if (host->cfg->mask_data0)
+ rval |= SDXC_MASK_DATA0;
mmc_writel(host, REG_CLKCR, rval);
@@ -680,6 +686,11 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
return -EIO;
}
+ if (host->cfg->mask_data0) {
+ rval = mmc_readl(host, REG_CLKCR);
+ mmc_writel(host, REG_CLKCR, rval & ~SDXC_MASK_DATA0);
+ }
+
return 0;
}
@@ -1081,6 +1092,7 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.idma_des_size_bits = 16,
.clk_delays = NULL,
.can_calibrate = true,
+ .mask_data0 = true,
.needs_new_timings = true,
};
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 6/13] mmc: sunxi: Add EMMC (MMC2) controller compatible
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: Rob Herring, devicetree, linux-arm-kernel, linux-kernel,
linux-mmc, Andre Przywara
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
The MMC2 controller on the A64 is kind of a special beast.
While the general controller design is the same than the other MMC
controllers in the SoC, it also has a bunch of features and changes that
prevent it to be driven in the same way.
It has for example a different bus width limit, a different maximum
frequency, and, for some reason, the maximum buffer size of a DMA
descriptor.
Add a new compatible specifically for this controller.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 8 ++++++++
1 file changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 6bbe61397b7c..f0f6922bca8a 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -5,6 +5,7 @@
* (C) Copyright 2013-2014 O2S GmbH <www.o2s.ch>
* (C) Copyright 2013-2014 David Lanzend�rfer <david.lanzendoerfer@o2s.ch>
* (C) Copyright 2013-2014 Hans de Goede <hdegoede@redhat.com>
+ * (C) Copyright 2017 Sootech SA
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -1096,12 +1097,19 @@ static const struct sunxi_mmc_cfg sun50i_a64_cfg = {
.needs_new_timings = true,
};
+static const struct sunxi_mmc_cfg sun50i_a64_emmc_cfg = {
+ .idma_des_size_bits = 13,
+ .clk_delays = NULL,
+ .can_calibrate = true,
+};
+
static const struct of_device_id sunxi_mmc_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-mmc", .data = &sun4i_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-mmc", .data = &sun5i_a13_cfg },
{ .compatible = "allwinner,sun7i-a20-mmc", .data = &sun7i_a20_cfg },
{ .compatible = "allwinner,sun9i-a80-mmc", .data = &sun9i_a80_cfg },
{ .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg },
+ { .compatible = "allwinner,sun50i-a64-emmc", .data = &sun50i_a64_emmc_cfg },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 7/13] mmc: sunxi: Add more debug messages
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: Rob Herring, devicetree, linux-arm-kernel, linux-kernel,
linux-mmc, Andre Przywara
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
Add a bit more debug messages that can be helpful when debugging the clock
setup.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/mmc/host/sunxi-mmc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index f0f6922bca8a..40ed287ceb1c 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -661,6 +661,9 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
unsigned long expire = jiffies + msecs_to_jiffies(750);
u32 rval;
+ dev_dbg(mmc_dev(host->mmc), "%sabling the clock\n",
+ oclk_en ? "en" : "dis");
+
rval = mmc_readl(host, REG_CLKCR);
rval &= ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON | SDXC_MASK_DATA0);
@@ -737,6 +740,7 @@ static int sunxi_mmc_clk_set_phase(struct sunxi_mmc_host *host,
index = SDXC_CLK_50M_DDR;
}
} else {
+ dev_dbg(mmc_dev(host->mmc), "Invalid clock... returning\n");
return -EINVAL;
}
@@ -753,6 +757,9 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
u32 rval, clock = ios->clock;
int ret;
+ dev_dbg(mmc_dev(host->mmc), "setting clk to %u (requested %u)\n",
+ clock, ios->clock);
+
ret = sunxi_mmc_oclk_onoff(host, 0);
if (ret)
return ret;
@@ -771,8 +778,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
clock, rate);
return rate;
}
- dev_dbg(mmc_dev(host->mmc), "setting clk to %d, rounded %ld\n",
- clock, rate);
+ dev_dbg(mmc_dev(host->mmc), "Rounded clk to %ld\n", rate);
/* setting clock rate */
ret = clk_set_rate(host->clk_mmc, rate);
--
git-series 0.8.11
^ permalink raw reply related
* [PATCH v3 8/13] arm64: allwinner: a64: Add MMC nodes
From: Maxime Ripard @ 2017-01-16 16:56 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, Ulf Hansson
Cc: devicetree, Andre Przywara, linux-mmc, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <cover.a06ce1672d7a72ee7f9bbca46fdd223edd6b2313.1484585798.git-series.maxime.ripard@free-electrons.com>
From: Andre Przywara <andre.przywara@arm.com>
The A64 has 3 MMC controllers, one of them being especially targeted to
eMMC. Among other things, it has a data strobe signal and a 8 bits data
width.
The two other are more usual controllers that will have a 4 bits width at
most and no data strobe signal, which limits it to more usual SD or MMC
peripherals.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 39 ++++++++++++++++++++-
1 file changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 99b6bb1e141c..143e9706438f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -299,6 +299,45 @@
#size-cells = <0>;
};
+ mmc0: mmc@1c0f000 {
+ compatible = "allwinner,sun50i-a64-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@1c10000 {
+ compatible = "allwinner,sun50i-a64-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@1c11000 {
+ compatible = "allwinner,sun50i-a64-emmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
git-series 0.8.11
^ 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