Re: [PATCH] drm/armada: replace the simple-framebuffer
On Mon, Jan 21, 2019 at 07:01:57AM +0100, Lubomir Rintel wrote:
> If there's a simple-framebuffer carried over from boot firmware, it's going
> to stop working once we setup the LCDC for use via DRM. Kick it off from
> the hardware.
Applied, thanks.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/armada/armada_drv.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index fa31589b4fc0..9fcf88c91758 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -100,6 +100,17 @@ static int armada_drm_bind(struct device *dev)
> return ret;
> }
>
> + /* Remove early framebuffers */
> + ret = drm_fb_helper_remove_conflicting_framebuffers(NULL,
> + "armada-drm-fb",
> + false);
> + if (ret) {
> + dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
> + __func__, ret);
> + kfree(priv);
> + return ret;
> + }
> +
> priv->drm.dev_private = priv;
>
> dev_set_drvdata(dev, >drm);
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
On Mon, Jan 21, 2019 at 05:58:50PM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 11:53 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> > > >
> > > > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel
> > > > > wrote:
> > > > > > The Marvell Armada DRM master device is a virtual device needed to
> > > > > > list all
> > > > > > nodes that comprise the graphics subsystem.
> > > > > >
> > > > > > Signed-off-by: Lubomir Rintel
> > > > > > ---
> > > > > > .../display/armada/marvell-armada-drm.txt | 24
> > > > > > +++
> > > > > > 1 file changed, 24 insertions(+)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > >
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > @@ -1,3 +1,27 @@
> > > > > > +Marvell Armada DRM master device
> > > > > > +
> > > > > > +
> > > > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > > > list all
> > > > > > +nodes that comprise the graphics subsystem.
> > > > > > +
> > > > > > +Required properties:
> > > > > > +
> > > > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > > > + "marvell,armada-display-subsystem"
> > > > > > + - ports: a list of phandles pointing to display interface ports
> > > > > > of CRTC
> > > > > > + devices
> > > > > > + - memory-region: phandle to a node describing memory to be used
> > > > > > for the
> > > > > > + framebuffer
> > > > > > +
> > > > > > +Example:
> > > > > > +
> > > > > > + display-subsystem {
> > > > > > + compatible = "marvell,dove-display-subsystem",
> > > > > > +"marvell,armada-display-subsystem";
> > > > > > + memory-region = <_reserved>;
> > > > > > + ports = <_port>;
> > > > >
> > > > > If there is only one device, you don't need this virtual node.
> > > >
> > > > By "one device" you mean one LCD controller (CRTC)?
> > >
> > > Yes.
> >
> > How does that work (as far as the Linux implementation) ? I can't see
> > a way that could work, while allowing the flexibility that Armada DRM
> > allows (two completely independent LCD controllers as two separate DRM
> > devices vs one DRM device containing both LCD controllers.)
> >
> > > > I suppose in the (single CRTC) example case, the display-subsystem node
> > > > used to associate it with the memory region reserved for allocating the
> > > > frame buffers from. Could that be done differently?
> > >
> > > Move memory-region to the LCD controller node.
> >
> > That doesn't work - it would appear in the wrong part of the driver.
>
> Why? You can fetch properties from other nodes.
>
> If you have 2 CRTCs, do you have 1 or 2 reserved memory regions? I'd
> think 2 with each one in the corresponding LCDC that uses them would
> be more flexible.
There would still be one reserved memory region, since it is shared
between both LCDCs.
> Or just get the data out of the /reserved-memory node directly. Surely
> it has a compatible that you can find it with.
I see that the DT reserved memory support has progressed since I wrote
the armada code to deal with it, and it's now possible to make use of
reserved memory via of_reserved_mem_lookup() rather than using the
RESERVEDMEM_OF_DECLARE() and so fort
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
On Mon, Jan 21, 2019 at 09:45:22PM +0100, Lubomir Rintel wrote:
> On Mon, 2019-01-21 at 17:53 +0000, Russell King - ARM Linux admin
> wrote:
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> > > > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel
> > > > > wrote:
> > > > > > The Marvell Armada DRM master device is a virtual device needed to
> > > > > > list all
> > > > > > nodes that comprise the graphics subsystem.
> > > > > >
> > > > > > Signed-off-by: Lubomir Rintel
> > > > > > ---
> > > > > > .../display/armada/marvell-armada-drm.txt | 24
> > > > > > +++
> > > > > > 1 file changed, 24 insertions(+)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > >
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > @@ -1,3 +1,27 @@
> > > > > > +Marvell Armada DRM master device
> > > > > > +
> > > > > > +
> > > > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > > > list all
> > > > > > +nodes that comprise the graphics subsystem.
> > > > > > +
> > > > > > +Required properties:
> > > > > > +
> > > > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > > > + "marvell,armada-display-subsystem"
> > > > > > + - ports: a list of phandles pointing to display interface ports
> > > > > > of CRTC
> > > > > > + devices
> > > > > > + - memory-region: phandle to a node describing memory to be used
> > > > > > for the
> > > > > > + framebuffer
> > > > > > +
> > > > > > +Example:
> > > > > > +
> > > > > > + display-subsystem {
> > > > > > + compatible = "marvell,dove-display-subsystem",
> > > > > > +"marvell,armada-display-subsystem";
> > > > > > + memory-region = <_reserved>;
> > > > > > + ports = <_port>;
> > > > >
> > > > > If there is only one device, you don't need this virtual node.
> > > >
> > > > By "one device" you mean one LCD controller (CRTC)?
> > >
> > > Yes.
> >
> > How does that work (as far as the Linux implementation) ? I can't see
> > a way that could work, while allowing the flexibility that Armada DRM
> > allows (two completely independent LCD controllers as two separate DRM
> > devices vs one DRM device containing both LCD controllers.)
> >
> > > > I suppose in the (single CRTC) example case, the display-subsystem node
> > > > used to associate it with the memory region reserved for allocating the
> > > > frame buffers from. Could that be done differently?
> > >
> > > Move memory-region to the LCD controller node.
> >
> > That doesn't work - it would appear in the wrong part of the driver.
> >
> > > > Also, if the node is indeed made optional, then it's going to
> > > > complicate things on the DRM side. Currently the driver that binds to
> > > > the node creates the DRM device once it sees all the components
> > > > connected to the ports appear. If we loose it, then the LCD controller
> > > > driver would somehow need to find out that it's alone and create the
> > > > DRM device itself.
> > >
> > > DT is not the only way to create devices. The DRM driver can bind to
> > > the LCDC node and then create a child CRTC device (or even multiple
> > > ones for h/w with multiple pipelines).
&
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> >
> > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel wrote:
> > > > The Marvell Armada DRM master device is a virtual device needed to list
> > > > all
> > > > nodes that comprise the graphics subsystem.
> > > >
> > > > Signed-off-by: Lubomir Rintel
> > > > ---
> > > > .../display/armada/marvell-armada-drm.txt | 24 +++
> > > > 1 file changed, 24 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > >
> > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > @@ -1,3 +1,27 @@
> > > > +Marvell Armada DRM master device
> > > > +
> > > > +
> > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > list all
> > > > +nodes that comprise the graphics subsystem.
> > > > +
> > > > +Required properties:
> > > > +
> > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > + "marvell,armada-display-subsystem"
> > > > + - ports: a list of phandles pointing to display interface ports of
> > > > CRTC
> > > > + devices
> > > > + - memory-region: phandle to a node describing memory to be used for
> > > > the
> > > > + framebuffer
> > > > +
> > > > +Example:
> > > > +
> > > > + display-subsystem {
> > > > + compatible = "marvell,dove-display-subsystem",
> > > > +"marvell,armada-display-subsystem";
> > > > + memory-region = <_reserved>;
> > > > + ports = <_port>;
> > >
> > > If there is only one device, you don't need this virtual node.
> >
> > By "one device" you mean one LCD controller (CRTC)?
>
> Yes.
How does that work (as far as the Linux implementation) ? I can't see
a way that could work, while allowing the flexibility that Armada DRM
allows (two completely independent LCD controllers as two separate DRM
devices vs one DRM device containing both LCD controllers.)
> > I suppose in the (single CRTC) example case, the display-subsystem node
> > used to associate it with the memory region reserved for allocating the
> > frame buffers from. Could that be done differently?
>
> Move memory-region to the LCD controller node.
That doesn't work - it would appear in the wrong part of the driver.
> > Also, if the node is indeed made optional, then it's going to
> > complicate things on the DRM side. Currently the driver that binds to
> > the node creates the DRM device once it sees all the components
> > connected to the ports appear. If we loose it, then the LCD controller
> > driver would somehow need to find out that it's alone and create the
> > DRM device itself.
>
> DT is not the only way to create devices. The DRM driver can bind to
> the LCDC node and then create a child CRTC device (or even multiple
> ones for h/w with multiple pipelines).
That seems completely upside down and rediculous to me - are you
really suggesting that we should have some kind of virtual device
in DT, and omit the _real_ physical devices for that, having the
driver create the device with all the appropriate SoC resources?
> You'll also notice that there are only 3 cases of this virtual node in
> the tree: STi, i.MX IPU, and Rockchip. That's because we've deprecated
> doing these virtual nodes for some time now. IOW, there are several
> examples of how to do this without a virtual node.
This driver has been in-tree with this setup for some time, although
the documentation has been missing (we actually have a _lot_ of
instances of that.) However, we have no in-tree DT using it.
I don't really see how to satisfy your comments without totally
restructuring the driver, which is going to be quite a big chunk
of work. I'm not sure I have the motivation to do that right now.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Armada DRM: bridge with componentized devices
On Tue, Jan 15, 2019 at 11:47:00PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] driver core: Fix adding device links to probing suppliers > > Currently, it is not valid to add a device link from a consumer > driver ->probe() callback to a supplier that is still probing too, but > generally this is a valid use case. For example, if the consumer has > just acquired a resource that can only be available when the supplier > is functional, adding a device link to that supplier right away > should be safe (and even desirable arguably), but device_link_add() > doesn't handle that case correctly and the initial state of the link > created by it is wrong then. > > To address this problem, change the initial state of device links > added between a probing supplier and a probing consumer to > DL_STATE_CONSUMER_PROBE and update device_links_driver_bound() to > skip such links on the supplier side. > > With this change, if the supplier probe completes first, > device_links_driver_bound() called for it will skip the link state > update and when it is called for the consumer, the link state will > be updated to "active". In turn, if the consumer probe completes > first, device_links_driver_bound() called for it will change the > state of the link to "active" and when it is called for the > supplier, the link status update will be skipped. > > However, in principle the supplier or consumer probe may still fail > after the link has been added, so modify device_links_no_driver() to > change device links in the "active" or "consumer probe" state to > "dormant" on the supplier side and update __device_links_no_driver() > to change the link state to "available" only if it is "consumer > probe" or "active". > > Then, if the supplier probe fails first, the leftover link to the > probing consumer will become "dormant" and device_links_no_driver() > called for the consumer (when its probe fails) will clean it up. > In turn, if the consumer probe fails first, it will either drop the > link, or change its state to "available" and, in the latter case, > when device_links_no_driver() is called for the supplier, it will > update the link state to "dormant". [If the supplier probe fails, > but the consumer probe succeeds, which should not happen as long as > the consumer driver is correct, the link still will be around, but > it will be "dormant" until the supplier is probed again.] > > Signed-off-by: Rafael J. Wysocki Hi Rafael, I've tried this with Armada DRM without using the component helper for bridges, and it seems to work up to a point (I have a vga bridge here to allow further testing): [2.323441] armada-drm display-subsystem: assigned reserved memory node framebuffer [2.332001] armada-drm display-subsystem: bound f182.lcd-controller (ops armada_lcd_ops) [2.340790] armada-drm display-subsystem: bound f181.lcd-controller (ops armada_lcd_ops) [2.349345] armada-drm display-subsystem: node=/i2c-mux/i2c@0/hdmi-encoder@70 [2.356719] armada-drm display-subsystem: panel=fdfb bridge= (null) ret=0 [2.364038] armada-drm display-subsystem: Linked as a consumer to 1-0070 [2.370818] armada-drm display-subsystem: bridge=ee8cda2c ret=0 [2.376894] armada-drm display-subsystem: node=/vga-bridge [2.382453] armada-drm display-subsystem: panel=fdfb bridge=(null) ret=0 [2.389762] armada-drm display-subsystem: Linked as a consumer to vga-bridge [2.396883] armada-drm display-subsystem: bridge=ef3bec40 ret=0 When I remove the HDMI encoder: root@cubox:/sys/bus/i2c/drivers/tda998x# echo 1-0070 > unbind then I get: [ 1013.824860] Console: switching to colour dummy device 80x30 [ 1013.866785] armada-drm display-subsystem: Dropping the link to vga-bridge [ 1013.867126] armada-drm display-subsystem: Dropping the link to 1-0070 which looks like it did what was expected - the DRM device is indeed unbound, the nodes in /dev/dri are gone. When rebinding the HDMI encoder: [ 1015.864703] tda998x 1-0070: found TDA19988 [ 1015.898078] tda9950 1-0034: TDA9950 CEC interface, hardware version 3.3 [ 1015.941374] Registered IR keymap rc-cec [ 1015.941684] rc rc0: tda9950 as /devices/platform/mbus/mbus:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-0070/rc/rc0 [ 1015.942439] input: tda9950 as /devices/platform/mbus/mbus:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-0070/rc/rc0/input2 [ 1016.982921] alloc_contig_range: [10390, 10490) PFNs busy [ 1016.987400] kirkwood-spdif-audio audio-subsystem: snd-soc-dummy-dai <-> kirkwood-fe mapping ok [ 1016.987591] kirkwood-spdif-audio audio-subsystem: multicodec <-> kirkwood-spdif mapping ok but the DRM stuff doesn't come back - this is what Daniel was talking about further down this thread. I guess the kernel can't know that it should come back because the device links were dropped at the unbind stage, which means the kernel has lost the information necessary to know that the display subsystem is dependent on the
Re: [RFC 00/16] Armada DRM support for OLPC XO-1.75 laptop
On Thu, Jan 17, 2019 at 04:03:45PM +0100, Lubomir Rintel wrote: > On Thu, 2019-01-17 at 10:55 +0000, Russell King - ARM Linux admin > wrote: > > On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote: > > > here are patches that make the Armada DRM work on an OLPC XO-1.75. > > > They build on patches previously submitted by Russel King (included here > > > for > > > completeness as well). > > > > Hi, > > > > Would it be possible for you to re-post patches 1 through 6 to include > > the DT maintainers so that they can review those patches (as is > > required for their acceptance) - once they have done that, I can pick > > them up and resubmit some of the patches I have queued. > > Yes. Before I do so, I'd like to know your opinion about the compatible > strings of the framebuffer and display-subsystem nodes. > > In the "[RFC 05/16] dt-bindings: display: armada: Add mmp2 compatible > strings" message [1] I wrote: > > Note that perhaps "marvell,armada-display-subsystem" and > > "marvell,armada-framebuffer" would be a good idea in addition of > > dove/mmp2 specific strings since (at least for now) the driver code > > is the same. > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-December/201016.html > > I essentially documented what you implemented, but I'd prefer if you > used the "marvell,armada-display-subsystem" and > "marvell,armada-framebuffer" compatible strings in the driver code > instead. Things in DT tend to be named by the first user who comes along - so we often get DT compatibles that refer to the first device. However, we do currently have the opportunity to change it, so please do as you suggest. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 14/16] drm/armada: optionally enable the AXI clock
On Tue, Dec 18, 2018 at 04:37:40PM +0100, Lubomir Rintel wrote:
> It needs to be enabled (at least on MMP2) in order for the register
> writes to LCDC to work.
Dove also has an AXI clock input to the LCDC, but it isn't clear
whether that is necessary for register access or not. From a quick
search of the documentation, there doesn't appear to be an enable bit
for the AXI clock. Unfortunately, the documentation of clocks on Dove
is not very good.
However, Dove LCDCs can have four clock inputs for the pixel clock -
AXI, PLL and two external clock inputs. It isn't clear what this AXI
clock is, and whether it's the same clock used for register access.
Can you check whether the AXI clock used for the pixel clock is the
same as the AXI bus clock for MMP2 and document that please?
Thanks.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/armada/armada_crtc.c | 7 +++
> drivers/gpu/drm/armada/armada_crtc.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 5400fb925bcd..973c377975a1 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -679,6 +679,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
>
> of_node_put(dcrtc->crtc.port);
>
> + clk_disable_unprepare(dcrtc->axiclk);
> kfree(dcrtc);
> }
>
> @@ -748,6 +749,11 @@ static int armada_drm_crtc_create(struct drm_device
> *drm, struct device *dev,
> dcrtc->clk = ERR_PTR(-EINVAL);
> dcrtc->spu_iopad_ctrl = CFG_VSCALE_LN_EN | CFG_IOPAD_DUMB24;
>
> + dcrtc->axiclk = devm_clk_get(dev, "axiclk");
> + if (IS_ERR(dcrtc->axiclk))
> + dcrtc->axiclk = NULL;
> + WARN_ON(clk_prepare_enable(dcrtc->axiclk));
> +
> endpoint = of_get_next_child(port, NULL);
> of_property_read_u32(endpoint, "bus-width", _width);
> of_node_put(endpoint);
> @@ -829,6 +835,7 @@ static int armada_drm_crtc_create(struct drm_device *drm,
> struct device *dev,
> err_crtc_init:
> primary->funcs->destroy(primary);
> err_crtc:
> + clk_disable_unprepare(dcrtc->axiclk);
> kfree(dcrtc);
>
> return ret;
> diff --git a/drivers/gpu/drm/armada/armada_crtc.h
> b/drivers/gpu/drm/armada/armada_crtc.h
> index 7ebd337b60af..b07faea7257d 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.h
> +++ b/drivers/gpu/drm/armada/armada_crtc.h
> @@ -39,6 +39,7 @@ struct armada_crtc {
> const struct armada_variant *variant;
> unsignednum;
> void __iomem*base;
> + struct clk *axiclk;
> struct clk *clk;
> struct clk *extclk[2];
> struct {
> --
> 2.19.1
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 00/16] Armada DRM support for OLPC XO-1.75 laptop
On Tue, Dec 18, 2018 at 04:37:26PM +0100, Lubomir Rintel wrote: > here are patches that make the Armada DRM work on an OLPC XO-1.75. > They build on patches previously submitted by Russel King (included here for > completeness as well). Hi, Would it be possible for you to re-post patches 1 through 6 to include the DT maintainers so that they can review those patches (as is required for their acceptance) - once they have done that, I can pick them up and resubmit some of the patches I have queued. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
