* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
From: Tomi Valkeinen @ 2013-12-12 7:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <10507960.9DXH4TSv2E@avalon>
[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]
On 2013-12-12 01:56, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
>> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
>>> To avoid the need for a "nickname" property for each display, change
>>> the display registration so that the display's alias (i.e. "display0"
>>> etc) will be used for the dssdev->name if the display driver didn't
>>> provide a name.
>>>
>>> This means that when booting with board files, we will have more
>>> descriptive names for displays, like "lcd1", "hdmi".
>>
>> Where are those names used ? Are they reported to userspace, or limited to
>> kernel internal use only ?
They are visible via omapdss's sysfs, when using omapfb. They are used
for debug prints and by the user for selecting the default display and
display modes via kernel cmdline, and when he sets the video pipeline
routing. So changing them could be considered breaking the API, but...
With omapdrm the sysfs files do not exist, and I think omapdrm doesn't
use them (except maybe for some debug prints).
>>> With DT we'll only have "display0", etc. But as there are no "nicknames"
>>> for things like serials ports either, I hope we will do fine with this
>>
>> Just a random thought, maybe the aliases node could help here.
>
> I should have read the next patches before replying, sorry :-)
>
>> I'm not sure what rules govern its usage. Adding labels to display DT nodes
>> could be an option too.
Using of_alias_get_id() means that the alias is in the form "nameX"
where X is a number.
> A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Tomi Valkeinen @ 2013-12-12 7:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <2199639.FbGhznOLP9@avalon>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On 2013-12-12 01:10, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>
> Is this a temporary solution that you plan to later replace with DT-only
> device instantiation ?
It's a long term task to remove the "virtual" omapdss device. Removing
the platform data that we pass has been very difficult.
For example, we need to get the OMAP revision to know which OMAP DSS
hardware we have. We can't get that information from the DSS hardware
(thank you, HW designers! ;).
Another is DSI pin muxing. I think we need a new pinmuxing driver for
that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
very simple, but the register fields are varying lengths and at varying
positions, so pinmux-single doesn't work for it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Laurent Pinchart @ 2013-12-12 0:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <1386160133-24026-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> Hi,
>
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
> the previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style
> port/endpoint style in the DT data.
That's great, and I fully support that. This also calls for refactoring the
V4L2 DT bindings and support code to share them with display devices. A
bikeshedding question is where to put the common code.
> However, note that even if the DT data contains proper port & endpoint data,
> the drivers only use the first endpoint. This is to simplify the patches, as
> adding full support for the ports and endpoints to the drivers will be a big
> task.
That's perfectly fine, there's no need to implement unused features just for
the sake of it, as long as the bindings are forward-compatible in that
respect.
> This approach still works with more or less all the boards, as the only
> cases where the simpler model is an issue are the boards with multiple
> display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see
> if there's anything that's clearly not CDF compatible.
I've quickly reviewed the patch set, concentrating on the .dts changes.
Overall it looks good to me, but I suspect that we will need quite some time
to finalize standard bindings as there's lots of small details that need to be
taken care of.
The major point that bothers we, as explained in my reply to one of the
patches, is that I feel like the multi-device model (virtual DSS core + DSS
modules) might not accurately represent the hardware. Departing from it
probably sounds scary but might not be such a large change.
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
> A few notes:
>
> - The DT data are added separately in the end of .dts files for clarity. In
> the final version I will move them to appropriate places in the .dts
> files.
>
> - No binding documentation. I will add them for the next version, if there
> are no major changes needed. Hopefully the bindings are quite self-
> explanatory for people with understanding of the hardware in question.
My plan is to split the connection information from the V4L2 bindings and make
that a separate document. If all goes well I should be able to spend Saturday
on this.
> - The connectors' compatible strings are "ti,xxx". As there's nothing TI
> specific there, I think I will rename them to be without "ti".
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
From: Laurent Pinchart @ 2013-12-11 23:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <37483030.ghHfzYFSnL@avalon>
Hi Tomi,
On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> > To avoid the need for a "nickname" property for each display, change
> > the display registration so that the display's alias (i.e. "display0"
> > etc) will be used for the dssdev->name if the display driver didn't
> > provide a name.
> >
> > This means that when booting with board files, we will have more
> > descriptive names for displays, like "lcd1", "hdmi".
>
> Where are those names used ? Are they reported to userspace, or limited to
> kernel internal use only ?
>
> > With DT we'll only have "display0", etc. But as there are no "nicknames"
> > for things like serials ports either, I hope we will do fine with this
>
> Just a random thought, maybe the aliases node could help here.
I should have read the next patches before replying, sorry :-)
> I'm not sure what rules govern its usage. Adding labels to display DT nodes
> could be an option too.
A label property is still an option.
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> >
> > drivers/video/omap2/dss/display.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/omap2/dss/display.c
> > b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f
> > 100644
> > --- a/drivers/video/omap2/dss/display.c
> > +++ b/drivers/video/omap2/dss/display.c
> > @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> > *dssdev)
> > snprintf(dssdev->alias, sizeof(dssdev->alias),
> > "display%d", disp_num_counter++);
> >
> > + if (dssdev->name = NULL)
> > + dssdev->name = dssdev->alias;
> > +
> > if (drv && drv->get_resolution = NULL)
> > drv->get_resolution = omapdss_default_get_resolution;
> > if (drv && drv->get_recommended_bpp = NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Laurent Pinchart @ 2013-12-11 23:44 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <52A5BB65.5050109@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
Hi Tomi,
On Monday 09 December 2013 14:45:25 Tomi Valkeinen wrote:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is
> > initialized from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
>
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
organized in a seemingly similar way, with the hardware subdivided in high-
level more-or-less independent modules. However, from a system point of view,
the ISP submodules are not standalone: they're part of the same power domain
as the ISP core, with subclocks management and interrupts being handled by the
ISP core. For those reasons we've modeled the ISP as a single platform device.
Are the DSS submodules really independent, or are they organized similarly ?
For instance do they each have a clock handled by the OMAP core clock IP, or
are the clocks gated by the DSS core ? Do they have interrupts routed to the
GIC, or does the DSS core driver demux the interrupts ?
If the submodules are not independent, would it make sense to have a single DT
node that would be matched with the DSS core driver ? You could list
information about the submodules in subnodes, and possibly create platform
devices internally in the DSS core, but a single platform device would be
instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible
string. My gut feeling is that this would be a better representation of the
hardware, but I might not known enough about the DSS and be completely wrong.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
>
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
DPI and SDI indeed seem like ports to me, node devices. Have you given the
implementation a thought ? How difficult would it be ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 10/26] OMAPDSS: add of helpers
From: Laurent Pinchart @ 2013-12-11 23:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <1386160133-24026-11-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> Add helpers to get ports and endpoints from DT data.
>
> While all the functions in dss-of.c might be useful for panel drivers if
> they need to parse full port/endpoint data, at the moment we only need a
> few of them outside dss-of.c, so only those functions are exported.
I totally understand that it was easier to add this code to the OMAP DSS
driver, but I believe we should refactor the existing drivers/media/v4l2-
core/v4l2-of.c and move it to a non V4L2-specific location (what about
drivers/media ?) sooner rather than later. That's on my to-do list for
Saturday.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/dss-of.c | 160 ++++++++++++++++++++++++++++++++++++
> include/video/omapdss.h | 6 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
> create mode 100644 drivers/video/omap2/dss/dss-of.c
>
> diff --git a/drivers/video/omap2/dss/Makefile
> b/drivers/video/omap2/dss/Makefile index d3aa91bdd6a8..8aec8bda27cc 100644
> --- a/drivers/video/omap2/dss/Makefile
> +++ b/drivers/video/omap2/dss/Makefile
> @@ -1,7 +1,7 @@
> obj-$(CONFIG_OMAP2_DSS) += omapdss.o
> # Core DSS files
> omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
> - output.o
> + output.o dss-of.o
> # DSS compat layer files
> omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
> dispc-compat.o display-sysfs.o
> diff --git a/drivers/video/omap2/dss/dss-of.c
> b/drivers/video/omap2/dss/dss-of.c new file mode 100644
> index 000000000000..9aa61d4bdb3d
> --- /dev/null
> +++ b/drivers/video/omap2/dss/dss-of.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments
> + * Author: Tomi Valkeinen <tomi.valkeinen@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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> General Public License for + * more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/seq_file.h>
> +
> +#include <video/omapdss.h>
> +
> +#include "dss.h"
> +#include "dss_features.h"
> +
> +static struct device_node *
> +omapdss_of_get_next_port(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *port = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + if (!prev) {
> + struct device_node *ports;
> + /*
> + * It's the first call, we have to find a port subnode
> + * within this node or within an optional 'ports' node.
> + */
> + ports = of_get_child_by_name(parent, "ports");
> + if (ports)
> + parent = ports;
> +
> + port = of_get_child_by_name(parent, "port");
> +
> + /* release the 'ports' node */
> + of_node_put(ports);
> + } else {
> + struct device_node *ports;
> +
> + ports = of_get_parent(prev);
> + if (!ports)
> + return NULL;
> +
> + do {
> + port = of_get_next_child(ports, prev);
> + if (!port) {
> + of_node_put(ports);
> + return NULL;
> + }
> + prev = port;
> + } while (of_node_cmp(port->name, "port") != 0);
> + }
> +
> + return port;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_next_endpoint(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *ep = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + do {
> + ep = of_get_next_child(parent, prev);
> + if (!ep)
> + return NULL;
> + prev = ep;
> + } while (of_node_cmp(ep->name, "endpoint") != 0);
> +
> + return ep;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_remote_device_node(const struct device_node *node)
> +{
> + struct device_node *np;
> + int i;
> +
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> + if (!np)
> + return NULL;
> +
> + np = of_get_next_parent(np);
> +
> + for (i = 0; i < 3 && np; ++i) {
> + struct property *prop;
> +
> + prop = of_find_property(np, "compatible", NULL);
> +
> + if (prop)
> + return np;
> +
> + np = of_get_next_parent(np);
> + }
> +
> + return NULL;
> +}
> +
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent)
> +{
> + struct device_node *port;
> + struct device_node *ep;
> +
> + port = omapdss_of_get_next_port(parent, NULL);
> + if (port) {
> + ep = omapdss_of_get_next_endpoint(port, NULL);
> + of_node_put(port);
> + } else {
> + ep = omapdss_of_get_next_endpoint(parent, NULL);
> + }
> +
> + return ep;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node)
> +{
> + struct device_node *ep;
> + struct device_node *src_node;
> + struct omap_dss_device *src;
> +
> + ep = omapdss_of_get_first_endpoint(node);
> + if (!ep)
> + return ERR_PTR(-EINVAL);
> +
> + src_node = omapdss_of_get_remote_device_node(ep);
> +
> + of_node_put(ep);
> +
> + if (!src_node)
> + return ERR_PTR(-EINVAL);
> +
> + src = omap_dss_find_output_by_node(src_node);
> +
> + of_node_put(src_node);
> +
> + if (!src)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return src;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 3d7c51a6f9ff..c510591df1b8 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct
> omap_dss_device *dssdev) return dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> }
>
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node);
> +
> #endif
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
From: Laurent Pinchart @ 2013-12-11 23:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <1386160133-24026-7-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> To avoid the need for a "nickname" property for each display, change
> the display registration so that the display's alias (i.e. "display0"
> etc) will be used for the dssdev->name if the display driver didn't
> provide a name.
>
> This means that when booting with board files, we will have more
> descriptive names for displays, like "lcd1", "hdmi".
Where are those names used ? Are they reported to userspace, or limited to
kernel internal use only ?
> With DT we'll only have "display0", etc. But as there are no "nicknames" for
> things like serials ports either, I hope we will do fine with this approach.
Just a random thought, maybe the aliases node could help here. I'm not sure
what rules govern its usage. Adding labels to display DT nodes could be an
option too.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/display.c
> b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f 100644
> --- a/drivers/video/omap2/dss/display.c
> +++ b/drivers/video/omap2/dss/display.c
> @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> *dssdev) snprintf(dssdev->alias, sizeof(dssdev->alias),
> "display%d", disp_num_counter++);
>
> + if (dssdev->name = NULL)
> + dssdev->name = dssdev->alias;
> +
> if (drv && drv->get_resolution = NULL)
> drv->get_resolution = omapdss_default_get_resolution;
> if (drv && drv->get_recommended_bpp = NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
From: Laurent Pinchart @ 2013-12-11 23:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
In-Reply-To: <1386160133-24026-6-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
> omapdss driver uses a omapdss platform device to pass platform specific
> function pointers and DSS hardware version from the arch code to the
> driver. This device is needed also when booting with DT.
>
> This patch adds omapdss_init_of() function, called from board-generic at
> init time, which creates the omapdss device.
Is this a temporary solution that you plan to later replace with DT-only
device instantiation ?
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 2 ++
> arch/arm/mach-omap2/common.h | 2 ++
> arch/arm/mach-omap2/display.c | 62 ++++++++++++++++++++++++++++++++++
> 3 files changed, 66 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c index 19f1652e94cf..0e06771d7bee
> 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = { static void __init omap_generic_init(void)
> {
> pdata_quirks_init(omap_dt_match_table);
> +
> + omapdss_init_of();
> }
>
> #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index f7644febee81..48e9cd34cae0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
> /* SoC specific clock initializer */
> extern int (*omap_clk_init)(void);
>
> +int __init omapdss_init_of(void);
> +
> #endif /* __ASSEMBLER__ */
> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index a4e536b11ec9..3279afc5f0b5 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -23,6 +23,8 @@
> #include <linux/clk.h>
> #include <linux/err.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
> #include <video/omapdss.h>
> #include "omap_hwmod.h"
> @@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
>
> return r;
> }
> +
> +int __init omapdss_init_of(void)
> +{
> + int r;
> + enum omapdss_version ver;
> +
> + static struct omap_dss_board_info board_data = {
> + .dsi_enable_pads = omap_dsi_enable_pads,
> + .dsi_disable_pads = omap_dsi_disable_pads,
> + .get_context_loss_count = omap_pm_get_dev_context_loss_count,
> + .set_min_bus_tput = omap_dss_set_min_bus_tput,
> + };
> +
> + ver = omap_display_get_version();
> +
> + if (ver = OMAPDSS_VER_UNKNOWN) {
> + pr_err("DSS not supported on this SoC\n");
> + return -ENODEV;
> + }
> +
> + board_data.version = ver;
> +
> + omap_display_device.dev.platform_data = &board_data;
> +
> + r = platform_device_register(&omap_display_device);
> + if (r < 0) {
> + pr_err("Unable to register omapdss device\n");
> + return r;
> + }
> +
> + /* create DRM device */
> + r = omap_init_drm();
> + if (r < 0) {
> + pr_err("Unable to register omapdrm device\n");
> + return r;
> + }
> +
> + /* create vrfb device */
> + r = omap_init_vrfb();
> + if (r < 0) {
> + pr_err("Unable to register omapvrfb device\n");
> + return r;
> + }
> +
> + /* create FB device */
> + r = omap_init_fb();
> + if (r < 0) {
> + pr_err("Unable to register omapfb device\n");
> + return r;
> + }
> +
> + /* create V4L2 display device */
> + r = omap_init_vout();
> + if (r < 0) {
> + pr_err("Unable to register omap_vout device\n");
> + return r;
> + }
> +
> + return 0;
> +}
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing unlock in acx565akm_panel_power_on()
From: Tomi Valkeinen @ 2013-12-11 14:29 UTC (permalink / raw)
To: Wei Yongjun, plagnioj, aaro.koskinen; +Cc: yongjun_wei, linux-omap, linux-fbdev
In-Reply-To: <CAPgLHd_asZkqBEXyx611=NOMfcaR18jZ8Yxkt5yhg7Lbng93MA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hi,
On 2013-12-06 14:55, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add the missing unlock before return from function
> acx565akm_panel_power_on() in the error handling case.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
A fix for this has already been merged:
c37dd677988ca50bc8bc60ab5ab053720583c168 (ARM: OMAPFB:
panel-sony-acx565akm: fix bad unlock balance)
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2013-12-11 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1385515117-23664-14-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Jean-Christophe and Tomi,
Could you please pick this patch up for v3.14 ?
On Wednesday 27 November 2013 02:18:35 Laurent Pinchart wrote:
> This helps increasing build testing coverage.
>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Acked-by: Simon Horman <horms@verge.net.au>
> ---
> drivers/video/Kconfig | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 4f2e1b3..2aceb08 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -10,7 +10,8 @@ config HAVE_FB_ATMEL
>
> config SH_MIPI_DSI
> tristate
> - depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> + depends on HAVE_CLK
> + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>
> config SH_LCD_MIPI_DSI
> bool
> @@ -1997,7 +1998,8 @@ config FB_W100
>
> config FB_SH_MOBILE_LCDC
> tristate "SuperH Mobile LCDC framebuffer support"
> - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> + depends on FB && HAVE_CLK
> + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> select FB_SYS_FILLRECT
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> @@ -2484,7 +2486,7 @@ endif
>
> config FB_SH_MOBILE_MERAM
> tristate "SuperH Mobile MERAM read ahead support"
> - depends on (SUPERH || ARCH_SHMOBILE)
> + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> select GENERIC_ALLOCATOR
> ---help---
> Enable MERAM support for the SuperH controller.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Tony Lindgren @ 2013-12-10 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv36MaVqrmQxpqDu-ciO9GNJK3pJkFZohEvd1BOLOWWEOhw@mail.gmail.com>
* Belisko Marek <marek.belisko@gmail.com> [131210 14:13]:
> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > It would be best to set it up as omap-ctrl.c driver under drivers
> > somewhere with few functions exported for DSS and MMC drivers.
>
> I create small dummy driver based on phy-omap-control which can be
> used but before sending patch (with more updates) I would like to get
> some feedback if my direction is correct.
Cool thanks. Yeah what you have can easily be combined with the patches
Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap
for the SCM register access. Maybe take a look at the work in progress
patches in thread:
[PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup
And also see my comments regarding using the SCM GENERAL register area
as base for the syscon.c driver. That should work for your driver too,
right? And then you can access the SYSCON1 register that way from your
consumer driver ;)
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.
From: Belisko Marek @ 2013-12-10 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131111233152.GR15154@atomide.com>
Hi Tony,
On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Belisko Marek <marek.belisko@gmail.com> [131111 14:01]:
>> Hi Tony,
>>
>> On Mon, Nov 11, 2013 at 5:49 PM, Tony Lindgren <tony@atomide.com> wrote:
>> > * Marek Belisko <marek@goldelico.com> [131014 14:11]:
>> >> devconf1 reg access is localized only in mach-omap2 and we need to export
>> >> updating of devconf1 from omapdss venc driver (bypass and acbias bits).
>> >> Add simple api call which update only necessary bits.
>> > ...
>> >
>> >> +void update_bypass_acbias(bool bypass, bool acbias)
>> >> +{
>> >> +#ifdef CONFIG_ARCH_OMAP3
>> >> + int val = omap_ctrl_readl(OMAP343X_CONTROL_DEVCONF1);
>> >> +
>> >> + if (bypass)
>> >> + val |= OMAP2_TVOUTBYPASS;
>> >> + else
>> >> + val &= ~OMAP2_TVOUTBYPASS;
>> >> +
>> >> + if (acbias)
>> >> + val |= OMAP2_TVACEN;
>> >> + else
>> >> + val &= ~OMAP2_TVACEN;
>> >> +
>> >> + omap_ctrl_writel(val, OMAP343X_CONTROL_DEVCONF1);
>> >> +#endif
>> >
>> > If this is truly a pinmux, you could already access this
>> > using pinctrl-single,bits device tree driver.
>> >
>> > But I guess that won't work yet, so it's best to set this
>> > up as a separate driver like we've done for the USB PHY
>> > registers.
>>
>> Can you please point me to that driver directly? I cannot see benefit
>> of new driver as as it will be only dummy driver
>> with export_symbol_gpl of upper function. Can it sit then in dss
>> directory or somewhere else? Thanks.
>
> You can take a look at drivers/usb/phy/phy-omap-control.c.
>
> Then there's a device tree using example for control_devconf0 in
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt.
>
> Looks like CONTROL_DEVCONF1 contains a bunch of misc registers,
> and arch/arm/mach-omap2/hsmmc.c seems to be tinkering with it too.
>
> It would be best to set it up as omap-ctrl.c driver under drivers
> somewhere with few functions exported for DSS and MMC drivers.
I create small dummy driver based on phy-omap-control which can be
used but before sending patch (with more updates) I would like to get
some feedback if my direction is correct.
diff --git a/drivers/misc/omap-ctrl.c b/drivers/misc/omap-ctrl.c
new file mode 100644
index 0000000..ca2e576
--- /dev/null
+++ b/drivers/misc/omap-ctrl.c
@@ -0,0 +1,84 @@
+/*
+ * omap-ctrl.c - The part of omap control module.
+ *
+ * Copyright (C) 2013 Goldelico GmbH
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Marek Belisko <marek@goldelico.com>
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+static u32 __iomem *devconf1;
+
+void omap_ctrl_tvoutbypass(int on)
+{
+ int val = readl(devconf1);
+
+ if (on)
+ val |= BIT(18);
+ else
+ val &= ~BIT(18);
+
+ writel(val, devconf1);
+}
+EXPORT_SYMBOL_GPL(omap_ctrl_tvoutbypass);
+
+
+void omap_ctrl_acen(int on)
+{
+ int val = readl(devconf1);
+
+ if (on)
+ val |= BIT(11);
+ else
+ val &= ~BIT(11);
+
+ writel(val, devconf1);
+}
+EXPORT_SYMBOL_GPL(omap_ctrl_acen);
+
+
+static int omap_ctrl_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "devconf1");
+ devconf1 = devm_ioremap_resource(
+ &pdev->dev, res);
+ if (IS_ERR(devconf1))
+ return PTR_ERR(devconf1);
+
+ return 0;
+}
+
+struct platform_driver omap_ctrl_driver = {
+ .probe = omap_ctrl_probe,
+ .driver = {
+ .name = "omap-ctrl",
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap_ctrl_init(void)
+{
+ return platform_driver_register(&omap_ctrl_driver);
+}
+subsys_initcall(omap_ctrl_init);
+
+static void __exit omap_ctrl_exit(void)
+{
+ platform_driver_unregister(&omap_ctrl_driver);
+}
I use that driver with platform device in board file with proper
resources and it works fine. It could be easily added also DT
bindings.
Also you mention somewhere in drivers (but I think misc isn't right
place for that). Any opinion on that? Thanks for feedback.
>
> The reason why it should be a separate driver is that the system
> control module can live a separate runtime PM life from the
> drivers using the CONTROL_DEVCONF register bits.
>
> Regards,
>
> Tony
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply related
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
From: Tomi Valkeinen @ 2013-12-10 12:18 UTC (permalink / raw)
To: florian.vaussard, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
In-Reply-To: <52A1A492.8090205@epfl.ch>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-06 12:18, Florian Vaussard wrote:
> Hello Tomi,
>
> On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
>> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
>> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
>> it as a test.
>>
>
> Looking at the schematics, both seem pretty similar indeed. The main
> difference seems to be the LCD on the palo43, and the HDMI on the Tobi
> (TFP410, as in your patch 21).
>
> I only have a Tobi on my desk, so this is the reason for not supporting
> other boards... We could make a .dtsi with common stuff, then add the
> LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
> support to these boards in the coming days, so I can add this too, at
> least for testing purpose.
I think I'll just drop this patch, as I haven't been able to boot my
overo with nfs root for some time. I don't know if it's my pc or the
board or the kernel, but for some reason the usb gadget ethernet refuses
to work.
If you want to update the tobi.dts for the proper DT data, I'm happy to
include the patch to my series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-10 12:10 UTC (permalink / raw)
To: Enric Balletbo Serra, Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CAFqH_517U6vUz7adwaF4h78wvvwPf3v0CYMw93_aFY7_=an1Xg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On 2013-12-10 12:56, Enric Balletbo Serra wrote:
> Hi all,
>
> 2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>>> Hi Tomi,
>>>>
>>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>>
>>>>>>> + tfp410: encoder@0 {
>>>>>>> + compatible = "ti,tfp410";
>>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>>> +
>>>>>>
>>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>>> numbers, i.e:
>>>>>>
>>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>>
>>>>> Thanks, fixed now (for all .dts files)
>>>>>
>>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>>
>>>>
>>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>>> GPIO_ACTIVE_HIGH as 0.
>>>>
>>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>>> signal inverter but that is a special case. I don't know about the
>>>> Panda board since I haven't looked at its datasheet.
>>>
>>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>>> as it were active-low. The flag is ignored.
>>>
>>
>> How weird, it does work on the IGEPv2 but you are right I just looked
>> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
>> that it indeed just does:
>>
>> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
>> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>>
>> So I don't know how it is working... I'm on the road and won't have
>> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
>> light on this.
>>
>
> On IGEPv2 the GPIO that controls the power-down pin is connected
> through a dual/buffer driver [1]. This driver is only a buffer, not
> inverts the signal (I had told you wrong, sorry Javier ), so the pin
> continues being active low.
>
> As both of you pointed the driver ignores the flag to handle the PD
> GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
> or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
> display for IGEP, to be coherent, the gpio should be defined as
> GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
> works.
>
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index 2569d60..d185e06 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -233,7 +233,7 @@
>
> tfp410: encoder@0 {
> compatible = "ti,tfp410";
> - gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
> + gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
>
> ports {
> #address-cells = <1>;
>
>
> [1] http://www.ti.com/product/sn74lvc2g07
Ok, looks good. I have changed the TFP gpios to active-low in my series
for all .dts files, which includes the igep0020.dts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Personal Loan
From: ''Hyde Finance Loan Company'' @ 2013-12-10 11:22 UTC (permalink / raw)
To: Recipients
Loans available at 3%.Contact us for more info if interested.Serious minded only.Contact us Via Email: hydenance@gmail.com
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Enric Balletbo Serra @ 2013-12-10 10:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tomi Valkeinen, linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CABxcv==2TS00WJduP0EUCmOgLT9x-qzTO+GzyE=R+yooGAmPEA@mail.gmail.com>
Hi all,
2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>> Hi Tomi,
>>>
>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>
>>>>>> + tfp410: encoder@0 {
>>>>>> + compatible = "ti,tfp410";
>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>> +
>>>>>
>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>> numbers, i.e:
>>>>>
>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>
>>>> Thanks, fixed now (for all .dts files)
>>>>
>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>
>>>
>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>> GPIO_ACTIVE_HIGH as 0.
>>>
>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>> signal inverter but that is a special case. I don't know about the
>>> Panda board since I haven't looked at its datasheet.
>>
>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>> as it were active-low. The flag is ignored.
>>
>
> How weird, it does work on the IGEPv2 but you are right I just looked
> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
> that it indeed just does:
>
> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>
> So I don't know how it is working... I'm on the road and won't have
> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
> light on this.
>
On IGEPv2 the GPIO that controls the power-down pin is connected
through a dual/buffer driver [1]. This driver is only a buffer, not
inverts the signal (I had told you wrong, sorry Javier ), so the pin
continues being active low.
As both of you pointed the driver ignores the flag to handle the PD
GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
display for IGEP, to be coherent, the gpio should be defined as
GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
works.
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 2569d60..d185e06 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -233,7 +233,7 @@
tfp410: encoder@0 {
compatible = "ti,tfp410";
- gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
+ gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
ports {
#address-cells = <1>;
[1] http://www.ti.com/product/sn74lvc2g07
Best regards,
Enric
>> Tomi
>>
>>
>
> Thanks a lot and best regards,
> Javier
^ permalink raw reply related
* [PATCH v4 1/5] PCI: pcibus address to resource converting take bus instead of dev
From: Yinghai Lu @ 2013-12-10 6:54 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Guo Chao, linux-pci, linux-kernel, Yinghai Lu, linux-alpha,
linuxppc-dev, sparclinux, linux-pcmcia, linux-scsi, linux-fbdev
In-Reply-To: <1386658484-15774-1-git-send-email-yinghai@kernel.org>
For allocating resource under bus path, we do not have dev to pass along,
and we only have bus to use instead.
-v2: drop pcibios_bus_addr_to_resource().
-v3: drop __* change requested by Bjorn.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: linux-alpha@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: linux-pcmcia@lists.infradead.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
---
arch/alpha/kernel/pci-sysfs.c | 4 ++--
arch/powerpc/kernel/pci-common.c | 4 ++--
arch/powerpc/kernel/pci_of_scan.c | 4 ++--
arch/sparc/kernel/pci.c | 6 +++---
drivers/pci/host-bridge.c | 24 +++++++++++-------------
drivers/pci/probe.c | 18 +++++++++---------
drivers/pci/quirks.c | 2 +-
drivers/pci/rom.c | 2 +-
drivers/pci/setup-bus.c | 16 ++++++++--------
drivers/pci/setup-res.c | 2 +-
drivers/pcmcia/i82092.c | 2 +-
drivers/pcmcia/yenta_socket.c | 6 +++---
drivers/scsi/sym53c8xx_2/sym_glue.c | 5 +++--
drivers/video/arkfb.c | 2 +-
drivers/video/s3fb.c | 2 +-
drivers/video/vt8623fb.c | 2 +-
include/linux/pci.h | 4 ++--
17 files changed, 52 insertions(+), 53 deletions(-)
diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
index 2b183b0..99e8d47 100644
--- a/arch/alpha/kernel/pci-sysfs.c
+++ b/arch/alpha/kernel/pci-sysfs.c
@@ -83,7 +83,7 @@ static int pci_mmap_resource(struct kobject *kobj,
if (iomem_is_exclusive(res->start))
return -EINVAL;
- pcibios_resource_to_bus(pdev, &bar, res);
+ pcibios_resource_to_bus(pdev->bus, &bar, res);
vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
@@ -139,7 +139,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
long dense_offset;
unsigned long sparse_size;
- pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]);
+ pcibios_resource_to_bus(pdev->bus, &bar, &pdev->resource[num]);
/* All core logic chips have 4G sparse address space, except
CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a1e3e40..d9476c1 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -835,7 +835,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
* at 0 as unset as well, except if PCI_PROBE_ONLY is also set
* since in that case, we don't want to re-assign anything
*/
- pcibios_resource_to_bus(dev, ®, res);
+ pcibios_resource_to_bus(dev->bus, ®, res);
if (pci_has_flag(PCI_REASSIGN_ALL_RSRC) ||
(reg.start = 0 && !pci_has_flag(PCI_PROBE_ONLY))) {
/* Only print message if not re-assigning */
@@ -886,7 +886,7 @@ static int pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
/* Job is a bit different between memory and IO */
if (res->flags & IORESOURCE_MEM) {
- pcibios_resource_to_bus(dev, ®ion, res);
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
/* If the BAR is non-0 then it's probably been initialized */
if (region.start != 0)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index ac0b034..83c26d8 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -111,7 +111,7 @@ static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
res->name = pci_name(dev);
region.start = base;
region.end = base + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
}
@@ -280,7 +280,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
res->flags = flags;
region.start = of_read_number(&ranges[1], 2);
region.end = region.start + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index cb02145..7de8d1f 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -392,7 +392,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res->flags = IORESOURCE_IO;
region.start = (first << 21);
region.end = (last << 21) + ((1 << 21) - 1);
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
pci_read_config_byte(dev, APB_MEM_ADDRESS_MAP, &map);
apb_calc_first_last(map, &first, &last);
@@ -400,7 +400,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res->flags = IORESOURCE_MEM;
region.start = (first << 29);
region.end = (last << 29) + ((1 << 29) - 1);
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
static void pci_of_scan_bus(struct pci_pbm_info *pbm,
@@ -491,7 +491,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
res->flags = flags;
region.start = GET_64BIT(ranges, 1);
region.end = region.start + size - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
after_ranges:
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index a68dc61..6bcd233 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -9,22 +9,19 @@
#include "pci.h"
-static struct pci_bus *find_pci_root_bus(struct pci_dev *dev)
+static struct pci_bus *find_pci_root_bus(struct pci_bus *bus)
{
- struct pci_bus *bus;
-
- bus = dev->bus;
while (bus->parent)
bus = bus->parent;
return bus;
}
-static struct pci_host_bridge *find_pci_host_bridge(struct pci_dev *dev)
+static struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
{
- struct pci_bus *bus = find_pci_root_bus(dev);
+ struct pci_bus *root_bus = find_pci_root_bus(bus);
- return to_pci_host_bridge(bus->bridge);
+ return to_pci_host_bridge(root_bus->bridge);
}
void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
@@ -40,10 +37,11 @@ static bool resource_contains(struct resource *res1, struct resource *res2)
return res1->start <= res2->start && res1->end >= res2->end;
}
-void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
- struct resource *res)
+void pcibios_resource_to_bus(struct pci_bus *bus,
+ struct pci_bus_region *region,
+ struct resource *res)
{
- struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
+ struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
struct pci_host_bridge_window *window;
resource_size_t offset = 0;
@@ -68,10 +66,10 @@ static bool region_contains(struct pci_bus_region *region1,
return region1->start <= region2->start && region1->end >= region2->end;
}
-void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
- struct pci_bus_region *region)
+void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
+ struct pci_bus_region *region)
{
- struct pci_host_bridge *bridge = find_pci_host_bridge(dev);
+ struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
struct pci_host_bridge_window *window;
resource_size_t offset = 0;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 38e403d..f049e3f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -269,8 +269,8 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
region.end = l + sz;
}
- pcibios_bus_to_resource(dev, res, ®ion);
- pcibios_resource_to_bus(dev, &inverted_region, res);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
+ pcibios_resource_to_bus(dev->bus, &inverted_region, res);
/*
* If "A" is a BAR value (a bus address), "bus_to_resource(A)" is
@@ -364,7 +364,7 @@ static void pci_read_bridge_io(struct pci_bus *child)
res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO;
region.start = base;
region.end = limit + io_granularity - 1;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -386,7 +386,7 @@ static void pci_read_bridge_mmio(struct pci_bus *child)
res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM;
region.start = base;
region.end = limit + 0xfffff;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -436,7 +436,7 @@ static void pci_read_bridge_mmio_pref(struct pci_bus *child)
res->flags |= IORESOURCE_MEM_64;
region.start = base;
region.end = limit + 0xfffff;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
dev_printk(KERN_DEBUG, &dev->dev, " bridge window %pR\n", res);
}
}
@@ -1084,24 +1084,24 @@ int pci_setup_device(struct pci_dev *dev)
region.end = 0x1F7;
res = &dev->resource[0];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
region.start = 0x3F6;
region.end = 0x3F6;
res = &dev->resource[1];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
if ((progif & 4) = 0) {
region.start = 0x170;
region.end = 0x177;
res = &dev->resource[2];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
region.start = 0x376;
region.end = 0x376;
res = &dev->resource[3];
res->flags = LEGACY_IO_RESOURCE;
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
}
}
break;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 3a02717..5cb726c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -339,7 +339,7 @@ static void quirk_io_region(struct pci_dev *dev, int port,
/* Convert from PCI bus to resource space */
bus_region.start = region;
bus_region.end = region + size - 1;
- pcibios_bus_to_resource(dev, res, &bus_region);
+ pcibios_bus_to_resource(dev->bus, res, &bus_region);
if (!pci_claim_resource(dev, nr))
dev_info(&dev->dev, "quirk: %pR claimed by %s\n", res, name);
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index c5d0a08..5d59572 100644
--- a/drivers/pci/rom.c
+++ b/drivers/pci/rom.c
@@ -31,7 +31,7 @@ int pci_enable_rom(struct pci_dev *pdev)
if (!res->flags)
return -1;
- pcibios_resource_to_bus(pdev, ®ion, res);
+ pcibios_resource_to_bus(pdev->bus, ®ion, res);
pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
rom_addr &= ~PCI_ROM_ADDRESS_MASK;
rom_addr |= region.start | PCI_ROM_ADDRESS_ENABLE;
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 219a410..7933982 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -475,7 +475,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
&bus->busn_res);
res = bus->resource[0];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
/*
* The IO resource is allocated a range twice as large as it
@@ -489,7 +489,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[1];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_IO_BASE_1,
@@ -499,7 +499,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[2];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_0,
@@ -509,7 +509,7 @@ void pci_setup_cardbus(struct pci_bus *bus)
}
res = bus->resource[3];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
dev_info(&bridge->dev, " bridge window %pR\n", res);
pci_write_config_dword(bridge, PCI_CB_MEMORY_BASE_1,
@@ -546,7 +546,7 @@ static void pci_setup_bridge_io(struct pci_bus *bus)
/* Set up the top and bottom of the PCI I/O segment for this bus. */
res = bus->resource[0];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_IO) {
pci_read_config_dword(bridge, PCI_IO_BASE, &l);
l &= 0xffff0000;
@@ -578,7 +578,7 @@ static void pci_setup_bridge_mmio(struct pci_bus *bus)
/* Set up the top and bottom of the PCI Memory segment for this bus. */
res = bus->resource[1];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_MEM) {
l = (region.start >> 16) & 0xfff0;
l |= region.end & 0xfff00000;
@@ -604,7 +604,7 @@ static void pci_setup_bridge_mmio_pref(struct pci_bus *bus)
/* Set up PREF base/limit. */
bu = lu = 0;
res = bus->resource[2];
- pcibios_resource_to_bus(bridge, ®ion, res);
+ pcibios_resource_to_bus(bridge->bus, ®ion, res);
if (res->flags & IORESOURCE_PREFETCH) {
l = (region.start >> 16) & 0xfff0;
l |= region.end & 0xfff00000;
@@ -1422,7 +1422,7 @@ static int iov_resources_unassigned(struct pci_dev *dev, void *data)
if (!r->flags)
continue;
- pcibios_resource_to_bus(dev, ®ion, r);
+ pcibios_resource_to_bus(dev->bus, ®ion, r);
if (!region.start) {
*unassigned = true;
return 1; /* return early from pci_walk_bus() */
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 83c4d3b..5c060b1 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -52,7 +52,7 @@ void pci_update_resource(struct pci_dev *dev, int resno)
if (res->flags & IORESOURCE_PCI_FIXED)
return;
- pcibios_resource_to_bus(dev, ®ion, res);
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
if (res->flags & IORESOURCE_IO)
diff --git a/drivers/pcmcia/i82092.c b/drivers/pcmcia/i82092.c
index 519c4d6..7d47456 100644
--- a/drivers/pcmcia/i82092.c
+++ b/drivers/pcmcia/i82092.c
@@ -608,7 +608,7 @@ static int i82092aa_set_mem_map(struct pcmcia_socket *socket, struct pccard_mem_
enter("i82092aa_set_mem_map");
- pcibios_resource_to_bus(sock_info->dev, ®ion, mem->res);
+ pcibios_resource_to_bus(sock_info->dev->bus, ®ion, mem->res);
map = mem->map;
if (map > 4) {
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index dc18a3a..8485761 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -445,7 +445,7 @@ static int yenta_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *
unsigned int start, stop, card_start;
unsigned short word;
- pcibios_resource_to_bus(socket->dev, ®ion, mem->res);
+ pcibios_resource_to_bus(socket->dev->bus, ®ion, mem->res);
map = mem->map;
start = region.start;
@@ -709,7 +709,7 @@ static int yenta_allocate_res(struct yenta_socket *socket, int nr, unsigned type
region.start = config_readl(socket, addr_start) & mask;
region.end = config_readl(socket, addr_end) | ~mask;
if (region.start && region.end > region.start && !override_bios) {
- pcibios_bus_to_resource(dev, res, ®ion);
+ pcibios_bus_to_resource(dev->bus, res, ®ion);
if (pci_claim_resource(dev, PCI_BRIDGE_RESOURCES + nr) = 0)
return 0;
dev_printk(KERN_INFO, &dev->dev,
@@ -1033,7 +1033,7 @@ static void yenta_config_init(struct yenta_socket *socket)
struct pci_dev *dev = socket->dev;
struct pci_bus_region region;
- pcibios_resource_to_bus(socket->dev, ®ion, &dev->resource[0]);
+ pcibios_resource_to_bus(socket->dev->bus, ®ion, &dev->resource[0]);
config_writel(socket, CB_LEGACY_MODE_BASE, 0);
config_writel(socket, PCI_BASE_ADDRESS_0, region.start);
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index bac55f7..6d3ee1a 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -1531,7 +1531,7 @@ static int sym_iomap_device(struct sym_device *device)
struct pci_bus_region bus_addr;
int i = 2;
- pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[1]);
+ pcibios_resource_to_bus(pdev->bus, &bus_addr, &pdev->resource[1]);
device->mmio_base = bus_addr.start;
if (device->chip.features & FE_RAM) {
@@ -1541,7 +1541,8 @@ static int sym_iomap_device(struct sym_device *device)
*/
if (!pdev->resource[i].flags)
i++;
- pcibios_resource_to_bus(pdev, &bus_addr, &pdev->resource[i]);
+ pcibios_resource_to_bus(pdev->bus, &bus_addr,
+ &pdev->resource[i]);
device->ram_base = bus_addr.start;
}
diff --git a/drivers/video/arkfb.c b/drivers/video/arkfb.c
index a6b29bd..adc4ea2 100644
--- a/drivers/video/arkfb.c
+++ b/drivers/video/arkfb.c
@@ -1014,7 +1014,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 968b299..9a3f8f1 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1180,7 +1180,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index 8bc6e09..5c7cbc6 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -729,7 +729,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
vga_res.flags = IORESOURCE_IO;
- pcibios_bus_to_resource(dev, &vga_res, &bus_reg);
+ pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
par->state.vgabase = (void __iomem *) vga_res.start;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb8078a..da069fa 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -737,9 +737,9 @@ void pci_fixup_cardbus(struct pci_bus *);
/* Generic PCI functions used internally */
-void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
+void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region,
struct resource *res);
-void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
struct pci_bus_region *region);
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tony Lindgren @ 2013-12-09 18:04 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <52A5BB65.5050109@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131209 04:46]:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> > from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
OK I've finally pushed a real branch for the mach-omap2 board-*.c file
removal patches at omap-for-v3.14/omap3-board-removal so you can use
that as a base for testing. I did not apply the dpi panel pdata-quirks.c
patch as we discussed earlier.
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
OK thanks. Care to also check that it plays along nicely with the comments
starting at line 3222 in omap_hwmod_3xxx_data.c? We should set up things
so we can eventually remove those kind of hwmod workarounds.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
Yes that's what we want if there is a dependency to the dss_core at the
hardware level and the children cannot be used independently. However,
if the children can be enabled and clocked independently, then they
should not be children of the dss_core.
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
If you need a dev entry created for those where the phandle of that dev
is used to select the output for a board, then it makes sense to have
them. I guess you could also set them as a pinctrl mux controller and
then the board specific .dts file could request those outputs. But there
may be more than just mux involved like regulators.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 16:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <52A5E230.4010901@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>
>>>>> + tfp410: encoder@0 {
>>>>> + compatible = "ti,tfp410";
>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>> +
>>>>
>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>> numbers, i.e:
>>>>
>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>
>>> Thanks, fixed now (for all .dts files)
>>>
>>> However... The TFP410 gpio is "power-down". I think we should actually
>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>
>>
>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>> GPIO_ACTIVE_HIGH as 0.
>>
>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>> signal inverter but that is a special case. I don't know about the
>> Panda board since I haven't looked at its datasheet.
>
> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
> as it were active-low. The flag is ignored.
>
How weird, it does work on the IGEPv2 but you are right I just looked
at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
that it indeed just does:
r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
GPIOF_OUT_INIT_LOW, "tfp410 PD");
So I don't know how it is working... I'm on the road and won't have
access to my IGEPv2 to dig further on this. Maybe Enric can shed more
light on this.
> Tomi
>
>
Thanks a lot and best regards,
Javier
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-09 15:30 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <CABxcv==-aknRfzybA6ify5JSHeiquS9bqAEXumJwhnS6PT0MfA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>
>>>> + tfp410: encoder@0 {
>>>> + compatible = "ti,tfp410";
>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>> +
>>>
>>> Please use the constants from include/dt-bindings/ instead of magic
>>> numbers, i.e:
>>>
>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>
>> Thanks, fixed now (for all .dts files)
>>
>> However... The TFP410 gpio is "power-down". I think we should actually
>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>
>
> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
> GPIO_ACTIVE_HIGH as 0.
>
> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
> signal inverter but that is a special case. I don't know about the
> Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 15:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Enric Balletbo Serra
In-Reply-To: <52A5BDF4.2070304@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>> +
>>
>> Please use the constants from include/dt-bindings/ instead of magic
>> numbers, i.e:
>>
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>
> Thanks, fixed now (for all .dts files)
>
> However... The TFP410 gpio is "power-down". I think we should actually
> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Thanks a lot and best regards,
Javier
[0]: http://www.ti.com/lit/ds/slds145b/slds145b.pdf
^ permalink raw reply
* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
From: Tomi Valkeinen @ 2013-12-09 12:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <CABxcv=m+-9V2qwvuQgJavQ3qOb2+fBcAoW9G_Mi33BTHCWE85g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>> +
>
> Please use the constants from include/dt-bindings/ instead of magic
> numbers, i.e:
>
> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is "power-down". I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
From: Tomi Valkeinen @ 2013-12-09 12:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge
In-Reply-To: <20131205170514.GY26766@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On 2013-12-05 19:05, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
>
> Description missing.. But other than that can you please check that
> the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> the hwmod data from device" works with this?
>
> The test to do is to remove the related reg, interrupt and dma entries
> from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> from DT properly.
I made a quick test with panda, by applying your patch and reverting
b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
the DISPC IRQ, but that worked fine.
> I don't know if it makes sense to have them as children of dss_core, they
> really all seem to be completely independent devices?
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.
> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> property and do the lookup based on the compatible property instead ;)
> So from that point of view we need to get the device mapping right in
> the .dtsi files, and don't want to start mixing up separate devices into
> single .dtsi entry.
Hmm, was that just a general comment, or something that affects the DSS
DT data I have in my patch? As far as I understand, the DSS nodes
reflect the current hwmods correctly.
With the exception that DPI and SDI do not have a matching hwmod, as
they are really part of dss_core/dispc. They are separate nodes as they
are "video outputs" the same way as the other subnodes.
I could perhaps remove the DPI and SDI nodes, and have them as direct
video ports from DISPC, but... That's easier said than done.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
From: Javier Martinez Canillas @ 2013-12-09 12:23 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Javier Martinez Canillas, linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren, Laurent Pinchart, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
In-Reply-To: <52A5B111.3010307@ti.com>
On Mon, Dec 9, 2013 at 1:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-07 06:28, Javier Martinez Canillas wrote:
>
>> Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the right
>> thing for legacy platform data probing but no for DT probing:
>>
>> static int dvic_probe_pdata(struct platform_device *pdev)
>> {
>> ..
>> adapter = i2c_get_adapter(i2c_bus_num);
>> if (!adapter) {
>> dev_err(&pdev->dev,
>> "Failed to get I2C adapter, bus %d\n",
>> i2c_bus_num);
>> return -EPROBE_DEFER;
>> }
>> ..
>> }
>>
>> static int dvic_probe_of(struct platform_device *pdev)
>> {
>> ..
>> adapter = of_find_i2c_adapter_by_node(adapter_node);
>> if (adapter = NULL) {
>> dev_err(&pdev->dev, "failed to parse i2c-bus\n");
>> omap_dss_put_device(ddata->in);
>> return -EINVAL;
>> }
>> ..
>> }
>>
>> The following patch solves the issue if you want to include in your patch-set:
>
> Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
>
Great, thanks a lot for working on this!
I'm very happy that we will have proper display support for IGEPv2 on
v3.14 without any DT hacks or pdata-quirks :-)
> Tomi
Best regards,
Javier
>
>
^ permalink raw reply
* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
From: Javier Martinez Canillas @ 2013-12-09 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org, linux-fbdev,
devicetree@vger.kernel.org, Archit Taneja, Darren Etheridge,
Tony Lindgren
In-Reply-To: <52A5B248.5050303@ti.com>
Hi Tomi,
On Mon, Dec 9, 2013 at 1:06 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:41, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>>> index fa532aaacc68..1ca1932d02aa 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>>> @@ -178,3 +178,70 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dpi {
>>> + vdds_dsi-supply = <&vpll2>;
>>> +
>>> + dpi_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + data-lines = <24>;
>>> + };
>>> +};
>>> +
>>> +&venc {
>>> + vdda_dac-supply = <&vdac>;
>>> +
>>> + venc_out: endpoint {
>>> + remote-endpoint = <&tv_connector_in>;
>>> + };
>>> +};
>>> +
>>> +/ {
>>> + aliases {
>>> + display0 = &dvi0;
>>> + display1 = &tv0;
>>> + };
>>> +
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>>> +
>>
>> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
>> from 1 so gpio5 + 10 is GPIO 138.
>
> Yes, you're right. Good catch.
>
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> +
>>> + tfp410_in: endpoint@0 {
>>> + remote-endpoint = <&dpi_out>;
>>> + };
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + tfp410_out: endpoint@1 {
>>> + remote-endpoint = <&dvi_connector_in>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + dvi0: connector@0 {
>>> + compatible = "ti,dvi_connector";
>>> + i2c-bus = <&i2c3>;
>>> +
>>> + dvi_connector_in: endpoint {
>>> + remote-endpoint = <&tfp410_out>;
>>> + };
>>> + };
>>> +
>>> + tv0: connector@1 {
>>> + compatible = "ti,svideo_connector";
>>> +
>>> + tv_connector_in: endpoint {
>>> + remote-endpoint = <&venc_out>;
>>> + };
>>> + };
>>> +};
>>> --
>>> 1.8.3.2
>>>
>>
>> Also I don't see the DSS pinmux set for this board. I guess you need
>> something like the following on top:
>>
>> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
>> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
>> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
>> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
>> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
>> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
>> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
>> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
>> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
>> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
>> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
>> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
>> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
>> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
>> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
>> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
>> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
>> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
>> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
>> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
>> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
>> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
>> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
>> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
>> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
>> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
>> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
>> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
>
> True. I need to add something like this to all the dts files.
>
> You didn't have muxing in the omap3-igep0020 patch you gave. Is the
> muxing already set in some other patch?
>
Your patch-set is based on v3.13-rc1 but I sent a patch-set [0] to fix
a few regressions for IGEPv2 when we moved to DT-only boot. One of
these patches added the needed DSS pinmuxing and these were included
in v3.13-rc2.
So to test your branch I cherry-picked:
d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
Also, for 3.13 I added a DT hack to make dpi_init_regulator() succeed
and find the VDDS_DSI regulator. That patch is mainline comit
2f2befd82 ("ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi")
Now that I think about it, you may want to add a revert for that patch
on your series too since this hack is not needed anymore with your DSS
bindings.
> Tomi
>
Thanks a lot and best regards,
Javier
>
[0]: http://www.spinics.net/lists/linux-omap/msg99970.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