* Re: [PATCH v3 6/8] video: xilinxfb: Add support for little endian accesses
From: Arnd Bergmann @ 2013-05-31 13:38 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, Michal Simek, Timur Tabi,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <c1791574b211528b9f59af634018b7c83678f963.1370004925.git.michal.simek@xilinx.com>
On Friday 31 May 2013 14:55:36 Michal Simek wrote:
> Dynamically detect endianess on IP and use
> ioread/iowrite functions instead of powerpc and microblaze
> specific out_be32.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Timur Tabi @ 2013-05-31 13:41 UTC (permalink / raw)
To: monstr
Cc: Michal Simek, linux-kernel, Arnd Bergmann,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <51A8A7B1.3040709@monstr.eu>
On 05/31/2013 08:37 AM, Michal Simek wrote:
> The same is for Microblaze. Driver shares fb_virt for IO memory
> and for allocated memory. The purpose of this driver wasn't
> to change the driver logic just resolved sparse warnings.
> The other way is also wrong.
> I have compiled this driver with ppc toolchain and it should
> remove sparse warnings for PPC.
But it's not I/O memory. It's regular memory. __iomem is for
memory-mapped I/O, which is limited to a specific range of memory locations.
If sometimes you use regular memory for the framebuffer, and other times
you use real I/O memory for the framebuffer, then you should have two
different pointers.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Michal Simek @ 2013-05-31 14:22 UTC (permalink / raw)
To: Timur Tabi
Cc: Michal Simek, linux-kernel, Arnd Bergmann,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <51A8A89C.8030404@tabi.org>
[-- Attachment #1: Type: text/plain, Size: 5077 bytes --]
On 05/31/2013 03:41 PM, Timur Tabi wrote:
> On 05/31/2013 08:37 AM, Michal Simek wrote:
>> The same is for Microblaze. Driver shares fb_virt for IO memory
>> and for allocated memory. The purpose of this driver wasn't
>> to change the driver logic just resolved sparse warnings.
>> The other way is also wrong.
>> I have compiled this driver with ppc toolchain and it should
>> remove sparse warnings for PPC.
>
> But it's not I/O memory. It's regular memory. __iomem is for
> memory-mapped I/O, which is limited to a specific range of memory locations.
>
> If sometimes you use regular memory for the framebuffer, and other times
> you use real I/O memory for the framebuffer, then you should have two
> different pointers.
I agree with you and if you like I can change it.
But there will be at least one retype because dma_alloc_coherent returns void *
but struct fb_info expects that pointer is __iomem (char __iomem *screen_base).
Patch is below.
Thanks,
Michal
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index f3d4a69..885f294 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -132,8 +132,8 @@ struct xilinxfb_drvdata {
unsigned int dcr_len;
#endif
void *fb_virt; /* virt. address of the frame buffer */
+ void __iomem *fb_virt_io; /* virt. address of the frame buffer */
dma_addr_t fb_phys; /* phys. address of the frame buffer */
- int fb_alloced; /* Flag, was the fb memory alloced? */
u8 flags; /* features of the driver */
@@ -270,24 +270,36 @@ static int xilinxfb_assign(struct platform_device *pdev,
/* Allocate the framebuffer memory */
if (pdata->fb_phys) {
drvdata->fb_phys = pdata->fb_phys;
- drvdata->fb_virt = ioremap(pdata->fb_phys, fbsize);
+ drvdata->fb_virt_io = ioremap(pdata->fb_phys, fbsize);
+
+ if (!drvdata->fb_virt_io) {
+ dev_err(dev, "Could not allocate frame buffer memory\n");
+ rc = -ENOMEM;
+ if (drvdata->flags & BUS_ACCESS_FLAG)
+ goto err_fbmem;
+ else
+ goto err_region;
+ }
+
+ /* Clear (turn to black) the framebuffer */
+ memset_io(drvdata->fb_virt_io, 0, fbsize);
} else {
- drvdata->fb_alloced = 1;
drvdata->fb_virt = dma_alloc_coherent(dev, PAGE_ALIGN(fbsize),
&drvdata->fb_phys, GFP_KERNEL);
- }
- if (!drvdata->fb_virt) {
- dev_err(dev, "Could not allocate frame buffer memory\n");
- rc = -ENOMEM;
- if (drvdata->flags & BUS_ACCESS_FLAG)
- goto err_fbmem;
- else
- goto err_region;
+ if (!drvdata->fb_virt_io) {
+ dev_err(dev, "Could not allocate frame buffer memory\n");
+ rc = -ENOMEM;
+ if (drvdata->flags & BUS_ACCESS_FLAG)
+ goto err_fbmem;
+ else
+ goto err_region;
+ memset(drvdata->fb_virt, 0, fbsize);
}
- /* Clear (turn to black) the framebuffer */
- memset_io((void __iomem *)drvdata->fb_virt, 0, fbsize);
+
/* Tell the hardware where the frame buffer is */
xilinx_fb_out32(drvdata, REG_FB_ADDR, drvdata->fb_phys);
@@ -307,7 +319,11 @@ static int xilinxfb_assign(struct platform_device *pdev,
/* Fill struct fb_info */
drvdata->info.device = dev;
- drvdata->info.screen_base = (void __iomem *)drvdata->fb_virt;
+ if (drvdata->fb_virt)
+ drvdata->info.screen_base = (__force void __iomem *)
+ drvdata->fb_virt;
+ else
+ drvdata->info.screen_base = drvdata->fb_virt_io;
drvdata->info.fbops = &xilinxfb_ops;
drvdata->info.fix = xilinx_fb_fix;
drvdata->info.fix.smem_start = drvdata->fb_phys;
@@ -341,8 +357,8 @@ static int xilinxfb_assign(struct platform_device *pdev,
if (drvdata->flags & BUS_ACCESS_FLAG) {
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, "regs: phys=%x, virt=%p\n", drvdata->regs_phys,
- drvdata->regs);
+ dev_dbg(dev, "regs: phys=%x, virt=%p\n",
+ (u32)drvdata->regs_phys, drvdata->regs);
}
/* Put a banner in the log (for DEBUG) */
dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
@@ -354,11 +370,11 @@ err_regfb:
fb_dealloc_cmap(&drvdata->info.cmap);
err_cmap:
- if (drvdata->fb_alloced)
+ if (drvdata->fb_virt)
dma_free_coherent(dev, PAGE_ALIGN(fbsize), drvdata->fb_virt,
drvdata->fb_phys);
else
- iounmap(drvdata->fb_virt);
+ iounmap(drvdata->fb_virt_io);
/* Turn off the display */
xilinx_fb_out32(drvdata, REG_CTRL, 0);
@@ -386,11 +402,11 @@ static int xilinxfb_release(struct device *dev)
fb_dealloc_cmap(&drvdata->info.cmap);
- if (drvdata->fb_alloced)
+ if (drvdata->fb_virt)
dma_free_coherent(dev, PAGE_ALIGN(drvdata->info.fix.smem_len),
drvdata->fb_virt, drvdata->fb_phys);
else
- iounmap(drvdata->fb_virt);
+ iounmap(drvdata->fb_virt_io);
/* Turn off the display */
xilinx_fb_out32(drvdata, REG_CTRL, 0);
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply related
* [PATCH 1/2] trivial: atmel_lcdfb: add missing error message
From: Richard Genoud @ 2013-05-31 14:28 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel, Richard Genoud
When a too small framebuffer is given, the atmel_lcdfb_check_var
silently fails.
Adding an error message will save some head scratching.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/video/atmel_lcdfb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 540909d..6e6491f 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -461,8 +461,11 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
if (info->fix.smem_len) {
unsigned int smem_len = (var->xres_virtual * var->yres_virtual
* ((var->bits_per_pixel + 7) / 8));
- if (smem_len > info->fix.smem_len)
+ if (smem_len > info->fix.smem_len) {
+ dev_err(dev, "Frame buffer is too small (%u) for screen size (need at least %u)\n",
+ info->fix.smem_len, smem_len);
return -EINVAL;
+ }
}
/* Saturate vertical and horizontal timings at maximum values */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] atmel_lcdfb: blank the backlight on remove
From: Richard Genoud @ 2013-05-31 14:28 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel, Richard Genoud
In-Reply-To: <1370010519-18691-1-git-send-email-richard.genoud@gmail.com>
When removing atmel_lcdfb module, the backlight is unregistered but not
blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
This can result in the screen going full white depending on how the PWM
is wired.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/video/atmel_lcdfb.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 6e6491f..e00318f 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -223,8 +223,13 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
static void exit_backlight(struct atmel_lcdfb_info *sinfo)
{
- if (sinfo->backlight)
+ if (sinfo->backlight) {
+ if (sinfo->backlight->ops) {
+ sinfo->backlight->props.power = FB_BLANK_POWERDOWN;
+ sinfo->backlight->ops->update_status(sinfo->backlight);
+ }
backlight_device_unregister(sinfo->backlight);
+ }
}
#else
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Arnd Bergmann @ 2013-05-31 14:56 UTC (permalink / raw)
To: monstr
Cc: Timur Tabi, Michal Simek, linux-kernel,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <51A8B220.6070308@monstr.eu>
On Friday 31 May 2013 16:22:24 Michal Simek wrote:
> @@ -307,7 +319,11 @@ static int xilinxfb_assign(struct platform_device *pdev,
>
> /* Fill struct fb_info */
> drvdata->info.device = dev;
> - drvdata->info.screen_base = (void __iomem *)drvdata->fb_virt;
> + if (drvdata->fb_virt)
> + drvdata->info.screen_base = (__force void __iomem *)
> + drvdata->fb_virt;
> + else
> + drvdata->info.screen_base = drvdata->fb_virt_io;
Yes, unfortunately, this is what all other frame buffer drivers do
at the moment. It is technically not correct, but most architectures
are able to call readl/writel on regular memory, or dereference
__iomem tokens, so we often get away with it. It's probably not
worth fixing it in the fbdev code base as that would be a huge
change, and people are migrating to DRM/KMS.
Arnd
^ permalink raw reply
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Timur Tabi @ 2013-05-31 15:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: monstr, Michal Simek, linux-kernel,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <1466524.sgAzczhnBg@wuerfel>
On 05/31/2013 09:56 AM, Arnd Bergmann wrote:
> Yes, unfortunately, this is what all other frame buffer drivers do
> at the moment. It is technically not correct, but most architectures
> are able to call readl/writel on regular memory, or dereference
> __iomem tokens, so we often get away with it. It's probably not
> worth fixing it in the fbdev code base as that would be a huge
> change, and people are migrating to DRM/KMS.
But why bother fixing this bug if it just makes things worse? Sparse is
supposed to warn us about bad code. This patch doesn't fix the bug, it
just masks the warnings!
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH 05/32] OMAPDSS: fix dss_get_ctx_loss_count for DT
From: Grygorii Strashko @ 2013-05-31 15:17 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Tomi Valkeinen, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <874ndk5sse.fsf@linaro.org>
On 05/30/2013 07:36 PM, Kevin Hilman wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>
>> When using DT, dss device does not have platform data. However,
>> dss_get_ctx_loss_count() uses dss device's platform data to find the
>> get_ctx_loss_count function pointer.
>>
>> To fix this, dss_get_ctx_loss_count() needs to be changed to get the
>> platform data from the omapdss device, which is a "virtual" device and
>> always has platform data.
> Dumb question (since the DSS device model has always been beyond my
> grasp): how/why does the virtual device still have platform_data on a DT
> boot?
>
> Also, this context_loss_count and DT boot is starting to get cumbersome,
> and there's currently no (good) way of handling the context loss in a
> generic way without pdata function pointers.
>
> I'm starting to think we should move towards dropping this OMAP-specific
> context loss counting, and just assume context is always lost. If there
> are performance problems, runtime PM autosuspend timeouts can be used to
> avoid the transitions.
>
> Or, on some devices, I suspect comparing a few registers against their
> power-on reset values might be a quicker way of detecting lost context
> and would avoid having to call into platform code all together.
Hi Kevin,
I've a question:
Why don't add API in "Kernel/Base PM" framework for context lost detection?
Like pm_was_ctx_lost().
If this topic has been discussed already (many times)) - sorry for the
noise.
And I'll be very appreciate if you can point me on corresponding
discussions.
>
> Kevin
>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/dss.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 94f66f9..bd01608 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -157,7 +157,8 @@ static void dss_restore_context(void)
>>
>> int dss_get_ctx_loss_count(void)
>> {
>> - struct omap_dss_board_info *board_data = dss.pdev->dev.platform_data;
>> + struct platform_device *core_pdev = dss_get_core_pdev();
>> + struct omap_dss_board_info *board_data = core_pdev->dev.platform_data;
>> int cnt;
>>
>> if (!board_data->get_context_loss_count)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] atmel_lcdfb: blank the backlight on remove
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-31 15:19 UTC (permalink / raw)
To: Richard Genoud; +Cc: Nicolas Ferre, Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1370010519-18691-2-git-send-email-richard.genoud@gmail.com>
On 16:28 Fri 31 May , Richard Genoud wrote:
> When removing atmel_lcdfb module, the backlight is unregistered but not
> blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
> This can result in the screen going full white depending on how the PWM
> is wired.
>
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> ---
> drivers/video/atmel_lcdfb.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 6e6491f..e00318f 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -223,8 +223,13 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
>
> static void exit_backlight(struct atmel_lcdfb_info *sinfo)
> {
> - if (sinfo->backlight)
> + if (sinfo->backlight) {
if (!sinfo->backlight)
return;
other look ok
if you want ot hte next RC you have 3h to send a v2 before I work off for few
days
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Arnd Bergmann @ 2013-05-31 15:28 UTC (permalink / raw)
To: monstr
Cc: Timur Tabi, Michal Simek, linux-kernel,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <51A8B220.6070308@monstr.eu>
On Friday 31 May 2013 16:22:24 Michal Simek wrote:
> if (pdata->fb_phys) {
> drvdata->fb_phys = pdata->fb_phys;
> - drvdata->fb_virt = ioremap(pdata->fb_phys, fbsize);
> + drvdata->fb_virt_io = ioremap(pdata->fb_phys, fbsize);
> +
> + if (!drvdata->fb_virt_io) {
> + dev_err(dev, "Could not allocate frame buffer memory\n");
> + rc = -ENOMEM;
> + if (drvdata->flags & BUS_ACCESS_FLAG)
> + goto err_fbmem;
> + else
> + goto err_region;
> + }
> +
> + /* Clear (turn to black) the framebuffer */
> + memset_io(drvdata->fb_virt_io, 0, fbsize);
> } else {
> - drvdata->fb_alloced = 1;
> drvdata->fb_virt = dma_alloc_coherent(dev, PAGE_ALIGN(fbsize),
> &drvdata->fb_phys, GFP_KERNEL);
> - }
>
I think you also want to use ioremap_wc or dma_alloc_writecombine
here, to get a write-combining mapping, rather than a device mapping
that you would use for MMIO register access.
There is also a builtin assumption in the code above that the DMA
address space pointer (which you pass into REG_FB_ADDR) is the
same as what you pass into drvdata->info.fix.smem_start. That is
not the case in general, but I don't see a good way around it
when pdata->fb_phys is set by the platform to something outside
of system memory. It should probably have a comment next to it.
Arnd
^ permalink raw reply
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Arnd Bergmann @ 2013-05-31 15:29 UTC (permalink / raw)
To: Timur Tabi
Cc: monstr, Michal Simek, linux-kernel,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <51A8BC83.6050809@tabi.org>
On Friday 31 May 2013 10:06:43 Timur Tabi wrote:
> On 05/31/2013 09:56 AM, Arnd Bergmann wrote:
> > Yes, unfortunately, this is what all other frame buffer drivers do
> > at the moment. It is technically not correct, but most architectures
> > are able to call readl/writel on regular memory, or dereference
> > __iomem tokens, so we often get away with it. It's probably not
> > worth fixing it in the fbdev code base as that would be a huge
> > change, and people are migrating to DRM/KMS.
>
> But why bother fixing this bug if it just makes things worse? Sparse is
> supposed to warn us about bad code. This patch doesn't fix the bug, it
> just masks the warnings!
Yes, good point. It's probably best cast the ioremap() output to
a regular pointer here, as that is actually just uncached RAM,
not an MMIO register.
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] atmel_lcdfb: blank the backlight on remove
From: Richard Genoud @ 2013-05-31 15:41 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Nicolas Ferre, Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <20130531151926.GR19468@game.jcrosoft.org>
2013/5/31 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> On 16:28 Fri 31 May , Richard Genoud wrote:
>> When removing atmel_lcdfb module, the backlight is unregistered but not
>> blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
>> This can result in the screen going full white depending on how the PWM
>> is wired.
>>
>> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
>> ---
>> drivers/video/atmel_lcdfb.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 6e6491f..e00318f 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -223,8 +223,13 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
>>
>> static void exit_backlight(struct atmel_lcdfb_info *sinfo)
>> {
>> - if (sinfo->backlight)
>> + if (sinfo->backlight) {
> if (!sinfo->backlight)
> return;
>
Well, I usually prefer to have a single exit point (when it doesn't
make the code go beyond the 80chars limit).
but if you prefer something like:
if (!sinfo->backlight)
return;
if (sinfo->backlight->ops) {
sinfo->backlight->props.power = FB_BLANK_POWERDOWN;
sinfo->backlight->ops->update_status(sinfo->backlight);
}
backlight_device_unregister(sinfo->backlight);
I'll send the modified patch.
> other look ok
>
> if you want ot hte next RC you have 3h to send a v2 before I work off for few
> days
ok, bonnes vacances !
>
> Best Regards,
> J.
^ permalink raw reply
* [PATCHv2 2/2] atmel_lcdfb: blank the backlight on remove
From: Richard Genoud @ 2013-05-31 15:49 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel, Richard Genoud
In-Reply-To: <CACQ1gAh5HL8ouhe3YeGe4B9AO+L02C+wF5a2pUvka01PbupCDg@mail.gmail.com>
When removing atmel_lcdfb module, the backlight is unregistered but not
blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
This can result in the screen going full white depending on how the PWM
is wired.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
---
drivers/video/atmel_lcdfb.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 6e6491f..effdb37 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -223,8 +223,14 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
static void exit_backlight(struct atmel_lcdfb_info *sinfo)
{
- if (sinfo->backlight)
- backlight_device_unregister(sinfo->backlight);
+ if (!sinfo->backlight)
+ return;
+
+ if (sinfo->backlight->ops) {
+ sinfo->backlight->props.power = FB_BLANK_POWERDOWN;
+ sinfo->backlight->ops->update_status(sinfo->backlight);
+ }
+ backlight_device_unregister(sinfo->backlight);
}
#else
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3 7/8] video: xilinxfb: Fix sparse warnings
From: Michal Simek @ 2013-05-31 16:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Timur Tabi, Michal Simek, linux-kernel,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <4930944.aMQtpv2nTI@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
On 05/31/2013 05:29 PM, Arnd Bergmann wrote:
> On Friday 31 May 2013 10:06:43 Timur Tabi wrote:
>> On 05/31/2013 09:56 AM, Arnd Bergmann wrote:
>>> Yes, unfortunately, this is what all other frame buffer drivers do
>>> at the moment. It is technically not correct, but most architectures
>>> are able to call readl/writel on regular memory, or dereference
>>> __iomem tokens, so we often get away with it. It's probably not
>>> worth fixing it in the fbdev code base as that would be a huge
>>> change, and people are migrating to DRM/KMS.
>>
>> But why bother fixing this bug if it just makes things worse? Sparse is
>> supposed to warn us about bad code. This patch doesn't fix the bug, it
>> just masks the warnings!
>
> Yes, good point. It's probably best cast the ioremap() output to
> a regular pointer here, as that is actually just uncached RAM,
> not an MMIO register.
ok. It means I will just remove this patch from this patchset.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 05/32] OMAPDSS: fix dss_get_ctx_loss_count for DT
From: Kevin Hilman @ 2013-05-31 19:31 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: Tomi Valkeinen, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <51A8BF17.4050209@ti.com>
Hi Grygorii,
Grygorii Strashko <grygorii.strashko@ti.com> writes:
[...]
> I've a question:
> Why don't add API in "Kernel/Base PM" framework for context lost detection?
> Like pm_was_ctx_lost().
I'm not aware of any proposals to do this in a generic way. Feel free
to propose one if you're so moved.
One complexity is that such a call is not needed on platforms that use
generic power domains (not OMAP). With gen_pd, the runtime PM callbacks
do not get called unless the power domains actually lose power. So for
gen_pd, you assume context has been lost when your runtime PM callbacks
are called.
This is a bit different than how we've done it on OMAP, and there's been
some work in exploring how to adapt OMAP to gen_pd, but there's not
anyone actively working on it at the moment.
That being said, I'm still leaning towards simply removing the context
loss logic from all the OMAP drivers. This feature adds a relatively
minor optimization, and a more configurable optimization could be done
using runtime PM autosuspend timeouts (configurable from userspace.)
Combined with the fact that adoption of gen_pd means we don't need it,
I'm included to drop it all together.
Kevin
^ permalink raw reply
* [PULL] FBDEV: some small fixes for 3.10-rc4
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-31 19:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-fbdev
Hi Linus,
This contain some small fixes for Atmel LCDC, ps3fb and OMAPDSS
please pull
The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git tags/fbdev-for-3.10-rc4
for you to fetch changes up to 56c21b53ab071feb3ce93375a563ead745fa7105:
atmel_lcdfb: blank the backlight on remove (2013-06-01 03:18:55 +0800)
----------------------------------------------------------------
fbdev: fixes for 3.10-rc4
This contains some small fixes
Atmel LCDC: fix blank the backlight on remove
ps3fb: fix compile warning
OMAPDSS: Fix crash with DT boot
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
----------------------------------------------------------------
Jean-Christophe PLAGNIOL-VILLARD (1):
Merge branch 'fbdev-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux into linux-fbdev/for-3.10-fixes
Richard Genoud (2):
trivial: atmel_lcdfb: add missing error message
atmel_lcdfb: blank the backlight on remove
Tomi Valkeinen (2):
fbdev/ps3fb: fix compile warning
OMAPDSS: Fix crash with DT boot
drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++
drivers/media/platform/omap/omap_vout.c | 3 +++
drivers/video/atmel_lcdfb.c | 15 ++++++++++++---
drivers/video/omap2/dss/core.c | 20 +++++++++++++++++++-
drivers/video/omap2/omapfb/omapfb-main.c | 3 +++
drivers/video/ps3fb.c | 2 +-
include/video/omapdss.h | 1 +
7 files changed, 42 insertions(+), 5 deletions(-)
Brest Regards,
J.
^ permalink raw reply
* Jean-Christophe PLAGNIOL-VILLARD off until 10th of June
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-31 19:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I'm Traveling back to France next week to go to my sister weeding
so I'll be off tonight and will start to be back end of next week
And fully back the 10th of June.
If any urgent matter for FBDEV please ping Tomi and for AT91 ping
Nicolas
Best Regards,
J.
^ permalink raw reply
* [PATCH] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2013-06-01 3:33 UTC (permalink / raw)
To: rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki
Cc: Shuah Khan, linux-fbdev, linux-kernel, shuahkhan
Convert drivers/video/backlight/class to use dev_pm_ops for power
management and remove Legacy PM ops hooks. With this change, rtc class
registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
Legacy class->suspend/resume. When __device_suspend() runs call-backs,
it will find class->pm ops for the rtc class.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Cc: Shuah Khan <shuahkhan@gmail.com>
---
drivers/video/backlight/backlight.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index c74e7aa..0ffb251 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
static struct class *backlight_class;
-static int backlight_suspend(struct device *dev, pm_message_t state)
+static int backlight_suspend(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
+ backlight_resume);
+
static void bl_device_release(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
}
backlight_class->dev_attrs = bl_device_attributes;
- backlight_class->suspend = backlight_suspend;
- backlight_class->resume = backlight_resume;
+ backlight_class->pm = &backlight_class_dev_pm_ops;
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2013-06-01 3:59 UTC (permalink / raw)
To: rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki
Cc: Shuah Khan, linux-fbdev, linux-kernel, shuahkhan
Convert drivers/video/backlight/class to use dev_pm_ops for power
management and remove Legacy PM ops hooks. With this change, rtc class
registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
Legacy class->suspend/resume. When __device_suspend() runs call-backs,
it will find class->pm ops for the backlight class.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Cc: Shuah Khan <shuahkhan@gmail.com>
---
v2: Updated changelog to correct device class.
drivers/video/backlight/backlight.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index c74e7aa..0ffb251 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
static struct class *backlight_class;
-static int backlight_suspend(struct device *dev, pm_message_t state)
+static int backlight_suspend(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
+ backlight_resume);
+
static void bl_device_release(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
}
backlight_class->dev_attrs = bl_device_attributes;
- backlight_class->suspend = backlight_suspend;
- backlight_class->resume = backlight_resume;
+ backlight_class->pm = &backlight_class_dev_pm_ops;
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Jingoo Han @ 2013-06-01 4:08 UTC (permalink / raw)
To: 'Shuah Khan', rpurdie, FlorianSchandinat, plagnioj,
tomi.valkeinen, rafael.j.wysocki
Cc: linux-fbdev, linux-kernel, shuahkhan, Jingoo Han
In-Reply-To: <2236503749-2998-1-git-send-email-shuah.kh@samsung.com>
On Wednesday, November 14, 2040 8:02 PM, Shuah Khan wrote:
>
> Convert drivers/video/backlight/class to use dev_pm_ops for power
> management and remove Legacy PM ops hooks. With this change, rtc class
No, this is a backlight class, not rtc class.
Please fix the typo as below:
rtc class -> backlight class.
> registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
> Legacy class->suspend/resume. When __device_suspend() runs call-backs,
> it will find class->pm ops for the rtc class.
Same here.
Best regards,
Jingoo Han
>
> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> Cc: Shuah Khan <shuahkhan@gmail.com>
> ---
> drivers/video/backlight/backlight.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index c74e7aa..0ffb251 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
>
> static struct class *backlight_class;
>
> -static int backlight_suspend(struct device *dev, pm_message_t state)
> +static int backlight_suspend(struct device *dev)
> {
> struct backlight_device *bd = to_backlight_device(dev);
>
> @@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
> return 0;
> }
>
> +static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
> + backlight_resume);
> +
> static void bl_device_release(struct device *dev)
> {
> struct backlight_device *bd = to_backlight_device(dev);
> @@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
> }
>
> backlight_class->dev_attrs = bl_device_attributes;
> - backlight_class->suspend = backlight_suspend;
> - backlight_class->resume = backlight_resume;
> + backlight_class->pm = &backlight_class_dev_pm_ops;
> return 0;
> }
>
> --
> 1.7.10.4
>
> --
^ permalink raw reply
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Jingoo Han @ 2013-06-01 4:13 UTC (permalink / raw)
To: 'Shuah Khan', rpurdie, FlorianSchandinat, plagnioj,
tomi.valkeinen, rafael.j.wysocki
Cc: linux-fbdev, linux-kernel, shuahkhan, Jingoo Han
In-Reply-To: <2236505237-3336-1-git-send-email-shuah.kh@samsung.com>
On Wednesday, November 14, 2040 8:27 PM, Shuah Khan wrote:
>
> Convert drivers/video/backlight/class to use dev_pm_ops for power
> management and remove Legacy PM ops hooks. With this change, rtc class
There is still the typo.
Please fix it.
rtc class -> backlight class
> registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
> Legacy class->suspend/resume. When __device_suspend() runs call-backs,
> it will find class->pm ops for the backlight class.
>
> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> Cc: Shuah Khan <shuahkhan@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] video: simplefb: add mode parsing function
From: Olof Johansson @ 2013-06-01 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51A42ED5.2060104@wwwdotorg.org>
On Mon, May 27, 2013 at 10:13:09PM -0600, Stephen Warren wrote:
> On 05/26/2013 09:53 PM, Alexandre Courbot wrote:
> > The naming scheme of simplefb's mode is precise enough to allow building
> > the mode structure from it instead of using a static list of modes. This
> > patch introduces a function that does this. In case exotic modes that
> > cannot be represented from their name alone are needed, the static list
> > of modes is still available as a backup.
> >
> > It also changes the order in which colors are declared from MSB first to
> > the more standard LSB first.
> >
> > Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> > ---
> > Changes from v1:
> > - amended documentation following Stephen's suggestion
> > - allow parsing of bitfields larger than 9 bits
> > - made it clear that the parsing order of bits is changed with respect
> > to the original patch
> >
> > Andrew, since this patch introduces a (small) change in the DT bindings,
> > could we try to merge it during the -rc cycle so we don't have to come
> > with a more complex solution in the future?
>
> So, I think we shouldn't change the DT binding at all now. The original
> driver is now merged for 3.10, and I think it's far too late to take
> code that implements new features for 3.10. This means that we couldn't
> merge this patch until 3.11. However, by then, we shouldn't be changing
> the DT binding in incompatible ways. Olof has already published some
> U-Boot binaries that use the current binding, and on IRC indicated he'd
> prefer not to change the binding because of that.
>
> As such, we should either:
>
> a) Just add new entries into the format array that already exists in the
> driver. Given David's response, this might be simplest.
I think so too. Is this even needed? Do we have any users of the newer formats
or is it just someone trying to feature-creep this driver to make the "simple"
part of the name inaccurate? :)
> b) Extend the DT binding in a 100% backwards-compatible way, which would
> mean defaulting the bit-order to match the existing 1 format, and adding
> a new Boolean property to indicate that the format string is specified
> in the other order.
Or just add a new property that has higher priority for the newer format
strings, and make the driver use that if it exists, otherwise fall back.
-Olof
^ permalink raw reply
* [PATCH] video: replace strict_strtoul() with kstrtoul()
From: Jingoo Han @ 2013-06-01 7:31 UTC (permalink / raw)
To: linux-fbdev
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/fsl-diu-fb.c | 4 ++--
drivers/video/omap2/displays/panel-taal.c | 6 +++---
drivers/video/wm8505fb.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 6c27805..6dd7225 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -469,7 +469,7 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
unsigned long val;
if (s) {
- if (!strict_strtoul(s, 10, &val) && (val <= 2))
+ if (!kstrtoul(s, 10, &val) && (val <= 2))
port = (enum fsl_diu_monitor_port) val;
else if (strncmp(s, "lvds", 4) = 0)
port = FSL_DIU_PORT_LVDS;
@@ -1853,7 +1853,7 @@ static int __init fsl_diu_setup(char *options)
if (!strncmp(opt, "monitor=", 8)) {
monitor_port = fsl_diu_name_to_port(opt + 8);
} else if (!strncmp(opt, "bpp=", 4)) {
- if (!strict_strtoul(opt + 4, 10, &val))
+ if (!kstrtoul(opt + 4, 10, &val))
default_bpp = val;
} else
fb_mode = opt;
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
index c4f78bd..52541f2 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -573,7 +573,7 @@ static ssize_t taal_store_esd_interval(struct device *dev,
unsigned long t;
int r;
- r = strict_strtoul(buf, 10, &t);
+ r = kstrtoul(buf, 10, &t);
if (r)
return r;
@@ -611,7 +611,7 @@ static ssize_t taal_store_ulps(struct device *dev,
unsigned long t;
int r;
- r = strict_strtoul(buf, 10, &t);
+ r = kstrtoul(buf, 10, &t);
if (r)
return r;
@@ -660,7 +660,7 @@ static ssize_t taal_store_ulps_timeout(struct device *dev,
unsigned long t;
int r;
- r = strict_strtoul(buf, 10, &t);
+ r = kstrtoul(buf, 10, &t);
if (r)
return r;
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 01f9ace..3072f30 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -173,7 +173,7 @@ static ssize_t contrast_store(struct device *dev,
struct wm8505fb_info *fbi = to_wm8505fb_info(info);
unsigned long tmp;
- if (strict_strtoul(buf, 10, &tmp) || (tmp > 0xff))
+ if (kstrtoul(buf, 10, &tmp) || (tmp > 0xff))
return -EINVAL;
fbi->contrast = tmp;
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2013-06-01 23:07 UTC (permalink / raw)
To: rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki
Cc: Shuah Khan, linux-fbdev, linux-kernel, shuahkhan
Convert drivers/video/backlight/class to use dev_pm_ops for power
management and remove Legacy PM ops hooks. With this change, backlight
class registers suspend/resume callbacks via class->pm (dev_pm_ops)
instead of Legacy class->suspend/resume. When __device_suspend() runs
call-backs, it will find class->pm ops for the backlight class.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Cc: Shuah Khan <shuahkhan@gmail.com>
---
v2: Updated changelog to correct device class.
v3: Updated changelog to correct device class.
drivers/video/backlight/backlight.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index c74e7aa..0ffb251 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
static struct class *backlight_class;
-static int backlight_suspend(struct device *dev, pm_message_t state)
+static int backlight_suspend(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
return 0;
}
+static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
+ backlight_resume);
+
static void bl_device_release(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
}
backlight_class->dev_attrs = bl_device_attributes;
- backlight_class->suspend = backlight_suspend;
- backlight_class->resume = backlight_resume;
+ backlight_class->pm = &backlight_class_dev_pm_ops;
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] video: simplefb: add mode parsing function
From: Stephen Warren @ 2013-06-02 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130601051223.GB5189@quad.lixom.net>
On 05/31/2013 11:12 PM, Olof Johansson wrote:
> On Mon, May 27, 2013 at 10:13:09PM -0600, Stephen Warren wrote:
>> On 05/26/2013 09:53 PM, Alexandre Courbot wrote:
>>> The naming scheme of simplefb's mode is precise enough to allow building
>>> the mode structure from it instead of using a static list of modes. This
>>> patch introduces a function that does this. In case exotic modes that
>>> cannot be represented from their name alone are needed, the static list
>>> of modes is still available as a backup.
...
>> As such, we should either:
>>
>> a) Just add new entries into the format array that already exists in the
>> driver. Given David's response, this might be simplest.
>
> I think so too. Is this even needed? Do we have any users of the newer formats
> or is it just someone trying to feature-creep this driver to make the "simple"
> part of the name inaccurate? :)
Alex is working on board support for a new NVIDIA board, where IIRC the
bootloader sets up some 32-bit ARGB format for the panel.
^ 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