* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Stefan Agner @ 2016-11-19 1:18 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Tim Harvey, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Ulf Hansson, Fabio Estevam, Javier Martinez Canillas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161115235503.GC1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 2016-11-15 15:55, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
>> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
>> > <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> > >> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > >> > So, someone merged a patch which makes mmcblk devices follow the
>> > >> > host controller numbering.
>> > >> >
>> > >> > Now my cubox-i fails to boot correctly because the SD card in the
>> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> > >> >
>> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > >> > remotely near a SD card or eMMC present. So, this change is
>> > >> > confusing on these platforms.
>> > >> >
>> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > >> > their kernels.
>> > >> >
>> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> > >> >
>> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
>> > >> > please revert whatever change caused this, and next time limit it
>> > >> > to only eMMC.
>> > >> >
>> > >> > Thanks.
>> > >>
>> > >> I see the same thing on newer kernels, which is why I asked the
>> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> > >> device and was looking for a way to control that via dt. Now I'm
>> > >> understanding that to avoid this kind of bootloader/kernel dependence
>> > >> issue I should be using UUID's to identify the boot device.
>> > >>
>> > >> >From my testing it looks like the change your looking for occurred
>> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> > >> regression specifically.
>> > >
>> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
>> > > which ties the block device number to the host device index, but that's
>> > > really only part of the story here.
>> > >
>> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
>> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
>> > > of behaviour - there can be no argument about that.
>> > >
>> > > Now, digging further into this today, it appears that:
>> > >
>> > > v4.8: usdhc2 was probed first, and is given mmc0.
>> > > usdhc1 is probed second, and is given mmc1.
>> > >
>> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
>> > > usdhc2 is probed second, and is given mmc1.
>> > >
>> > > I haven't yet been able to figure out why there's been this change
>> > > of probe order. There's no change that I can see in the iMX6 DT
>> > > files that would account for this.
>> > >
>> >
>> > I bisected it and the commit your looking for is
>> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>>
>> No it's not.
>>
>> Let me try and put it plainer:
>>
>> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
>> device number (mmcblkN) to the mmc host interface number (mmcN).
>> This change happened between 4.5 and 4.6.
>>
>> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
>> seeing a change of behaviour between 4.5 and 4.6.
>>
>> * The change I'm seeing changes the order of the physical device
>> associated with the hosts named mmc0 and mmc1 in the kernel.
>>
>> * Because physical devices associated with the mmc0 and mmc1 hosts
>> swap over, the mmcblkN number changes due to the commit you point
>> out.
>>
>> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
>> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
>> else changing the order in which the two usdhc physical hardware
>> blocks get probed.
>>
>> Does this make it clearer?
>
> It turns out to be this commit:
>
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Date: Mon Sep 19 01:16:44 2016 +0900
>
> clk: probe common clock drivers earlier
>
> Several SoCs implement platform drivers for clocks rather than
> CLK_OF_DECLARE(). Clocks should come earlier because they are
> prerequisites for many of other drivers. It will help to mitigate
> EPROBE_DEFER issues.
>
> Also, drop the comment since it does not carry much value.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>
> which changes the init order. In 4.8, we get:
Afaik, init order is not guaranteed, it never was. Usually the order
ends up to be in some order of the device tree, but one could also parse
the device tree in reverse order (which would be an interesting
experiment).
If we want to rely on ordering, we need to add alias support.
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] of: Fix issue where code would fall through to error case.
From: Moritz Fischer @ 2016-11-19 0:48 UTC (permalink / raw)
To: linux-kernel
Cc: pantelis.antoniou, robh+dt, frowand.list, devicetree, moritz,
Moritz Fischer
No longer fall through into the error case that prints out
an error if no error (err = 0) occurred.
Fixes d9181b20a83(of: Add back an error message, restructured)
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Frank Rowand <frank.rowand@am.sony.com>
---
Hi Rob,
this is Frank's suggestion. I don't have a strong preference one way or the other.
Feel free to pick one or the other.
Cheers,
Moritz
---
drivers/of/resolver.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 783bd09..c47404f3 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -358,14 +358,14 @@ int of_resolve_phandles(struct device_node *overlay)
err = update_usages_of_a_phandle_reference(overlay, prop, phandle);
if (err)
- break;
+ goto err_out;
}
-
-err_out:
- pr_err("overlay phandle fixup failed: %d\n", err);
out:
of_node_put(tree_symbols);
-
return err;
+
+err_out:
+ pr_err("overlay phandle fixup failed: %d\n", err);
+ goto out;
}
EXPORT_SYMBOL_GPL(of_resolve_phandles);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-11-19 0:32 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, Axel Haslam,
Bartosz Gołaszewski, Alexandre Bailon, David Lechner,
Rob Herring
In-Reply-To: <20161119003208.10550-1-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/media/ti,vpif-capture.txt | 65 ++++++++++++++++++++++
.../devicetree/bindings/media/ti,vpif.txt | 8 +++
2 files changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,vpif-capture.txt
create mode 100644 Documentation/devicetree/bindings/media/ti,vpif.txt
diff --git a/Documentation/devicetree/bindings/media/ti,vpif-capture.txt b/Documentation/devicetree/bindings/media/ti,vpif-capture.txt
new file mode 100644
index 000000000000..eaaaa46d3a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,vpif-capture.txt
@@ -0,0 +1,65 @@
+Texas Instruments VPIF Capture
+------------------------------
+
+The TI Video Port InterFace (VPIF) capture component is the primary
+component for video capture on some TI DaVinci family SoCs.
+
+TI Document number reference: SPRUH82C
+
+Required properties:
+- compatible: must be "ti,vpif-capture"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+VPIF capture has a 16-bit parallel bus input, supporting 2 8-bit
+channels or a single 16-bit channel. It should contain at least one
+port child node with child 'endpoint' node. Please refer to the
+bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+ vpif_capture: video-capture@0x00217000 {
+ compatible = "ti,vpif-capture";
+ reg = <0x00217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint@0 {
+ reg = <0>;
+ bus-width = <8>;
+ remote-endpoint = <&composite>;
+ };
+
+ vpif_ch1: endpoint@1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
+
+[ ... ]
+
+&i2c0 {
+
+ tvp5147@5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
+
+};
diff --git a/Documentation/devicetree/bindings/media/ti,vpif.txt b/Documentation/devicetree/bindings/media/ti,vpif.txt
new file mode 100644
index 000000000000..0d5c16531c0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,vpif.txt
@@ -0,0 +1,8 @@
+Texas Instruments VPIF
+----------------------
+
+The Video Port InterFace (VPIF) is the core component for video output
+and capture on TI Davinci family SoCs.
+
+- compatible: must be "ti,vpif"
+- reg: physical base address and length of the registers set for the device;
--
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
* [PATCH 3/4] [media] davinci: vpif_capture: get subdevs from DT
From: Kevin Hilman @ 2016-11-19 0:32 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, Axel Haslam,
Bartosz Gołaszewski, Alexandre Bailon, David Lechner
In-Reply-To: <20161119003208.10550-1-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Allow getting of subdevs from DT ports and endpoints.
The _get_pdata() function was larely inspired by (i.e. stolen from)
am437x-vpfe.c
Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/media/platform/davinci/vpif_capture.c | 130 +++++++++++++++++++++++++-
include/media/davinci/vpif_types.h | 9 +-
2 files changed, 133 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index becc3e63b472..a0353d13eb92 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -26,6 +26,8 @@
#include <linux/slab.h>
#include <media/v4l2-ioctl.h>
+#include <media/v4l2-of.h>
+#include <media/i2c/tvp514x.h>
#include "vpif.h"
#include "vpif_capture.h"
@@ -651,6 +653,10 @@ static int vpif_input_to_subdev(
vpif_dbg(2, debug, "vpif_input_to_subdev\n");
+ if (!chan_cfg)
+ return -1;
+ if (input_index >= chan_cfg->input_count)
+ return -1;
subdev_name = chan_cfg->inputs[input_index].subdev_name;
if (subdev_name == NULL)
return -1;
@@ -658,7 +664,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info */
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = &vpif_cfg->subdev_info[i];
- if (!strcmp(subdev_info->name, subdev_name))
+ if (subdev_info && !strcmp(subdev_info->name, subdev_name))
return i;
}
return -1;
@@ -1328,6 +1334,21 @@ static int vpif_async_bound(struct v4l2_async_notifier *notifier,
{
int i;
+ for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
+ struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
+ const struct device_node *node = _asd->match.of.node;
+
+ if (node == subdev->of_node) {
+ vpif_obj.sd[i] = subdev;
+ vpif_obj.config->chan_config->inputs[i].subdev_name =
+ (char *)subdev->of_node->full_name;
+ vpif_dbg(2, debug,
+ "%s: setting input %d subdev_name = %s\n",
+ __func__, i, subdev->of_node->full_name);
+ return 0;
+ }
+ }
+
for (i = 0; i < vpif_obj.config->subdev_count; i++)
if (!strcmp(vpif_obj.config->subdev_info[i].name,
subdev->name)) {
@@ -1423,6 +1444,110 @@ static int vpif_async_complete(struct v4l2_async_notifier *notifier)
return vpif_probe_complete();
}
+static struct vpif_capture_config *
+vpif_capture_get_pdata(struct platform_device *pdev)
+{
+ struct device_node *endpoint = NULL;
+ struct v4l2_of_endpoint bus_cfg;
+ struct vpif_capture_config *pdata;
+ struct vpif_subdev_info *sdinfo;
+ struct vpif_capture_chan_config *chan;
+ unsigned int i;
+
+ dev_dbg(&pdev->dev, "vpif_get_pdata\n");
+
+ if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+ return pdev->dev.platform_data;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+ pdata->subdev_info =
+ devm_kzalloc(&pdev->dev, sizeof(*pdata->subdev_info) *
+ VPIF_CAPTURE_MAX_CHANNELS, GFP_KERNEL);
+
+ if (!pdata->subdev_info)
+ return NULL;
+ dev_dbg(&pdev->dev, "%s\n", __func__);
+
+ for (i = 0; ; i++) {
+ struct device_node *rem;
+ unsigned int flags;
+ int err;
+
+ endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+ endpoint);
+ if (!endpoint)
+ break;
+
+ sdinfo = &pdata->subdev_info[i];
+ chan = &pdata->chan_config[i];
+ chan->inputs = devm_kzalloc(&pdev->dev,
+ sizeof(*chan->inputs) *
+ VPIF_DISPLAY_MAX_CHANNELS,
+ GFP_KERNEL);
+
+ chan->input_count++;
+ chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
+ chan->inputs[i].input.std = V4L2_STD_ALL;
+ chan->inputs[i].input.capabilities = V4L2_IN_CAP_STD;
+
+ /* FIXME: need a new property? ch0:composite ch1: s-video */
+ if (i == 0)
+ chan->inputs[i].input_route = INPUT_CVBS_VI2B;
+ else
+ chan->inputs[i].input_route = INPUT_SVIDEO_VI2C_VI1C;
+ chan->inputs[i].output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC;
+
+ err = v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+ if (err) {
+ dev_err(&pdev->dev, "Could not parse the endpoint\n");
+ goto done;
+ }
+ dev_dbg(&pdev->dev, "Endpoint %s, bus_width = %d\n",
+ endpoint->full_name, bus_cfg.bus.parallel.bus_width);
+ flags = bus_cfg.bus.parallel.flags;
+
+ if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ chan->vpif_if.hd_pol = 1;
+
+ if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ chan->vpif_if.vd_pol = 1;
+
+ chan->vpif_if.if_type = VPIF_IF_BT656;
+ rem = of_graph_get_remote_port_parent(endpoint);
+ if (!rem) {
+ dev_dbg(&pdev->dev, "Remote device at %s not found\n",
+ endpoint->full_name);
+ goto done;
+ }
+
+ dev_dbg(&pdev->dev, "Remote device %s, %s found\n",
+ rem->name, rem->full_name);
+ sdinfo->name = rem->full_name;
+
+ pdata->asd[i] = devm_kzalloc(&pdev->dev,
+ sizeof(struct v4l2_async_subdev),
+ GFP_KERNEL);
+ if (!pdata->asd[i]) {
+ of_node_put(rem);
+ pdata = NULL;
+ goto done;
+ }
+
+ pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_OF;
+ pdata->asd[i]->match.of.node = rem;
+ of_node_put(rem);
+ }
+
+done:
+ pdata->asd_sizes[0] = i;
+ pdata->subdev_count = i;
+ pdata->card_name = "DA850/OMAP-L138 Video Capture";
+
+ return pdata;
+}
+
/**
* vpif_probe : This function probes the vpif capture driver
* @pdev: platform device pointer
@@ -1439,6 +1564,7 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ pdev->dev.platform_data = vpif_capture_get_pdata(pdev);
if (!pdev->dev.platform_data) {
dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
return -EINVAL;
@@ -1481,7 +1607,7 @@ static __init int vpif_probe(struct platform_device *pdev)
goto vpif_unregister;
}
- if (!vpif_obj.config->asd_sizes) {
+ if (!vpif_obj.config->asd_sizes[0]) {
i2c_adap = i2c_get_adapter(1);
for (i = 0; i < subdev_count; i++) {
subdevdata = &vpif_obj.config->subdev_info[i];
diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4ee3b41975db 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -65,14 +65,14 @@ struct vpif_display_config {
struct vpif_input {
struct v4l2_input input;
- const char *subdev_name;
+ char *subdev_name;
u32 input_route;
u32 output_route;
};
struct vpif_capture_chan_config {
struct vpif_interface vpif_if;
- const struct vpif_input *inputs;
+ struct vpif_input *inputs;
int input_count;
};
@@ -83,7 +83,8 @@ struct vpif_capture_config {
struct vpif_subdev_info *subdev_info;
int subdev_count;
const char *card_name;
- struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
- int *asd_sizes; /* 0-terminated array of asd group sizes */
+
+ struct v4l2_async_subdev *asd[VPIF_CAPTURE_MAX_CHANNELS];
+ int asd_sizes[VPIF_CAPTURE_MAX_CHANNELS];
};
#endif /* _VPIF_TYPES_H */
--
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
* [PATCH 2/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-11-19 0:32 UTC (permalink / raw)
To: linux-media, Hans Verkuil
Cc: devicetree, Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
Alexandre Bailon, David Lechner
In-Reply-To: <20161119003208.10550-1-khilman@baylibre.com>
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 79cef74e164f..becc3e63b472 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -193,12 +193,16 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
}
}
+ spin_unlock_irqrestore(&common->irqlock, flags);
+
ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
vpif_dbg(1, debug, "stream on failed in subdev\n");
goto err;
}
+ spin_lock_irqsave(&common->irqlock, flags);
+
/* Call vpif_set_params function to set the parameters and addresses */
ret = vpif_set_video_params(vpif, ch->channel_id);
if (ret < 0) {
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] [media] davinci: add support for DT init
From: Kevin Hilman @ 2016-11-19 0:32 UTC (permalink / raw)
To: linux-media, Hans Verkuil
Cc: devicetree, Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
Alexandre Bailon, David Lechner
Add basic support for initialization via DT.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 9 +++++++++
drivers/media/platform/davinci/vpif_capture.c | 14 ++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index 0380cf2e5775..077e328e0281 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -464,8 +464,17 @@ static const struct dev_pm_ops vpif_pm = {
#define vpif_pm_ops NULL
#endif
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+ { .compatible = "ti,vpif", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
static struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_of_match),
.name = "vpif",
.pm = vpif_pm_ops,
},
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 5104cc0ee40e..79cef74e164f 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1435,6 +1435,11 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
@@ -1618,8 +1623,17 @@ static int vpif_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(vpif_pm_ops, vpif_suspend, vpif_resume);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_capture_of_match[] = {
+ { .compatible = "ti,vpif-capture", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_capture_of_match);
+#endif
+
static __refdata struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_capture_of_match),
.name = VPIF_DRIVER_NAME,
.pm = &vpif_pm_ops,
},
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 3/3] ARM64: dts: meson-gxbb: add the USB reset also to the second USB PHY
From: Martin Blumenstingl @ 2016-11-18 22:35 UTC (permalink / raw)
To: Kevin Hilman
Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
carlo-KA+7E9HrN00dnm+yROfE0A, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <m2twb7w1j6.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Kevin,
On Wed, Nov 16, 2016 at 10:35 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
>> When the USB PHY driver was introduced the reset framework did not
>> have support for triggering a reset pulse for shared resets. On GXBB
>> however there is only one reset line for both PHYs (meaning we have a
>> shared reset line). With the latest changes to the reset framework and
>> the corresponding updates to the phy-meson8b-usb2 driver we can now pass
>> the reset to the second PHY as well.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> Applied.
Unfortunately I think I put crucial information only in the
cover-letter's description:
"the dts patch has a runtime-dependency on patch 1 and 2"
So please feel free to keep or drop the patch as it is. In case you
decide drop it I will re-send it for 4.11 (after all the 4.10 stuff is
done).
--
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 v3 4/5] i2c: designware: Add slave mode as separated driver
From: kbuild test robot @ 2016-11-18 22:27 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <36abadc931ab0814019c9b2214886bcb4e4ce5c1.1479410047.git.lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6345 bytes --]
Hi Luis,
[auto build test ERROR on v4.9-rc5]
[also build test ERROR on next-20161117]
[cannot apply to wsa/i2c/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Luis-Oliveira/i2c-designware-Add-slave-support/20161118-193236
config: x86_64-randconfig-s4-11190538 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/i2c/busses/i2c-designware-slave.c: In function 'i2c_dw_irq_handler_slave':
>> drivers/i2c/busses/i2c-designware-slave.c:295:3: error: implicit declaration of function 'i2c_slave_event' [-Werror=implicit-function-declaration]
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:295:31: error: 'I2C_SLAVE_WRITE_REQUESTED' undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/i2c/busses/i2c-designware-slave.c:295:31: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/i2c/busses/i2c-designware-slave.c:302:6: error: 'I2C_SLAVE_WRITE_RECEIVED' undeclared (first use in this function)
I2C_SLAVE_WRITE_RECEIVED, &val)) {
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:314:7: error: 'I2C_SLAVE_READ_REQUESTED' undeclared (first use in this function)
I2C_SLAVE_READ_REQUESTED, &val))
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:320:36: error: 'I2C_SLAVE_READ_PROCESSED' undeclared (first use in this function)
if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:324:31: error: 'I2C_SLAVE_STOP' undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
^~~~~~~~~~~~~~
drivers/i2c/busses/i2c-designware-slave.c: At top level:
>> drivers/i2c/busses/i2c-designware-slave.c:370:2: error: unknown field 'reg_slave' specified in initializer
.reg_slave = i2c_dw_reg_slave,
^
>> drivers/i2c/busses/i2c-designware-slave.c:370:15: warning: excess elements in struct initializer
.reg_slave = i2c_dw_reg_slave,
^~~~~~~~~~~~~~~~
drivers/i2c/busses/i2c-designware-slave.c:370:15: note: (near initialization for 'i2c_dw_algo')
>> drivers/i2c/busses/i2c-designware-slave.c:371:2: error: unknown field 'unreg_slave' specified in initializer
.unreg_slave = i2c_dw_unreg_slave,
^
drivers/i2c/busses/i2c-designware-slave.c:371:17: warning: excess elements in struct initializer
.unreg_slave = i2c_dw_unreg_slave,
^~~~~~~~~~~~~~~~~~
drivers/i2c/busses/i2c-designware-slave.c:371:17: note: (near initialization for 'i2c_dw_algo')
cc1: some warnings being treated as errors
vim +/i2c_slave_event +295 drivers/i2c/busses/i2c-designware-slave.c
289 dw_readl(dev, DW_IC_CLR_START_DET);
290 if (stat & DW_IC_INTR_ACTIVITY)
291 dw_readl(dev, DW_IC_CLR_ACTIVITY);
292 if (stat & DW_IC_INTR_RX_OVER)
293 dw_readl(dev, DW_IC_CLR_RX_OVER);
294 if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))
> 295 i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
296
297 if (slave_activity) {
298 if (stat & DW_IC_INTR_RD_REQ) {
299 if (stat & DW_IC_INTR_RX_FULL) {
300 val = dw_readl(dev, DW_IC_DATA_CMD);
301 if (!i2c_slave_event(dev->slave,
> 302 I2C_SLAVE_WRITE_RECEIVED, &val)) {
303 dev_dbg(dev->dev, "Byte %X acked! ",
304 val);
305 }
306 dw_readl(dev, DW_IC_CLR_RD_REQ);
307 stat = i2c_dw_read_clear_intrbits_slave(dev);
308 } else {
309 dw_readl(dev, DW_IC_CLR_RD_REQ);
310 dw_readl(dev, DW_IC_CLR_RX_UNDER);
311 stat = i2c_dw_read_clear_intrbits_slave(dev);
312 }
313 if (!i2c_slave_event(dev->slave,
> 314 I2C_SLAVE_READ_REQUESTED, &val))
315 dw_writel(dev, val, DW_IC_DATA_CMD);
316 }
317 }
318
319 if (stat & DW_IC_INTR_RX_DONE) {
> 320 if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
321 &val))
322 dw_readl(dev, DW_IC_CLR_RX_DONE);
323
> 324 i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
325 stat = i2c_dw_read_clear_intrbits_slave(dev);
326 return true;
327 }
328
329 if (stat & DW_IC_INTR_RX_FULL) {
330 val = dw_readl(dev, DW_IC_DATA_CMD);
331 if (!i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED,
332 &val))
333 dev_dbg(dev->dev, "Byte %X acked! ", val);
334 } else {
335 i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
336 stat = i2c_dw_read_clear_intrbits_slave(dev);
337 }
338
339 if (stat & DW_IC_INTR_TX_OVER) {
340 dw_readl(dev, DW_IC_CLR_TX_OVER);
341 return true;
342 }
343 return true;
344 }
345
346 static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id)
347 {
348 struct dw_i2c_dev *dev = dev_id;
349 u32 stat, enabled, mode;
350
351 enabled = dw_readl(dev, DW_IC_ENABLE);
352 mode = dw_readl(dev, DW_IC_CON);
353 stat = dw_readl(dev, DW_IC_RAW_INTR_STAT);
354
355 dev_dbg(dev->dev, "%s: enabled=%#x stat=%#x\n", __func__, enabled,
356 stat);
357 if (!enabled || !(stat & ~DW_IC_INTR_ACTIVITY))
358 return IRQ_NONE;
359
360 stat = i2c_dw_read_clear_intrbits_slave(dev);
361 if (!i2c_dw_irq_handler_slave(dev))
362 return IRQ_NONE;
363
364 complete(&dev->cmd_complete);
365 return IRQ_HANDLED;
366 }
367
368 static struct i2c_algorithm i2c_dw_algo = {
369 .functionality = i2c_dw_func,
> 370 .reg_slave = i2c_dw_reg_slave,
> 371 .unreg_slave = i2c_dw_unreg_slave,
372 };
373
374 void i2c_dw_disable_slave(struct dw_i2c_dev *dev)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25799 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 21:54 UTC (permalink / raw)
To: Rob Herring, Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAL_JsqJv7bBmkWUmd44Ln-=PLLKEch+hbjuD8v8ArhOCZ37jdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/18/2016 12:03 PM, Rob Herring wrote:
>
> Sorry, didn't send anything out, but the series is already applied if
> you look at -next or PW.
>
Thanks!
Dinh
--
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: [v3,2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-18 21:33 UTC (permalink / raw)
To: Christopher Spinrath, dri-devel, devicetree
Cc: khilman, tomi.valkeinen, laurent.pinchart, bcousson, bgolaszewski
In-Reply-To: <09499db556b444f9aa88aadf0cae4f2d@rwthex-s1-b.rwth-ad.de>
On 11/18/16 07:00, Christopher Spinrath wrote:
> Hi Jyri,
>
> On 11/17/2016 02:28 PM, Jyri Sarha wrote:
>> Add very basic ti-ftp410 DVI transmitter driver. The only feature
>
> s/ftp/tfp ?
>
My fingers just want type these three letter is that order, wonder why :).
>> separating this from a completely dummy bridge is the EDID read
>> support trough DDC I2C. Even that functionality should be in a
>> separate generic connector driver. However, because of missing DRM
>> infrastructure support the connector is implemented within the bridge
>> driver. Some tfp410 HW specific features may be added later if needed,
>> because there is a set of registers behind i2c if it is connected.
>>
>> This implementation is tested against my new tilcdc bridge support
>> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
>> is also added.
>>
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>
> Thanks for working on this. I have tested the driver on my Utilite Pro
> which is based on the imx6q SoC and has a tfp410 chip hooked up to its
> parallel rgb24 interface. So you can add my
>
> Tested-By: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
Thanks, I'll address these comments and resend the corrected patches
before sending a pull request.
> However, I have two more comments below.
>
>> ---
>> .../bindings/display/bridge/ti,tfp410.txt | 40 +++
>> drivers/gpu/drm/bridge/Kconfig | 7 +
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> drivers/gpu/drm/bridge/ti-tfp410.c | 287 +++++++++++++++++++++
>> 4 files changed, 335 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>> new file mode 100644
>> index 0000000..6174b18
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>
> There already is a binding documentation for the tfp410 in
>
> Documentation/devicetree/bindings/display/ti/ti,tfp410.txt .
>
> It is used by the omap drm driver. IMHO you should extend, move or
> deprecate that one. Note that it describes an optional powerdown-gpios
> property.
>
Good that you noticed that. Guess we need to unify those. Probably to
the new location under bridge directory.
>> @@ -0,0 +1,40 @@
>> +TFP410 DVI bridge bindings
>> +
>> +Required properties:
>> + - compatible: "ti,tfp410"
>> +
>> +Optional properties
>> + - reg: I2C address. If and only if present the device node
>> + should be placed into the i2c controller node where the
>> + tfp410 i2c is connected to.
>> +
>> +Required subnodes:
>> + - port@0: Video input port node to connect the bridge to a
>> + display controller output [1].
>> + - port@1: Video output port node to connect the bridge to a
>> + connector input [1].
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> + hdmi-bridge {
>> + compatible = "ti,tfp410";
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + bridge_in: endpoint {
>> + remote-endpoint = <&dc_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + bridge_out: endpoint {
>> + remote-endpoint = <&hdmi_in>;
>> + };
>> + };
>> + };
>> + };
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index bd6acc8..a424e03 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
>> ---help---
>> Toshiba TC358767 eDP bridge chip driver.
>>
>> +config DRM_TI_TFP410
>> + tristate "TI TFP410 DVI/HDMI bridge"
>> + depends on OF
>> + select DRM_KMS_HELPER
>> + ---help---
>> + Texas Instruments TFP410 DVI/HDMI Transmitter driver
>> +
>> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>>
>> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>> index 97ed1a5..8b065d9 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
>> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>> +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
>> new file mode 100644
>> index 0000000..64f54e4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>> @@ -0,0 +1,287 @@
>> +/*
>> + * Copyright (C) 2016 Texas Instruments
>> + * Author: Jyri Sarha <jsarha@ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published by
>> + * the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/of_graph.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/i2c.h>
>> +
>> +#include <drm/drmP.h>
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +
>> +struct tfp410 {
>> + struct drm_bridge bridge;
>> + struct drm_connector connector;
>> +
>> + struct i2c_adapter *ddc;
>> +
>> + struct device *dev;
>> +};
>> +
>> +static inline struct tfp410 *
>> +drm_bridge_to_tfp410(struct drm_bridge *bridge)
>> +{
>> + return container_of(bridge, struct tfp410, bridge);
>> +}
>> +
>> +static inline struct tfp410 *
>> +drm_connector_to_tfp410(struct drm_connector *connector)
>> +{
>> + return container_of(connector, struct tfp410, connector);
>> +}
>> +
>> +static int tfp410_get_modes(struct drm_connector *connector)
>> +{
>> + struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>> + struct edid *edid;
>> + int ret;
>> +
>> + if (!dvi->ddc)
>> + goto fallback;
>> +
>> + edid = drm_get_edid(connector, dvi->ddc);
>> + if (!edid) {
>> + DRM_INFO("EDID read failed. Fallback to standard modes\n");
>> + goto fallback;
>> + }
>> +
>> + drm_mode_connector_update_edid_property(connector, edid);
>> +
>> + return drm_add_edid_modes(connector, edid);
>> +fallback:
>> + /* No EDID, fallback on the XGA standard modes */
>> + ret = drm_add_modes_noedid(connector, 1920, 1200);
>> +
>> + /* And prefer a mode pretty much anything can handle */
>> + drm_set_preferred_mode(connector, 1024, 768);
>> +
>> + return ret;
>> +}
>> +
>> +static const struct drm_connector_helper_funcs tfp410_con_helper_funcs = {
>> + .get_modes = tfp410_get_modes,
>> +};
>> +
>> +static enum drm_connector_status
>> +tfp410_connector_detect(struct drm_connector *connector, bool force)
>> +{
>> + struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>> +
>> + if (dvi->ddc) {
>> + if (drm_probe_ddc(dvi->ddc))
>> + return connector_status_connected;
>> + else
>> + return connector_status_disconnected;
>> + }
>
> I wonder what happens if a display with none or defect ddc/edid is
> attached? The dumb-vga-dac bridge driver reports
> connector_status_unknown in the case drm_probe_ddc fails.
>
If there is such a problem with DVI/HDMI device, then the device is
clearly broken. In such a case one can hack a custom dtd file without
ddc-i2c-bus. The situation with VGA is slightly different. There may
still be some perfectly legitimate legacy VGA devices that do not
support ddc.
I do not have a strong opinion about this, but would like to wait if
anybody is bothered about this behaviour and fix it only if there is a
problem.
> Cheers,
> Christopher
>
>> +
>> + return connector_status_unknown;
>> +}
>> +
>> +static const struct drm_connector_funcs tfp410_con_funcs = {
>> + .dpms = drm_atomic_helper_connector_dpms,
>> + .detect = tfp410_connector_detect,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .destroy = drm_connector_cleanup,
>> + .reset = drm_atomic_helper_connector_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +static int tfp410_attach(struct drm_bridge *bridge)
>> +{
>> + struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
>> + int ret;
>> +
>> + if (!bridge->encoder) {
>> + dev_err(dvi->dev, "Missing encoder\n");
>> + return -ENODEV;
>> + }
>> +
>> + drm_connector_helper_add(&dvi->connector,
>> + &tfp410_con_helper_funcs);
>> + ret = drm_connector_init(bridge->dev, &dvi->connector,
>> + &tfp410_con_funcs, DRM_MODE_CONNECTOR_HDMIA);
>> + if (ret) {
>> + dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + drm_mode_connector_attach_encoder(&dvi->connector,
>> + bridge->encoder);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>> + .attach = tfp410_attach,
>> +};
>> +
>> +static int tfp410_get_connector_ddc(struct tfp410 *dvi)
>> +{
>> + struct device_node *ep = NULL, *connector_node = NULL;
>> + struct device_node *ddc_phandle = NULL;
>> + int ret = 0;
>> +
>> + /* port@1 is the connector node */
>> + ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, -1);
>> + if (!ep)
>> + goto fail;
>> +
>> + connector_node = of_graph_get_remote_port_parent(ep);
>> + if (!connector_node)
>> + goto fail;
>> +
>> + ddc_phandle = of_parse_phandle(connector_node, "ddc-i2c-bus", 0);
>> + if (!ddc_phandle)
>> + goto fail;
>> +
>> + dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
>> + if (dvi->ddc)
>> + dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
>> + else
>> + ret = -EPROBE_DEFER;
>> +
>> +fail:
>> + of_node_put(ep);
>> + of_node_put(connector_node);
>> + of_node_put(ddc_phandle);
>> + return ret;
>> +}
>> +
>> +static int tfp410_init(struct device *dev)
>> +{
>> + struct tfp410 *dvi;
>> + int ret;
>> +
>> + if (!dev->of_node) {
>> + dev_err(dev, "device-tree data is missing\n");
>> + return -ENXIO;
>> + }
>> +
>> + dvi = devm_kzalloc(dev, sizeof(*dvi), GFP_KERNEL);
>> + if (!dvi)
>> + return -ENOMEM;
>> + dev_set_drvdata(dev, dvi);
>> +
>> + dvi->bridge.funcs = &tfp410_bridge_funcs;
>> + dvi->bridge.of_node = dev->of_node;
>> + dvi->dev = dev;
>> +
>> + ret = tfp410_get_connector_ddc(dvi);
>> + if (ret)
>> + goto fail;
>> +
>> + ret = drm_bridge_add(&dvi->bridge);
>> + if (ret) {
>> + dev_err(dev, "drm_bridge_add() failed: %d\n", ret);
>> + goto fail;
>> + }
>> +
>> + return 0;
>> +fail:
>> + i2c_put_adapter(dvi->ddc);
>> + return ret;
>> +}
>> +
>> +static int tfp410_fini(struct device *dev)
>> +{
>> + struct tfp410 *dvi = dev_get_drvdata(dev);
>> +
>> + drm_bridge_remove(&dvi->bridge);
>> +
>> + if (dvi->ddc)
>> + i2c_put_adapter(dvi->ddc);
>> +
>> + return 0;
>> +}
>> +
>> +static int tfp410_probe(struct platform_device *pdev)
>> +{
>> + return tfp410_init(&pdev->dev);
>> +}
>> +
>> +static int tfp410_remove(struct platform_device *pdev)
>> +{
>> + return tfp410_fini(&pdev->dev);
>> +}
>> +
>> +/* There is currently no i2c functionality. */
>> +static int tfp410_i2c_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + int reg;
>> +
>> + if (!client->dev.of_node ||
>> + of_property_read_u32(client->dev.of_node, "reg", ®)) {
>> + dev_err(&client->dev,
>> + "Can't get i2c reg property from device-tree\n");
>> + return -ENXIO;
>> + }
>> +
>> + return tfp410_init(&client->dev);
>> +}
>> +
>> +static int tfp410_i2c_remove(struct i2c_client *client)
>> +{
>> + return tfp410_fini(&client->dev);
>> +}
>> +
>> +static const struct of_device_id tfp410_match[] = {
>> + { .compatible = "ti,tfp410" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, tfp410_match);
>> +
>> +struct platform_driver tfp410_platform_driver = {
>> + .probe = tfp410_probe,
>> + .remove = tfp410_remove,
>> + .driver = {
>> + .name = "tfp410-bridge",
>> + .of_match_table = tfp410_match,
>> + },
>> +};
>> +
>> +static const struct i2c_device_id tfp410_i2c_ids[] = {
>> + { "tfp410", 0 },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, tfp410_i2c_ids);
>> +
>> +static struct i2c_driver tfp410_i2c_driver = {
>> + .driver = {
>> + .name = "tfp410",
>> + .of_match_table = of_match_ptr(tfp410_match),
>> + },
>> + .id_table = tfp410_i2c_ids,
>> + .probe = tfp410_i2c_probe,
>> + .remove = tfp410_i2c_remove,
>> +};
>> +
>> +static int __init tfp410_module_init(void)
>> +{
>> + i2c_add_driver(&tfp410_i2c_driver);
>> + platform_driver_register(&tfp410_platform_driver);
>> +
>> + return 0;
>> +}
>> +module_init(tfp410_module_init);
>> +
>> +static void __exit tfp410_module_exit(void)
>> +{
>> + i2c_del_driver(&tfp410_i2c_driver);
>> + platform_driver_unregister(&tfp410_platform_driver);
>> +}
>> +module_exit(tfp410_module_exit);
>> +
>> +MODULE_AUTHOR("Jyri Sarha <jsarha@ti.com>");
>> +MODULE_DESCRIPTION("TI TFP410 DVI bridge driver");
>> +MODULE_LICENSE("GPL");
>>
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-18 20:22 UTC (permalink / raw)
To: Sudeep Holla, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring
Cc: Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <075d4718-8cd2-e390-b755-bc24e7497eae-5wv7dgnIgG8@public.gmane.org>
On 11/18/16 02:41, Sudeep Holla wrote:
>
>
> On 17/11/16 21:00, Frank Rowand wrote:
>> On 11/17/16 07:32, Sudeep Holla wrote:
>>> Currently platforms/drivers needing to get the machine model name are
>>> replicating the same snippet of code. In some case, the OF reference
>>> counting is either missing or incorrect.
>>>
>>> This patch adds support to read the machine model name either using
>>> the "model" or the "compatible" property in the device tree root node
>>> to the core OF/DT code.
>>>
>>> This can be used to remove all the duplicate code snippets doing exactly
>>> same thing later.
>>
>> I find five instances of reading only property "model":
>>
>> arch/arm/mach-imx/cpu.c
>> arch/arm/mach-mxs/mach-mxs.c
>> arch/c6x/kernel/setup.c
>> arch/mips/cavium-octeon/setup.c
>> arch/sh/boards/of-generic.c
>>
>
> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
> that this will be used for.
I have not seen 2/2. I do not see it on the devicetree list or on lkml.
I did see a list of drivers in the RFC patch that you sent several hours
before this patch.
In that patch you replaced reading the model name from the _flat_ device
tree with the new function in at least one location. That is not
correct.
>
>> I find one instance of reading property "model", then if
>> that does not exist, property "compatible":
>>
>> arch/mips/generic/proc.c
>>
>
> Correct as you can check in patch 2/2
>
>> The proposed patch matches the code used in one place, and thus
>> current usage does not match the patch description.
>>
>
> Yes, but does it matter ? compatibles are somewhat informative about the
> model IMO.
Yes it does matter. That is just sloppy and makes devicetree yet harder
to understand. It hurts clarity. The new function name says get "model",
not get "model" or "first element of the compatible list".
And using the _first_ element only of the compatible list to determine
model is not a good paradigm. It is yet another hidden, special case,
undocumented trap to lure in the unwary.
It is extremely unlikely that the change actually changes behavior for an
existing device tree because there is probably no dts that does not
contain the model property but does contain the proper magic value in
the compatible property. But did you actually check for that?
>
>> Is my search bad? Are you planning to add additional instances
>> of reading "model" then "compatible"?
>>
>
> No, just replacing the existing ones as in patch 2/2
>
You also ignored Arnd's comment in reply to your RFC patch.
-Frank
--
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] mmc: pwrseq: add support for Marvell SD8787 chip
From: Tony Lindgren @ 2016-11-18 20:19 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Mark Rutland,
Srinivas Kandagatla
In-Reply-To: <1479434109-8745-1-git-send-email-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
* Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> [161117 17:55]:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
Good to see this happening:
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Christian Lamparter @ 2016-11-18 20:18 UTC (permalink / raw)
To: Rob Herring
Cc: Stefan Wahren, John Youn, Felipe Balbi,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Christian Lamparter
In-Reply-To: <20161118141608.r7jsu7pfc4ztjt33@rob-hp-laptop>
On Friday, November 18, 2016 8:16:08 AM CET Rob Herring wrote:
> On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
> > Hi John,
> >
> > Am 17.11.2016 um 00:47 schrieb John Youn:
> > > Add the "snps,ahb-burst" binding and read it in.
> > >
> > > This property controls which burst type to perform on the AHB bus as a
> > > master in internal DMA mode. This overrides the legacy param value,
> > > which we need to keep around for now since several platforms use it.
> > >
> > > Some platforms may see better or worse performance based on this
> > > value. The HAPS platform is one example where all INCRx have worse
> > > performance than INCR.
> > >
> > > Other platforms (such as the Canyonlands board) report that the default
> > > value causes system hangs.
> > >
> > > Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> > > Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > > ---
> > > Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
> > > drivers/usb/dwc2/core.h | 9 +++++
> > > drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
> > > 3 files changed, 67 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> > > index 6c7c2bce..9e7b4b4 100644
> > > --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> > > +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> >
> > according to Documentation/devicetree/bindings/submitting-patches.txt
> > this change should be a separate patch.
> >
> > > @@ -26,6 +26,8 @@ Optional properties:
> > > Refer to phy/phy-bindings.txt for generic phy consumer properties
> > > - dr_mode: shall be one of "host", "peripheral" and "otg"
> > > Refer to usb/generic.txt
> > > +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
> > > + "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
> >
> > This doesn't apply in case of the bcm2835. I would prefer this option is
> > ignored in that case with a dev_warn("snps,ahb-burst is not supported on
> > this platform").
>
> Also, perhaps you should allow that the compatible string can define the
> default.
>
I hoped you would say that :).
I've attached a patch (on top of John Youn changes) that does
just that for the amcc,dwc-otg. I put the GAHBCFG_HBSTLEN_INCR
value into the .data, if that's a problem, I can certainly
respin the patch and put it in a dedicated struct.
Regards
Christian
---
>From 4c31a029dde714828810b1c3e61a5b1412ac939a Mon Sep 17 00:00:00 2001
From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 18 Nov 2016 21:03:19 +0100
Subject: [PATCH] usb: dwc2: add a default ahb-burst setting for amcc,dwc-otg
This patch adds a of_device_id table which can be used by
existing devices to supply a ahb-burst value for the platform
without having to add a "snps,ahb-burst" entry to the dts.
Note: Adding new devices to this table is discouraged.
please consider adding the "snps,ahb-burst" property
with the correct configuration to your device tree
file instead.
Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/usb/dwc2/params.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index e0fc9aa..51be266 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1097,6 +1097,22 @@ static const char *const ahb_bursts[] = {
[GAHBCFG_HBSTLEN_INCR16] = "INCR16",
};
+/*
+ * This table provides AHB burst configuration for existing
+ * device tree bindings that work poorly with the default setting.
+ *
+ * Note: Adding new devices to this table is discouraged.
+ * please consider adding the "snps,ahb-burst" property
+ * with the correct configuration to your device tree
+ * file instead.
+ */
+static const struct of_device_id dwc2_compat_ahb_bursts[] = {
+ {
+ .compatible = "amcc,dwc-otg",
+ .data = (void *) GAHBCFG_HBSTLEN_INCR16,
+ },
+};
+
static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
{
struct device_node *node = hsotg->dev->of_node;
@@ -1107,6 +1123,12 @@ static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
ret = device_property_read_string(hsotg->dev,
"snps,ahb-burst", &str);
if (ret < 0) {
+ const struct of_device_id *match;
+
+ match = of_match_node(dwc2_compat_ahb_bursts, node);
+ if (match)
+ ret = (int)match->data;
+
return ret;
} else if (of_device_is_compatible(node, "brcm,bcm2835-usb")) {
dev_warn(hsotg->dev,
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH] arm64: dts: qcom: msm8996: Fixup smp2p node
From: Bjorn Andersson @ 2016-11-18 20:06 UTC (permalink / raw)
To: Andy Gross
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The SMEM state property name changes between the integration branch and
mainline, update to use the correct one.
Fixes: 2f45d9fcd531 ("arm64: dts: msm8996: Add SMP2P and APCS nodes")
Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Seems we're still carrying this discrepancy somewhere and I missed it in my
review, sorry about that.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index cde4114bae5a..712d5d043105 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -530,7 +530,7 @@
adsp_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
- #qcom,state-cells = <1>;
+ #qcom,smem-state-cells = <1>;
};
adsp_smp2p_in: slave-kernel {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-18 20:00 UTC (permalink / raw)
To: Rob Herring, Sudeep Holla
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118144651.275xz4gu6jaefhp7@rob-hp-laptop>
On 11/18/16 06:46, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
>> Currently platforms/drivers needing to get the machine model name are
>> replicating the same snippet of code. In some case, the OF reference
>> counting is either missing or incorrect.
>>
>> This patch adds support to read the machine model name either using
>> the "model" or the "compatible" property in the device tree root node
>> to the core OF/DT code.
>>
>> This can be used to remove all the duplicate code snippets doing exactly
>> same thing later.
>>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>> drivers/of/base.c | 32 ++++++++++++++++++++++++++++++++
>> include/linux/of.h | 6 ++++++
>> 2 files changed, 38 insertions(+)
>>
>> Hi Rob,
>>
>> It would be good if we can target this for v4.10, so that we have no
>> dependencies to push PATCH 2/2 in v4.11
>
> Applied.
>
> Rob
>
A little fast on the trigger Rob.
-Frank
--
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 v3 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Bjorn Andersson @ 2016-11-18 19:55 UTC (permalink / raw)
To: Sarangdhar Joshi
Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, linux-arm-msm, linux-soc,
devicetree, linux-arm-kernel, linux-kernel, Jordan Crouse,
Stephen Boyd, Trilok Soni
In-Reply-To: <1479259165-1601-2-git-send-email-spjoshi@codeaurora.org>
On Tue 15 Nov 17:19 PST 2016, Sarangdhar Joshi wrote:
> Add SCM DT bindings for Qualcomm's MSM8996 platform.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> index 3b4436e..20f26fb 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> @@ -10,8 +10,10 @@ Required properties:
> * "qcom,scm-apq8064" for APQ8064 platforms
> * "qcom,scm-msm8660" for MSM8660 platforms
> * "qcom,scm-msm8690" for MSM8690 platforms
> + * "qcom,scm-msm8996" for MSM8996 platforms
> * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
> - clocks: One to three clocks may be required based on compatible.
> + * No clock required for "qcom,scm-msm8996"
> * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
> * Core, iface, and bus clocks required for "qcom,scm"
> - clock-names: Must contain "core" for the core clock, "iface" for the interface
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH v3 2/2] DW DMAC: add multi-block property to device tree
From: Andy Shevchenko @ 2016-11-18 19:33 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479496356-27834-3-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> Several versions of DW DMAC have multi block transfers hardware
> support. Hardware support of multi block transfers is disabled
> by default if we use DT to configure DMAC and software emulation
> of multi block transfers used instead.
> Add multi-block property, so it is possible to enable hardware
> multi block transfers (if present) via DT.
>
> Switch from per device is_nollp variable to multi_block array
> to be able enable/disable multi block transfers separately per
> channel.
>
> Update DT documentation.
>
> Update existing platform data.
Kinda useless for commit message, but might go after --- delimiter.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 5 +++++
> drivers/tty/serial/8250/8250_lpss.c | 2 +-
> include/linux/platform_data/dma-dw.h | 4 ++--
> 5 files changed, 11 insertions(+), 4 deletions(-)
> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> @@ -27,6 +27,8 @@ Optional properties:
> that services interrupts for this device
> - is_private: The device channels should be marked as private and not
> for by the
> general purpose DMA channel allocator. False if not passed.
> +- multi-block: Multi block transfers supported by hardware per AHB
> master.
> + 0 (default): not supported, 1: supported.
>
> Example:
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index c2c0a61..f2a3d06 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
> (dwc_params >> DWC_PARAMS_MBLK_EN &
> 0x1) == 0;
> } else {
> dwc->block_size = pdata->block_size;
> - dwc->nollp = pdata->is_nollp;
> + dwc->nollp = pdata->multi_block[i];
You missed the point. You assign positive value to negative variable.
It's a bug. Have you tested this? How?
In case of positive property you have to update DTS. By the way, I'm
pretty sure that spare13xx boards has auto configuration enabled, though
it has to be checked with vendor (I assume you may have fast response
from them).
> }
> }
>
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
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 v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Marek Vasut @ 2016-11-18 19:28 UTC (permalink / raw)
To: Moritz Fischer, atull
Cc: Rob Herring, Joel Holdsworth, Geert Uytterhoeven, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <CAAtXAHcORUBHH-V98cK0CABtjXYB1afhLHb_2m-akn5tMcv5vQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/18/2016 08:17 PM, Moritz Fischer wrote:
> On Fri, Nov 18, 2016 at 10:56 AM, atull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org> wrote:
>> On Mon, 14 Nov 2016, Rob Herring wrote:
>>
>>> On Sun, Nov 06, 2016 at 07:49:21PM -0700, Joel Holdsworth wrote:
>>>> This adds documentation of the device tree bindings of the Lattice iCE40
>>>> FPGA driver for the FPGA manager framework.
>>>>
>>>> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
>>>> ---
>>>> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
>>>> 1 file changed, 21 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
>>>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>
>>
>> Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
> Acked-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
Acked-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
--
Best regards,
Marek Vasut
--
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 v3 1/2] DW DMAC: enable memory-to-memory transfers support
From: Andy Shevchenko @ 2016-11-18 19:27 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479496356-27834-2-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> All known devices, which use DT for configuration, support
> memory-to-memory transfers. So enable it by default, if we read
> configuration from DT.
>
> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
You missed the given tag(s).
> ---
> drivers/dma/dw/platform.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index 5bda0eb..aa7a5c1 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
> if (of_property_read_bool(np, "is_private"))
> pdata->is_private = true;
>
> + /*
> + * All known devices, which use DT for configuration, support
> + * memory-to-memory transfers. So enable it by default.
> + */
> + pdata->is_memcpy = true;
> +
> if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
> pdata->chan_allocation_order = (unsigned char)tmp;
>
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
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 v3 0/2] DW DMAC: update device tree
From: Andy Shevchenko @ 2016-11-18 19:26 UTC (permalink / raw)
To: Eugeniy Paltsev, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479496356-27834-1-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> It wasn't possible to enable some features like
> memory-to-memory transfers or multi block transfers via DT.
> It is fixed by these patches.
First of all, please, give time to reviewers to comment the patches.
Usually it should be at least 24h (for the series that has been sent
first time 1 week approximately).
>
> Changes for v3:
> * Update existing platform data.
> We don't need to update existing DTS because default logic
> wasn't change: we don't set "is_nollp" if we read
> configuration from DT before. And we don't set it now if
> "multi-block" property doesn't exist in DTS.
See my comments in the patches.
And do not send the updated version earlier than Monday, please.
>
> Changes for v2:
> * I thought about is_memcpy DT property: all known devices, which
> use DT for configuration, support memory-to-memory transfers.
> So we don't need to read it from DT. So enable it by default,
> if we read configuration from DT.
>
> * Use "multi-block" instead of "hw-llp" name to be more clear.
>
> * Move adding DT property and adding documentation for this
> property to one patch.
>
> Eugeniy Paltsev (2):
> DW DMAC: enable memory-to-memory transfers support
> DW DMAC: add multi-block property to device tree
>
> Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 11 +++++++++++
> drivers/tty/serial/8250/8250_lpss.c | 2 +-
> include/linux/platform_data/dma-dw.h | 4 ++--
> 5 files changed, 17 insertions(+), 4 deletions(-)
>
--
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] of: Add vendor prefix for Lattice Semiconductor
From: Moritz Fischer @ 2016-11-18 19:17 UTC (permalink / raw)
To: atull
Cc: Joel Holdsworth, Devicetree List, Linux Kernel Mailing List,
linux-spi
In-Reply-To: <alpine.DEB.2.20.1611181257340.3387@atull-VirtualBox2>
On Fri, Nov 18, 2016 at 10:59 AM, atull <atull@opensource.altera.com> wrote:
> On Sat, 29 Oct 2016, Joel Holdsworth wrote:
>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 1992aa9..d64a835 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -146,6 +146,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
>> kyo Kyocera Corporation
>> lacie LaCie
>> lantiq Lantiq Semiconductor
>> +lattice Lattice Semiconductor
>> lenovo Lenovo Group Ltd.
>> lg LG Corporation
>> linux Linux-specific binding
>> --
>> 2.7.4
>>
>>
>
> Acked-by: Alan Tull <atull@opensource.altera.com>
Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
^ permalink raw reply
* Re: [PATCH v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Moritz Fischer @ 2016-11-18 19:17 UTC (permalink / raw)
To: atull
Cc: Rob Herring, Joel Holdsworth, Geert Uytterhoeven, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut, Clifford Wolf
In-Reply-To: <alpine.DEB.2.20.1611181255120.3387@atull-VirtualBox2>
On Fri, Nov 18, 2016 at 10:56 AM, atull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org> wrote:
> On Mon, 14 Nov 2016, Rob Herring wrote:
>
>> On Sun, Nov 06, 2016 at 07:49:21PM -0700, Joel Holdsworth wrote:
>> > This adds documentation of the device tree bindings of the Lattice iCE40
>> > FPGA driver for the FPGA manager framework.
>> >
>> > Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
>> > ---
>> > .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
>> > 1 file changed, 21 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
>>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>
> Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Acked-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
--
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
* [PATCH v3 2/2] DW DMAC: add multi-block property to device tree
From: Eugeniy Paltsev @ 2016-11-18 19:12 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, vinod.koul, linux-kernel, robh+dt,
dmaengine, andriy.shevchenko, Eugeniy Paltsev
In-Reply-To: <1479496356-27834-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Update DT documentation.
Update existing platform data.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +++++
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 4 ++--
5 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..03d6d6d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,8 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- multi-block: Multi block transfers supported by hardware per AHB master.
+ 0 (default): not supported, 1: supported.
Example:
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..f2a3d06 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = pdata->multi_block[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index aa7a5c1..b262fd3 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -152,6 +152,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "multi-block", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->multi_block[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
diff --git a/drivers/tty/serial/8250/8250_lpss.c b/drivers/tty/serial/8250/8250_lpss.c
index f607946..58cbb30 100644
--- a/drivers/tty/serial/8250/8250_lpss.c
+++ b/drivers/tty/serial/8250/8250_lpss.c
@@ -157,12 +157,12 @@ static int byt_serial_setup(struct lpss8250 *lpss, struct uart_port *port)
static const struct dw_dma_platform_data qrk_serial_dma_pdata = {
.nr_channels = 2,
.is_private = true,
- .is_nollp = true,
.chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
.chan_priority = CHAN_PRIORITY_ASCENDING,
.block_size = 4095,
.nr_masters = 1,
.data_width = {4},
+ .multi_block = {0},
};
static void qrk_serial_setup_dma(struct lpss8250 *lpss, struct uart_port *port)
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..0773bb4 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @multi_block: Multi block transfers supported by hardware per AHB master.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR_MASTERS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH v3 1/2] DW DMAC: enable memory-to-memory transfers support
From: Eugeniy Paltsev @ 2016-11-18 19:12 UTC (permalink / raw)
To: devicetree
Cc: mark.rutland, linux-snps-arc, vinod.koul, linux-kernel, robh+dt,
dmaengine, andriy.shevchenko, Eugeniy Paltsev
In-Reply-To: <1479496356-27834-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
drivers/dma/dw/platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ /*
+ * All known devices, which use DT for configuration, support
+ * memory-to-memory transfers. So enable it by default.
+ */
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
^ permalink raw reply related
* [PATCH v3 0/2] DW DMAC: update device tree
From: Eugeniy Paltsev @ 2016-11-18 19:12 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eugeniy Paltsev
It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
Changes for v3:
* Update existing platform data.
We don't need to update existing DTS because default logic
wasn't change: we don't set "is_nollp" if we read
configuration from DT before. And we don't set it now if
"multi-block" property doesn't exist in DTS.
Changes for v2:
* I thought about is_memcpy DT property: all known devices, which
use DT for configuration, support memory-to-memory transfers.
So we don't need to read it from DT. So enable it by default,
if we read configuration from DT.
* Use "multi-block" instead of "hw-llp" name to be more clear.
* Move adding DT property and adding documentation for this
property to one patch.
Eugeniy Paltsev (2):
DW DMAC: enable memory-to-memory transfers support
DW DMAC: add multi-block property to device tree
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 11 +++++++++++
drivers/tty/serial/8250/8250_lpss.c | 2 +-
include/linux/platform_data/dma-dw.h | 4 ++--
5 files changed, 17 insertions(+), 4 deletions(-)
--
2.5.5
--
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
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