* [PATCH 1/2] ARM: integrator: move framebuffers to driver
From: Linus Walleij @ 2015-07-29 12:27 UTC (permalink / raw)
To: linux-arm-kernel
Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd
"video: move Versatile CLCD helpers" already moved the
CLCD mode setting helpers for Versatile and Integrator/CP
to drivers/video/fbdev. Let's do the same for the IM-PD1
add-on board, copy the missing displays into the database
and simplify the code.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
FBDEV maintainers: requesting your ACK so I can take this into
the ARM SoC tree.
---
arch/arm/mach-integrator/impd1.c | 181 +++---------------------------
drivers/video/fbdev/amba-clcd-versatile.c | 80 +++++++++++++
2 files changed, 94 insertions(+), 167 deletions(-)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index 38b0da300dd5..f164643b7c59 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -20,6 +20,7 @@
#include <linux/mm.h>
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
+#include <linux/platform_data/video-clcd-versatile.h>
#include <linux/amba/mmci.h>
#include <linux/amba/pl061.h>
#include <linux/io.h>
@@ -64,131 +65,6 @@ static struct mmci_platform_data mmc_data = {
/*
* CLCD support
*/
-#define PANEL PROSPECTOR
-
-#define LTM10C209 1
-#define PROSPECTOR 2
-#define SVGA 3
-#define VGA 4
-
-#if PANEL = VGA
-#define PANELTYPE vga
-static struct clcd_panel vga = {
- .mode = {
- .name = "VGA",
- .refresh = 60,
- .xres = 640,
- .yres = 480,
- .pixclock = 39721,
- .left_margin = 40,
- .right_margin = 24,
- .upper_margin = 32,
- .lower_margin = 11,
- .hsync_len = 96,
- .vsync_len = 2,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED,
- },
- .width = -1,
- .height = -1,
- .tim2 = TIM2_BCD | TIM2_IPC,
- .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
- .caps = CLCD_CAP_5551,
- .connector = IMPD1_CTRL_DISP_VGA,
- .bpp = 16,
- .grayscale = 0,
-};
-
-#elif PANEL = SVGA
-#define PANELTYPE svga
-static struct clcd_panel svga = {
- .mode = {
- .name = "SVGA",
- .refresh = 0,
- .xres = 800,
- .yres = 600,
- .pixclock = 27778,
- .left_margin = 20,
- .right_margin = 20,
- .upper_margin = 5,
- .lower_margin = 5,
- .hsync_len = 164,
- .vsync_len = 62,
- .sync = 0,
- .vmode = FB_VMODE_NONINTERLACED,
- },
- .width = -1,
- .height = -1,
- .tim2 = TIM2_BCD,
- .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
- .connector = IMPD1_CTRL_DISP_VGA,
- .caps = CLCD_CAP_5551,
- .bpp = 16,
- .grayscale = 0,
-};
-
-#elif PANEL = PROSPECTOR
-#define PANELTYPE prospector
-static struct clcd_panel prospector = {
- .mode = {
- .name = "PROSPECTOR",
- .refresh = 0,
- .xres = 640,
- .yres = 480,
- .pixclock = 40000,
- .left_margin = 33,
- .right_margin = 64,
- .upper_margin = 36,
- .lower_margin = 7,
- .hsync_len = 64,
- .vsync_len = 25,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED,
- },
- .width = -1,
- .height = -1,
- .tim2 = TIM2_BCD,
- .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
- .caps = CLCD_CAP_5551,
- .fixedtimings = 1,
- .connector = IMPD1_CTRL_DISP_LCD,
- .bpp = 16,
- .grayscale = 0,
-};
-
-#elif PANEL = LTM10C209
-#define PANELTYPE ltm10c209
-/*
- * Untested.
- */
-static struct clcd_panel ltm10c209 = {
- .mode = {
- .name = "LTM10C209",
- .refresh = 0,
- .xres = 640,
- .yres = 480,
- .pixclock = 40000,
- .left_margin = 20,
- .right_margin = 20,
- .upper_margin = 19,
- .lower_margin = 19,
- .hsync_len = 20,
- .vsync_len = 10,
- .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
- .vmode = FB_VMODE_NONINTERLACED,
- },
- .width = -1,
- .height = -1,
- .tim2 = TIM2_BCD,
- .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
- .caps = CLCD_CAP_5551,
- .fixedtimings = 1,
- .connector = IMPD1_CTRL_DISP_LCD,
- .bpp = 16,
- .grayscale = 0,
-};
-#endif
-
/*
* Disable all display connectors on the interface module.
*/
@@ -206,51 +82,22 @@ static void impd1fb_clcd_enable(struct clcd_fb *fb)
fb->panel->connector | IMPD1_CTRL_DISP_ENABLE);
}
-static int impd1fb_clcd_setup(struct clcd_fb *fb)
-{
- unsigned long framebase = fb->dev->res.start + 0x01000000;
- unsigned long framesize = SZ_1M;
- int ret = 0;
+#define PANEL "PROSPECTOR"
- fb->panel = &PANELTYPE;
-
- if (!request_mem_region(framebase, framesize, "clcd framebuffer")) {
- printk(KERN_ERR "IM-PD1: unable to reserve framebuffer\n");
- return -EBUSY;
- }
-
- fb->fb.screen_base = ioremap(framebase, framesize);
- if (!fb->fb.screen_base) {
- printk(KERN_ERR "IM-PD1: unable to map framebuffer\n");
- ret = -ENOMEM;
- goto free_buffer;
- }
-
- fb->fb.fix.smem_start = framebase;
- fb->fb.fix.smem_len = framesize;
-
- return 0;
-
- free_buffer:
- release_mem_region(framebase, framesize);
- return ret;
-}
-
-static int impd1fb_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
+static int impd1fb_clcd_setup(struct clcd_fb *fb)
{
- unsigned long start, size;
+ fb->panel = versatile_clcd_get_panel(PANEL);
- start = vma->vm_pgoff + (fb->fb.fix.smem_start >> PAGE_SHIFT);
- size = vma->vm_end - vma->vm_start;
+ if (!fb->panel)
+ return -EINVAL;
- return remap_pfn_range(vma, vma->vm_start, start, size,
- vma->vm_page_prot);
-}
+ if (!strcmp(PANEL, "VGA") || !strcmp(PANEL, "SVGA") ||
+ !strcmp(PANEL, "XVGA"))
+ fb->panel->connector = IMPD1_CTRL_DISP_VGA;
+ else
+ fb->panel->connector = IMPD1_CTRL_DISP_LCD;
-static void impd1fb_clcd_remove(struct clcd_fb *fb)
-{
- iounmap(fb->fb.screen_base);
- release_mem_region(fb->fb.fix.smem_start, fb->fb.fix.smem_len);
+ return versatile_clcd_setup_dma(fb, SZ_1M);
}
static struct clcd_board impd1_clcd_data = {
@@ -261,8 +108,8 @@ static struct clcd_board impd1_clcd_data = {
.disable = impd1fb_clcd_disable,
.enable = impd1fb_clcd_enable,
.setup = impd1fb_clcd_setup,
- .mmap = impd1fb_clcd_mmap,
- .remove = impd1fb_clcd_remove,
+ .mmap = versatile_clcd_mmap_dma,
+ .remove = versatile_clcd_remove_dma,
};
struct impd1_device {
diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
index 7a8afcd4573e..293499981031 100644
--- a/drivers/video/fbdev/amba-clcd-versatile.c
+++ b/drivers/video/fbdev/amba-clcd-versatile.c
@@ -28,6 +28,31 @@ static struct clcd_panel vga = {
.bpp = 16,
};
+static struct clcd_panel svga = {
+ .mode = {
+ .name = "SVGA",
+ .refresh = 0,
+ .xres = 800,
+ .yres = 600,
+ .pixclock = 27778,
+ .left_margin = 20,
+ .right_margin = 20,
+ .upper_margin = 5,
+ .lower_margin = 5,
+ .hsync_len = 164,
+ .vsync_len = 62,
+ .sync = 0,
+ .vmode = FB_VMODE_NONINTERLACED,
+ },
+ .width = -1,
+ .height = -1,
+ .tim2 = TIM2_BCD,
+ .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
+ .caps = CLCD_CAP_5551,
+ .bpp = 16,
+ .grayscale = 0,
+};
+
static struct clcd_panel xvga = {
.mode = {
.name = "XVGA",
@@ -126,12 +151,67 @@ static struct clcd_panel epson_l2f50113t00 = {
.bpp = 16,
};
+static struct clcd_panel prospector = {
+ .mode = {
+ .name = "PROSPECTOR",
+ .refresh = 0,
+ .xres = 640,
+ .yres = 480,
+ .pixclock = 40000,
+ .left_margin = 33,
+ .right_margin = 64,
+ .upper_margin = 36,
+ .lower_margin = 7,
+ .hsync_len = 64,
+ .vsync_len = 25,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ },
+ .width = -1,
+ .height = -1,
+ .tim2 = TIM2_BCD,
+ .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
+ .caps = CLCD_CAP_5551,
+ .fixedtimings = 1,
+ .bpp = 16,
+ .grayscale = 0,
+};
+
+static struct clcd_panel ltm10c209 = {
+ .mode = {
+ .name = "LTM10C209",
+ .refresh = 0,
+ .xres = 640,
+ .yres = 480,
+ .pixclock = 40000,
+ .left_margin = 20,
+ .right_margin = 20,
+ .upper_margin = 19,
+ .lower_margin = 19,
+ .hsync_len = 20,
+ .vsync_len = 10,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED,
+ },
+ .width = -1,
+ .height = -1,
+ .tim2 = TIM2_BCD,
+ .cntl = CNTL_LCDTFT | CNTL_LCDVCOMP(1),
+ .caps = CLCD_CAP_5551,
+ .fixedtimings = 1,
+ .bpp = 16,
+ .grayscale = 0,
+};
+
static struct clcd_panel *panels[] = {
&vga,
+ &svga,
&xvga,
&sanyo_tm38qv67a02a,
&sanyo_2_5_in,
&epson_l2f50113t00,
+ &prospector,
+ <m10c209,
};
struct clcd_panel *versatile_clcd_get_panel(const char *name)
--
2.4.3
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Wei Liu @ 2015-07-29 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55B8BA9A.8000502@citrix.com>
On Wed, Jul 29, 2015 at 12:35:54PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 29/07/15 11:13, Wei Liu wrote:
> > On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
> > [...]
> >> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> >> index 7d50711..3b7b7c3 100644
> >> --- a/drivers/net/xen-netback/netback.c
> >> +++ b/drivers/net/xen-netback/netback.c
> >> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
> >> } else {
> >> copy_gop->source.domid = DOMID_SELF;
> >> copy_gop->source.u.gmfn > >> - virt_to_mfn(page_address(page));
> >> + virt_to_gfn(page_address(page));
> >> }
> >> copy_gop->source.offset = offset;
> >>
> >> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
> >> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
> >>
> >> queue->tx_copy_ops[*copy_ops].dest.u.gmfn > >> - virt_to_mfn(skb->data);
> >> + virt_to_gfn(skb->data);
> >> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> >> queue->tx_copy_ops[*copy_ops].dest.offset > >> offset_in_page(skb->data);
> >
> > Reviewed-by: Wei Liu <wei.liu2@citrix.com>
> >
> > One possible improvement is to change gmfn in copy_gop to gfn as well.
> > But that's outside of netback code.
>
> The structure gnttab_copy is part of the hypervisor interface. Is it
> fine to differ on the naming between Xen and Linux?
>
> Or maybe we could do the change in the public headers in Xen repo too.
> Is it fine to do field renaming in public headers?
>
Oh well. Never mind then. I mistook that structure as internal to Linux.
Wei.
> Regards,
>
> --
> Julien Grall
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: David Vrabel @ 2015-07-29 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55B8BA9A.8000502@citrix.com>
On 29/07/15 12:35, Julien Grall wrote:
> Hi Wei,
>
> On 29/07/15 11:13, Wei Liu wrote:
>> On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
>> [...]
>>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>>> index 7d50711..3b7b7c3 100644
>>> --- a/drivers/net/xen-netback/netback.c
>>> +++ b/drivers/net/xen-netback/netback.c
>>> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
>>> } else {
>>> copy_gop->source.domid = DOMID_SELF;
>>> copy_gop->source.u.gmfn >>> - virt_to_mfn(page_address(page));
>>> + virt_to_gfn(page_address(page));
>>> }
>>> copy_gop->source.offset = offset;
>>>
>>> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
>>> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>>>
>>> queue->tx_copy_ops[*copy_ops].dest.u.gmfn >>> - virt_to_mfn(skb->data);
>>> + virt_to_gfn(skb->data);
>>> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
>>> queue->tx_copy_ops[*copy_ops].dest.offset >>> offset_in_page(skb->data);
>>
>> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
>>
>> One possible improvement is to change gmfn in copy_gop to gfn as well.
>> But that's outside of netback code.
>
> The structure gnttab_copy is part of the hypervisor interface. Is it
> fine to differ on the naming between Xen and Linux?
>
> Or maybe we could do the change in the public headers in Xen repo too.
> Is it fine to do field renaming in public headers?
I think this series should not alter than Xen API.
David
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-07-29 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150729101323.GW5111@zion.uk.xensource.com>
Hi Wei,
On 29/07/15 11:13, Wei Liu wrote:
> On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
> [...]
>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>> index 7d50711..3b7b7c3 100644
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
>> } else {
>> copy_gop->source.domid = DOMID_SELF;
>> copy_gop->source.u.gmfn >> - virt_to_mfn(page_address(page));
>> + virt_to_gfn(page_address(page));
>> }
>> copy_gop->source.offset = offset;
>>
>> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
>> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>>
>> queue->tx_copy_ops[*copy_ops].dest.u.gmfn >> - virt_to_mfn(skb->data);
>> + virt_to_gfn(skb->data);
>> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
>> queue->tx_copy_ops[*copy_ops].dest.offset >> offset_in_page(skb->data);
>
> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
>
> One possible improvement is to change gmfn in copy_gop to gfn as well.
> But that's outside of netback code.
The structure gnttab_copy is part of the hypervisor interface. Is it
fine to differ on the naming between Xen and Linux?
Or maybe we could do the change in the public headers in Xen repo too.
Is it fine to do field renaming in public headers?
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-07-29 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7DDBB5@SJEXCHMB05.corp.ad.broadcom.com>
Hi Chris,
On 28/07/15 20:39, Chris (Christopher) Brand wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN is meant,
>> I suspect this is because the first support for Xen was for PV. This brough some
> Typo : "brought"
> Perhaps "resulted in" would be better ?
>
>> misimplementation of helpers on ARM and make the developper confused the expected behavior.
> Typo: "developer".
> I'd also suggest "...and confused developers about the...".
>
> [...]
>
>> For clarity and avoid new confusion, replace any reference of mfn into gnf in any helpers used by PV drivers.
> Typo : "gfn"
> I'd suggest "...replace any reference to mfn with gfn..."
>
> [...]
Thanks for telling me the typoes. I will fix it in the next version of
this series.
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-07-29 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55B7D40B.5080903@oracle.com>
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
> On 07/28/2015 11:02 AM, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>
>
>
>
>> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned
>> long pfn)
>> struct mmuext_op op;
>>
>> op.cmd = level;
>> - op.arg1.mfn = pfn_to_mfn(pfn);
>> + op.arg1.mfn = pfn_to_gfn(pfn);
>
>
> This looks slightly odd. It is correct but given that purpose of this
> series is to make things more clear perhaps we can add another union
> member (gfn) to mmuext_op.arg1?
>
> (Of course, the hypervisor will continue referring to mfn which could
> still be confusing)
This operation is only used for PV guests, right?
IHMO re-introducing pfn_to_mfn for PV-guests only (i.e with a BUG_ON to
ensure no usage for auto-translated guest) would be the best solution.
It would avoid to have different name than the hypersivor one in the
hypercall interface. It will also make clear that virt_to_machine & co
is only PV specific.
I though doing this but I preferred to defer it to x86 expert as my
knowledge for x86 Xen is very limited. I don't know where it's more
suitable to use MFN or GFN. I guess this file (mmu.c) is mostly PV specific?
Would something like below fine for you?
static inline unsigned long pfn_to_mfn(unsigned long pfn)
{
unsigned long mfn;
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
mfn = __pfn_to_mfn(pfn);
if (mfn != INVALID_P2M_ENTRY)
mfn &= ~(FOREIGN_FRAME_BIT | IDENTITY_FRAME_BIT);
return mfn;
}
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
Similar splitting would be done for gfn_to_pfn and mfn_to_pfn.
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-07-29 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55B7B8D2.5060107@citrix.com>
On 28/07/15 18:16, David Vrabel wrote:
> On 28/07/15 16:02, Julien Grall wrote:
>> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
>> is meant, I suspect this is because the first support for Xen was for
>> PV. This brough some misimplementation of helpers on ARM and make the
>> developper confused the expected behavior.
>
> For the benefit of other subsystem maintainers, this is a purely
> mechanical change in Xen-specific terminology. It doesn't need reviews
> or acks from non-Xen people (IMO).
>
>> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>>
>> For clarity and avoid new confusion, replace any reference of mfn into
>> gnf in any helpers used by PV drivers.
>>
>> Take also the opportunity to simplify simple construction such
>> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
>> will come in follow-up patches.
>>
>> I think it may be possible to do further clean up in the x86 code to
>> ensure that helpers returning machine address (such as virt_address) is
>> not used by no auto-translated guests. I will let x86 xen expert doing
>> it.
>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
>
> It looks a bit odd to use GFN in some of the PV code where the
> hypervisor API uses MFN but overall I think using the correct
> terminology where possible is best. But I'd like to have Boris's or
> Konrad's opinion on this.
I was thinking to introduce mfn_to_pfn & co which would be used only for
PV-guest (a BUG_ON would be here to ensure it) and hypercall related.
I didn't do it as I haven't much knowledge on x86 Xen and was able to
decide where I have to use pfn_to_mfn.
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH 0/8] Use correctly the Xen memory terminologies in Linux
From: Julien Grall @ 2015-07-29 11:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, stefano.stabellini, linux-kernel, Boris Ostrovsky,
David Vrabel, Dmitry Torokhov, Greg Kroah-Hartman, H. Peter Anvin,
Ingo Molnar, James E.J. Bottomley,
Jean-Christophe Plagniol-Villard, Jiri Slaby, Juergen Gross,
Konrad Rzeszutek Wilk, linux-api, linux-arm-kernel, linux-fbdev,
linux-input, linuxppc-dev, linux-scsi, netdev,
Roger Pau Monné, Russell King
In-Reply-To: <1438095769-2560-1-git-send-email-julien.grall@citrix.com>
On 28/07/15 16:02, Julien Grall wrote:
> Hi all,
>
> This patch series aims to use the memory terminologies described in
> include/linux/mm.h [1] for Linux xen code.
I mistakenly wrote the wrong include here. It should be include/xen/mm.h
from the Xen tree:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;hç58ed14f390342513405dd766e874934573e6cb
Regards,
--
Julien Grall
^ permalink raw reply
* Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Wei Liu @ 2015-07-29 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
On Tue, Jul 28, 2015 at 04:02:45PM +0100, Julien Grall wrote:
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 7d50711..3b7b7c3 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
> } else {
> copy_gop->source.domid = DOMID_SELF;
> copy_gop->source.u.gmfn > - virt_to_mfn(page_address(page));
> + virt_to_gfn(page_address(page));
> }
> copy_gop->source.offset = offset;
>
> @@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
> queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
>
> queue->tx_copy_ops[*copy_ops].dest.u.gmfn > - virt_to_mfn(skb->data);
> + virt_to_gfn(skb->data);
> queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
> queue->tx_copy_ops[*copy_ops].dest.offset > offset_in_page(skb->data);
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
One possible improvement is to change gmfn in copy_gop to gfn as well.
But that's outside of netback code.
Wei.
^ permalink raw reply
* Re: Congrats !
From: Nicolas PERRON @ 2015-07-29 8:38 UTC (permalink / raw)
To: Nicolas PERRON
In-Reply-To: <20150729030841.14961o6ihamg5pc0@courriel.upmc.fr>
Quoting Nicolas PERRON <nicolas.perron@upmc.fr>:
> Private Donation for you; contact your benefactor with your donation
> code RBL15USJHS (jhuntsman17@yahoo.com) for claim
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH v2 0/22] On-demand device probing
From: Rafael J. Wysocki @ 2015-07-29 0:36 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Warren,
Javier Martinez Canillas, Mark Brown, Thierry Reding,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Dmitry Torokhov, devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Terje Bergström,
Len Brown, Rob Herring, David Airlie, Michael Turquette,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1438089593-7696-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Tuesday, July 28, 2015 03:19:31 PM Tomeu Vizoso wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
>
> While reading the thread [1] that Alexander Holler started with his
> series to make probing order deterministic, it occurred to me that it
> should be possible to achieve the same by probing devices as they are
> referenced by other devices.
>
> This basically reuses the information that is already implicit in the
> probe() implementations, saving us from refactoring existing drivers or
> adding information to DTBs.
>
> During review of v1 of this series Linus Walleij suggested that it
> should be the device driver core to make sure that dependencies are
> ready before probing a device. I gave this idea a try [2] but Mark Brown
> pointed out to the logic duplication between the resource acquisition
> and dependency discovery code paths (though I think it's fairly minor).
>
> To address that code duplication I experimented with Arnd's devm_probe
> [3] concept of having drivers declare their dependencies instead of
> acquiring them during probe, and while it worked [4], I don't think we
> end up winning anything when compared to just probing devices on-demand
> from resource getters.
>
> One remaining objection is to the "sprinkling" of calls to
> fwnode_ensure_device() in the resource getters of each subsystem, but I
> think it's the right thing to do given that the storage of resources is
> currently subsystem-specific.
>
> We could avoid the above by moving resource storage into the core, but I
> don't think there's a compelling case for that.
>
> I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
> and these patches were enough to eliminate all the deferred probes
> (except one in PandaBoard because omap_dma_system doesn't have a
> firmware node as of yet).
>
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.
Can you trim your CC list somewhat, please?
I'm definitely going to look at this, but not before then next week.
Sorry about that.
Thanks,
Rafael
^ permalink raw reply
* Re: [Xen-devel] [PATCH 0/8] Use correctly the Xen memory terminologies in Linux
From: Andrew Cooper @ 2015-07-28 21:12 UTC (permalink / raw)
To: H. Peter Anvin, Julien Grall, xen-devel
Cc: linux-fbdev, x86, netdev, Jiri Slaby, Thomas Gleixner,
Russell King, linux-scsi, Tomi Valkeinen, stefano.stabellini,
Ingo Molnar, linux-input, Jean-Christophe Plagniol-Villard,
ian.campbell, James E.J. Bottomley, Boris Ostrovsky,
linux-arm-kernel, Juergen Gross, Wei Liu, Greg Kroah-Hartman,
Dmitry Torokhov, linux-kernel, David Vrabel, linux-api,
linuxppc-dev
In-Reply-To: <55B7EECD.8050605@zytor.com>
On 28/07/15 22:06, H. Peter Anvin wrote:
> On 07/28/2015 08:02 AM, Julien Grall wrote:
>> Hi all,
>>
>> This patch series aims to use the memory terminologies described in
>> include/linux/mm.h [1] for Linux xen code.
>>
>> Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
>> first support of Xen was for PV. This has brought some misimplementation
>> of memory helpers on ARM and make the developper confused about the expected
>> behavior.
>>
>> For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
>> Although, if we look at the implementation on x86, it's returning a GFN.
>> Most of the callers are also using it this way.
>>
>> The first 2 patches of this series is ARM related in order to remove
>> PV specific helpers which should not be used and fixing the implementation of
>> pfn_to_mfn.
>>
>> The rest of the series is here rename most of the usage in the common code
>> of MFN to GFN. I also took the opportunity to replace most of the call to
>> pfn_to_gfn in the common code by page_to_gfn avoid construction such
>> as pfn_to_gfn(page_to_pfn(...).
>>
>> Note the one xen-blkfront will be dropped by 64K series [2], I can include it
>> if necessary.
>>
> Can we actually get some documentation for Xen before starting to change
> names around?
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;hç58ed14f390342513405dd766e874934573e6cb
~Andrew
^ permalink raw reply
* Re: [PATCH 0/8] Use correctly the Xen memory terminologies in Linux
From: H. Peter Anvin @ 2015-07-28 21:06 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: linux-fbdev, x86, netdev, Jiri Slaby, Thomas Gleixner,
Russell King, linux-scsi, Tomi Valkeinen, stefano.stabellini,
Ingo Molnar, linux-input, Jean-Christophe Plagniol-Villard,
ian.campbell, Konrad Rzeszutek Wilk, James E.J. Bottomley,
Boris Ostrovsky, linux-arm-kernel, Juergen Gross, Wei Liu,
Greg Kroah-Hartman, Dmitry Torokhov, linux-kernel, David Vrabel,
linux-api, linuxppc-dev
In-Reply-To: <1438095769-2560-1-git-send-email-julien.grall@citrix.com>
On 07/28/2015 08:02 AM, Julien Grall wrote:
> Hi all,
>
> This patch series aims to use the memory terminologies described in
> include/linux/mm.h [1] for Linux xen code.
>
> Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
> first support of Xen was for PV. This has brought some misimplementation
> of memory helpers on ARM and make the developper confused about the expected
> behavior.
>
> For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
> Most of the callers are also using it this way.
>
> The first 2 patches of this series is ARM related in order to remove
> PV specific helpers which should not be used and fixing the implementation of
> pfn_to_mfn.
>
> The rest of the series is here rename most of the usage in the common code
> of MFN to GFN. I also took the opportunity to replace most of the call to
> pfn_to_gfn in the common code by page_to_gfn avoid construction such
> as pfn_to_gfn(page_to_pfn(...).
>
> Note the one xen-blkfront will be dropped by 64K series [2], I can include it
> if necessary.
>
Can we actually get some documentation for Xen before starting to change
names around?
-hpa
^ permalink raw reply
* RE: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Chris (Christopher) Brand @ 2015-07-28 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
PiBCYXNlZCBvbiBpbmNsdWRlL3hlbi9tbS5oIFsxXSwgTGludXggaXMgbWlzdGFrZW5seSB1c2lu
ZyBNRk4gd2hlbiBHRk4gaXMgbWVhbnQsDQo+IEkgc3VzcGVjdCB0aGlzIGlzIGJlY2F1c2UgdGhl
IGZpcnN0IHN1cHBvcnQgZm9yIFhlbiB3YXMgZm9yIFBWLiBUaGlzIGJyb3VnaCBzb21lDQpUeXBv
IDogImJyb3VnaHQiDQpQZXJoYXBzICJyZXN1bHRlZCBpbiIgd291bGQgYmUgYmV0dGVyID8NCg0K
PiBtaXNpbXBsZW1lbnRhdGlvbiBvZiBoZWxwZXJzIG9uIEFSTSBhbmQgbWFrZSB0aGUgZGV2ZWxv
cHBlciBjb25mdXNlZCB0aGUgZXhwZWN0ZWQgYmVoYXZpb3IuDQpUeXBvOiAiZGV2ZWxvcGVyIi4N
CkknZCBhbHNvIHN1Z2dlc3QgIi4uLmFuZCBjb25mdXNlZCBkZXZlbG9wZXJzIGFib3V0IHRoZS4u
LiIuDQoNClsuLi5dDQoNCj4gRm9yIGNsYXJpdHkgYW5kIGF2b2lkIG5ldyBjb25mdXNpb24sIHJl
cGxhY2UgYW55IHJlZmVyZW5jZSBvZiBtZm4gaW50byBnbmYgaW4gYW55IGhlbHBlcnMgdXNlZCBi
eSBQViBkcml2ZXJzLg0KVHlwbyA6ICJnZm4iDQpJJ2Qgc3VnZ2VzdCAiLi4ucmVwbGFjZSBhbnkg
cmVmZXJlbmNlIHRvIG1mbiB3aXRoIGdmbi4uLiINCg0KWy4uLl0NCg0KQ2hyaXMNCg0K
^ permalink raw reply
* Re: [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Boris Ostrovsky @ 2015-07-28 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
On 07/28/2015 11:02 AM, Julien Grall wrote:
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> is meant, I suspect this is because the first support for Xen was for
> PV. This brough some misimplementation of helpers on ARM and make the
> developper confused the expected behavior.
>
> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
>
> For clarity and avoid new confusion, replace any reference of mfn into
> gnf in any helpers used by PV drivers.
> @@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned long pfn)
> struct mmuext_op op;
>
> op.cmd = level;
> - op.arg1.mfn = pfn_to_mfn(pfn);
> + op.arg1.mfn = pfn_to_gfn(pfn);
This looks slightly odd. It is correct but given that purpose of this
series is to make things more clear perhaps we can add another union
member (gfn) to mmuext_op.arg1?
(Of course, the hypervisor will continue referring to mfn which could
still be confusing)
>
> xen_extend_mmuext_op(&op);
> }
> @@ -1323,7 +1323,7 @@ static void __xen_write_cr3(bool kernel, unsigned long cr3)
> trace_xen_mmu_write_cr3(kernel, cr3);
>
> if (cr3)
> - mfn = pfn_to_mfn(PFN_DOWN(cr3));
> + mfn = pfn_to_gfn(PFN_DOWN(cr3));
Here too. And further down, thoughout this patch.
-boris
^ permalink raw reply
* Re: [Xen-devel] [PATCH 6/8] video/xen-fbfront: Further s/MFN/GFN clean-up
From: David Vrabel @ 2015-07-28 17:16 UTC (permalink / raw)
To: Julien Grall, xen-devel
Cc: linux-fbdev, ian.campbell, stefano.stabellini, linux-kernel,
Tomi Valkeinen, David Vrabel, Jean-Christophe Plagniol-Villard
In-Reply-To: <1438095769-2560-7-git-send-email-julien.grall@citrix.com>
On 28/07/15 16:02, Julien Grall wrote:
> The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
> all the occurence of MFN to GFN.
>
> Also take the opportunity to replace to usage of pfn_to_gfn by
> page_to_pfn.
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
David
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: David Vrabel @ 2015-07-28 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438095769-2560-5-git-send-email-julien.grall@citrix.com>
On 28/07/15 16:02, Julien Grall wrote:
> Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
> is meant, I suspect this is because the first support for Xen was for
> PV. This brough some misimplementation of helpers on ARM and make the
> developper confused the expected behavior.
For the benefit of other subsystem maintainers, this is a purely
mechanical change in Xen-specific terminology. It doesn't need reviews
or acks from non-Xen people (IMO).
> For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
> Although, if we look at the implementation on x86, it's returning a GFN.
>
> For clarity and avoid new confusion, replace any reference of mfn into
> gnf in any helpers used by PV drivers.
>
> Take also the opportunity to simplify simple construction such
> as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
> will come in follow-up patches.
>
> I think it may be possible to do further clean up in the x86 code to
> ensure that helpers returning machine address (such as virt_address) is
> not used by no auto-translated guests. I will let x86 xen expert doing
> it.
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
It looks a bit odd to use GFN in some of the PV code where the
hypervisor API uses MFN but overall I think using the correct
terminology where possible is best. But I'd like to have Boris's or
Konrad's opinion on this.
David
^ permalink raw reply
* [PATCH 6/8] video/xen-fbfront: Further s/MFN/GFN clean-up
From: Julien Grall @ 2015-07-28 15:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, stefano.stabellini, linux-kernel, Julien Grall,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, David Vrabel,
linux-fbdev
In-Reply-To: <1438095769-2560-1-git-send-email-julien.grall@citrix.com>
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
page_to_pfn.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/xen-fbfront.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
index 25e3cce..3112168 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -46,7 +46,7 @@ struct xenfb_info {
int nr_pages;
int irq;
struct xenfb_page *page;
- unsigned long *mfns;
+ unsigned long *gfns;
int update_wanted; /* XENFB_TYPE_UPDATE wanted */
int feature_resize; /* XENFB_TYPE_RESIZE ok */
struct xenfb_resize resize; /* protected by resize_lock */
@@ -402,8 +402,8 @@ static int xenfb_probe(struct xenbus_device *dev,
info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
- info->mfns = vmalloc(sizeof(unsigned long) * info->nr_pages);
- if (!info->mfns)
+ info->gfns = vmalloc(sizeof(unsigned long) * info->nr_pages);
+ if (!info->gfns)
goto error_nomem;
/* set up shared page */
@@ -530,29 +530,29 @@ static int xenfb_remove(struct xenbus_device *dev)
framebuffer_release(info->fb_info);
}
free_page((unsigned long)info->page);
- vfree(info->mfns);
+ vfree(info->gfns);
vfree(info->fb);
kfree(info);
return 0;
}
-static unsigned long vmalloc_to_mfn(void *address)
+static unsigned long vmalloc_to_gfn(void *address)
{
- return pfn_to_gfn(vmalloc_to_pfn(address));
+ return page_to_gfn(vmalloc_to_page(address));
}
static void xenfb_init_shared_page(struct xenfb_info *info,
struct fb_info *fb_info)
{
int i;
- int epd = PAGE_SIZE / sizeof(info->mfns[0]);
+ int epd = PAGE_SIZE / sizeof(info->gfns[0]);
for (i = 0; i < info->nr_pages; i++)
- info->mfns[i] = vmalloc_to_mfn(info->fb + i * PAGE_SIZE);
+ info->gfns[i] = vmalloc_to_gfn(info->fb + i * PAGE_SIZE);
for (i = 0; i * epd < info->nr_pages; i++)
- info->page->pd[i] = vmalloc_to_mfn(&info->mfns[i * epd]);
+ info->page->pd[i] = vmalloc_to_gfn(&info->gfns[i * epd]);
info->page->width = fb_info->var.xres;
info->page->height = fb_info->var.yres;
--
2.1.4
^ permalink raw reply related
* [PATCH 4/8] xen: Use the correctly the Xen memory terminologies
From: Julien Grall @ 2015-07-28 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1438095769-2560-1-git-send-email-julien.grall@citrix.com>
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This brough some misimplementation of helpers on ARM and make the
developper confused the expected behavior.
For instance, with pfn_to_mfn, we expect to get an MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
For clarity and avoid new confusion, replace any reference of mfn into
gnf in any helpers used by PV drivers.
Take also the opportunity to simplify simple construction such
as pfn_to_mfn(page_to_pfn(page)) into page_to_gfn. More complex clean up
will come in follow-up patches.
I think it may be possible to do further clean up in the x86 code to
ensure that helpers returning machine address (such as virt_address) is
not used by no auto-translated guests. I will let x86 xen expert doing
it.
[1] Xen tree: e758ed14f390342513405dd766e874934573e6cb
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: "James E.J. Bottomley" <JBottomley@odin.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-input@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
arch/arm/include/asm/xen/page.h | 13 +++++++------
arch/x86/include/asm/xen/page.h | 30 ++++++++++++++++--------------
arch/x86/xen/enlighten.c | 4 ++--
arch/x86/xen/mmu.c | 16 ++++++++--------
arch/x86/xen/p2m.c | 32 ++++++++++++++++----------------
arch/x86/xen/setup.c | 12 ++++++------
arch/x86/xen/smp.c | 4 ++--
arch/x86/xen/suspend.c | 8 ++++----
drivers/block/xen-blkfront.c | 6 +++---
drivers/input/misc/xen-kbdfront.c | 4 ++--
drivers/net/xen-netback/netback.c | 4 ++--
drivers/net/xen-netfront.c | 8 ++++----
drivers/scsi/xen-scsifront.c | 8 +++-----
drivers/tty/hvc/hvc_xen.c | 5 +++--
drivers/video/fbdev/xen-fbfront.c | 4 ++--
drivers/xen/balloon.c | 2 +-
drivers/xen/events/events_base.c | 2 +-
drivers/xen/events/events_fifo.c | 4 ++--
drivers/xen/gntalloc.c | 3 ++-
drivers/xen/manage.c | 2 +-
drivers/xen/tmem.c | 4 ++--
drivers/xen/xenbus/xenbus_client.c | 2 +-
drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 8 +++-----
include/xen/page.h | 4 ++--
25 files changed, 96 insertions(+), 95 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 493471f..f542f68 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -34,14 +34,15 @@ typedef struct xpaddr {
unsigned long __pfn_to_mfn(unsigned long pfn);
extern struct rb_root phys_to_mach;
-static inline unsigned long pfn_to_mfn(unsigned long pfn)
+/* Pseudo-physical <-> Guest conversion */
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
return pfn;
}
-static inline unsigned long mfn_to_pfn(unsigned long mfn)
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
{
- return mfn;
+ return gfn;
}
/* Pseudo-physical <-> DMA conversion */
@@ -65,9 +66,9 @@ static inline unsigned long dfn_to_pfn(unsigned long dfn)
#define dfn_to_local_pfn(dfn) dfn_to_pfn(dfn)
-/* VIRT <-> MACHINE conversion */
-#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
-#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+/* VIRT <-> GUEST conversion */
+#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
+#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << PAGE_SHIFT))
/* Only used in PV code. However ARM guest is always assimilated as HVM. */
static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 046e91a..72d9f15 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -99,7 +99,7 @@ static inline unsigned long __pfn_to_mfn(unsigned long pfn)
return mfn;
}
-static inline unsigned long pfn_to_mfn(unsigned long pfn)
+static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
unsigned long mfn;
@@ -145,23 +145,23 @@ static inline unsigned long mfn_to_pfn_no_overrides(unsigned long mfn)
return pfn;
}
-static inline unsigned long mfn_to_pfn(unsigned long mfn)
+static inline unsigned long gfn_to_pfn(unsigned long gfn)
{
unsigned long pfn;
if (xen_feature(XENFEAT_auto_translated_physmap))
- return mfn;
+ return gfn;
- pfn = mfn_to_pfn_no_overrides(mfn);
- if (__pfn_to_mfn(pfn) != mfn)
+ pfn = mfn_to_pfn_no_overrides(gfn);
+ if (__pfn_to_mfn(pfn) != gfn)
pfn = ~0;
/*
* pfn is ~0 if there are no entries in the m2p for mfn or the
* entry doesn't map back to the mfn.
*/
- if (pfn = ~0 && __pfn_to_mfn(mfn) = IDENTITY_FRAME(mfn))
- pfn = mfn;
+ if (pfn = ~0 && __pfn_to_mfn(gfn) = IDENTITY_FRAME(gfn))
+ pfn = gfn;
return pfn;
}
@@ -169,18 +169,18 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
static inline xmaddr_t phys_to_machine(xpaddr_t phys)
{
unsigned offset = phys.paddr & ~PAGE_MASK;
- return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+ return XMADDR(PFN_PHYS(pfn_to_gfn(PFN_DOWN(phys.paddr))) | offset);
}
static inline xpaddr_t machine_to_phys(xmaddr_t machine)
{
unsigned offset = machine.maddr & ~PAGE_MASK;
- return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+ return XPADDR(PFN_PHYS(gfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
}
/* Pseudo-physical <-> DMA conversion */
-#define pfn_to_dfn(pfn) pfn_to_mfn(pfn)
-#define dfn_to_pfn(dfn) mfn_to_pfn(dfn)
+#define pfn_to_dfn(pfn) pfn_to_gfn(pfn)
+#define dfn_to_pfn(dfn) gfn_to_pfn(dfn)
/*
* We detect special mappings in one of two ways:
@@ -209,7 +209,7 @@ static inline unsigned long dfn_to_local_pfn(unsigned long mfn)
if (xen_feature(XENFEAT_auto_translated_physmap))
return mfn;
- pfn = mfn_to_pfn(mfn);
+ pfn = gfn_to_pfn(mfn);
if (__pfn_to_mfn(pfn) != mfn)
return -1; /* force !pfn_valid() */
return pfn;
@@ -218,8 +218,10 @@ static inline unsigned long dfn_to_local_pfn(unsigned long mfn)
/* VIRT <-> MACHINE conversion */
#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v))))
#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
-#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
-#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+/* VIRT <-> GUEST conversion */
+#define virt_to_gfn(v) (pfn_to_gfn(virt_to_pfn(v)))
+#define gfn_to_virt(m) (__va(gfn_to_pfn(m) << PAGE_SHIFT))
static inline unsigned long pte_mfn(pte_t pte)
{
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0b95c9b..a519b1b 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -573,7 +573,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
BUG_ON(ptep = NULL);
pfn = pte_pfn(*ptep);
- mfn = pfn_to_mfn(pfn);
+ mfn = pfn_to_gfn(pfn);
virt = __va(PFN_PHYS(pfn));
frames[f] = mfn;
@@ -610,7 +610,7 @@ static void __init xen_load_gdt_boot(const struct desc_ptr *dtr)
unsigned long pfn, mfn;
pfn = virt_to_pfn(va);
- mfn = pfn_to_mfn(pfn);
+ mfn = pfn_to_gfn(pfn);
pte = pfn_pte(pfn, PAGE_KERNEL_RO);
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index dd151b2..742b8d2 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -367,7 +367,7 @@ static pteval_t pte_mfn_to_pfn(pteval_t val)
{
if (val & _PAGE_PRESENT) {
unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
- unsigned long pfn = mfn_to_pfn(mfn);
+ unsigned long pfn = gfn_to_pfn(mfn);
pteval_t flags = val & PTE_FLAGS_MASK;
if (unlikely(pfn = ~0))
@@ -730,7 +730,7 @@ static void xen_do_pin(unsigned level, unsigned long pfn)
struct mmuext_op op;
op.cmd = level;
- op.arg1.mfn = pfn_to_mfn(pfn);
+ op.arg1.mfn = pfn_to_gfn(pfn);
xen_extend_mmuext_op(&op);
}
@@ -1323,7 +1323,7 @@ static void __xen_write_cr3(bool kernel, unsigned long cr3)
trace_xen_mmu_write_cr3(kernel, cr3);
if (cr3)
- mfn = pfn_to_mfn(PFN_DOWN(cr3));
+ mfn = pfn_to_gfn(PFN_DOWN(cr3));
else
mfn = 0;
@@ -1493,7 +1493,7 @@ static void __init pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
struct mmuext_op op;
op.cmd = cmd;
- op.arg1.mfn = pfn_to_mfn(pfn);
+ op.arg1.mfn = pfn_to_gfn(pfn);
if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
BUG();
}
@@ -1539,7 +1539,7 @@ static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
mcs = __xen_mc_entry(sizeof(*op));
op = mcs.args;
op->cmd = cmd;
- op->arg1.mfn = pfn_to_mfn(pfn);
+ op->arg1.mfn = pfn_to_gfn(pfn);
MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
}
@@ -1672,7 +1672,7 @@ static unsigned long __init m2p(phys_addr_t maddr)
phys_addr_t paddr;
maddr &= PTE_PFN_MASK;
- paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;
+ paddr = gfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;
return paddr;
}
@@ -2178,7 +2178,7 @@ static void xen_zap_pfn_range(unsigned long vaddr, unsigned int order,
mcs = __xen_mc_entry(0);
if (in_frames)
- in_frames[i] = virt_to_mfn(vaddr);
+ in_frames[i] = virt_to_gfn(vaddr);
MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);
@@ -2343,7 +2343,7 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
spin_lock_irqsave(&xen_reservation_lock, flags);
/* 1. Find start MFN of contiguous extent. */
- in_frame = virt_to_mfn(vstart);
+ in_frame = virt_to_gfn(vstart);
/* 2. Zap current PTEs. */
xen_zap_pfn_range(vstart, order, NULL, out_frames);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8b7f18e..9d23992d 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -30,14 +30,14 @@
* However not all entries are filled with MFNs. Specifically for all other
* leaf entries, or for the top root, or middle one, for which there is a void
* entry, we assume it is "missing". So (for example)
- * pfn_to_mfn(0x90909090)=INVALID_P2M_ENTRY.
+ * pfn_to_gfn(0x90909090)=INVALID_P2M_ENTRY.
* We have a dedicated page p2m_missing with all entries being
* INVALID_P2M_ENTRY. This page may be referenced multiple times in the p2m
* list/tree in case there are multiple areas with P2M_PER_PAGE invalid pfns.
*
* We also have the possibility of setting 1-1 mappings on certain regions, so
* that:
- * pfn_to_mfn(0xc0000)=0xc0000
+ * pfn_to_gfn(0xc0000)=0xc0000
*
* The benefit of this is, that we can assume for non-RAM regions (think
* PCI BARs, or ACPI spaces), we can create mappings easily because we
@@ -51,10 +51,10 @@
* identity value instead of dereferencing and returning INVALID_P2M_ENTRY.
* If the entry points to an allocated page, we just proceed as before and
* return the PFN. If the PFN has IDENTITY_FRAME_BIT set we unmask that in
- * appropriate functions (pfn_to_mfn).
+ * appropriate functions (pfn_to_gfn).
*
* The reason for having the IDENTITY_FRAME_BIT instead of just returning the
- * PFN is that we could find ourselves where pfn_to_mfn(pfn)=pfn for a
+ * PFN is that we could find ourselves where pfn_to_gfn(pfn)=pfn for a
* non-identity pfn. To protect ourselves against we elect to set (and get) the
* IDENTITY_FRAME_BIT on all identity mapped PFNs.
*/
@@ -129,7 +129,7 @@ static void p2m_top_mfn_init(unsigned long *top)
unsigned i;
for (i = 0; i < P2M_TOP_PER_PAGE; i++)
- top[i] = virt_to_mfn(p2m_mid_missing_mfn);
+ top[i] = virt_to_gfn(p2m_mid_missing_mfn);
}
static void p2m_top_mfn_p_init(unsigned long **top)
@@ -145,7 +145,7 @@ static void p2m_mid_mfn_init(unsigned long *mid, unsigned long *leaf)
unsigned i;
for (i = 0; i < P2M_MID_PER_PAGE; i++)
- mid[i] = virt_to_mfn(leaf);
+ mid[i] = virt_to_gfn(leaf);
}
static void p2m_init(unsigned long *p2m)
@@ -236,7 +236,7 @@ void __ref xen_build_mfn_list_list(void)
if (ptep = p2m_missing_pte || ptep = p2m_identity_pte) {
BUG_ON(mididx);
BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
- p2m_top_mfn[topidx] = virt_to_mfn(p2m_mid_missing_mfn);
+ p2m_top_mfn[topidx] = virt_to_gfn(p2m_mid_missing_mfn);
pfn += (P2M_MID_PER_PAGE - 1) * P2M_PER_PAGE;
continue;
}
@@ -248,7 +248,7 @@ void __ref xen_build_mfn_list_list(void)
p2m_top_mfn_p[topidx] = mid_mfn_p;
}
- p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
+ p2m_top_mfn[topidx] = virt_to_gfn(mid_mfn_p);
mid_mfn_p[mididx] = mfn;
}
}
@@ -261,7 +261,7 @@ void xen_setup_mfn_list_list(void)
BUG_ON(HYPERVISOR_shared_info = &xen_dummy_shared_info);
HYPERVISOR_shared_info->arch.pfn_to_mfn_frame_list_list - virt_to_mfn(p2m_top_mfn);
+ virt_to_gfn(p2m_top_mfn);
HYPERVISOR_shared_info->arch.max_pfn = xen_max_p2m_pfn;
}
@@ -531,7 +531,7 @@ static bool alloc_p2m(unsigned long pfn)
top_mfn_p = &p2m_top_mfn[topidx];
mid_mfn = ACCESS_ONCE(p2m_top_mfn_p[topidx]);
- BUG_ON(virt_to_mfn(mid_mfn) != *top_mfn_p);
+ BUG_ON(virt_to_gfn(mid_mfn) != *top_mfn_p);
if (mid_mfn = p2m_mid_missing_mfn) {
/* Separately check the mid mfn level */
@@ -545,12 +545,12 @@ static bool alloc_p2m(unsigned long pfn)
p2m_mid_mfn_init(mid_mfn, p2m_missing);
- missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
- mid_mfn_mfn = virt_to_mfn(mid_mfn);
+ missing_mfn = virt_to_gfn(p2m_mid_missing_mfn);
+ mid_mfn_mfn = virt_to_gfn(mid_mfn);
old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
if (old_mfn != missing_mfn) {
free_p2m_page(mid_mfn);
- mid_mfn = mfn_to_virt(old_mfn);
+ mid_mfn = gfn_to_virt(old_mfn);
} else {
p2m_top_mfn_p[topidx] = mid_mfn;
}
@@ -580,7 +580,7 @@ static bool alloc_p2m(unsigned long pfn)
set_pte(ptep,
pfn_pte(PFN_DOWN(__pa(p2m)), PAGE_KERNEL));
if (mid_mfn)
- mid_mfn[mididx] = virt_to_mfn(p2m);
+ mid_mfn[mididx] = virt_to_gfn(p2m);
p2m = NULL;
}
@@ -682,7 +682,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
continue;
if (map_ops[i].flags & GNTMAP_contains_pte) {
- pte = (pte_t *)(mfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
+ pte = (pte_t *)(gfn_to_virt(PFN_DOWN(map_ops[i].host_addr)) +
(map_ops[i].host_addr & ~PAGE_MASK));
mfn = pte_mfn(*pte);
} else {
@@ -690,7 +690,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
}
pfn = page_to_pfn(pages[i]);
- WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, "page must be ballooned");
+ WARN(pfn_to_gfn(pfn) != INVALID_P2M_ENTRY, "page must be ballooned");
if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn)))) {
ret = -ENOMEM;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 55f388e..4c2e91d 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -231,10 +231,10 @@ static void __init xen_set_identity_and_release_chunk(unsigned long start_pfn,
/* Release pages first. */
end = min(end_pfn, nr_pages);
for (pfn = start_pfn; pfn < end; pfn++) {
- unsigned long mfn = pfn_to_mfn(pfn);
+ unsigned long mfn = pfn_to_gfn(pfn);
/* Make sure pfn exists to start with */
- if (mfn = INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
+ if (mfn = INVALID_P2M_ENTRY || gfn_to_pfn(mfn) != pfn)
continue;
ret = xen_free_mfn(mfn);
@@ -313,7 +313,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
BUG_ON(xen_feature(XENFEAT_auto_translated_physmap));
- mfn_save = virt_to_mfn(buf);
+ mfn_save = virt_to_gfn(buf);
for (ident_pfn_iter = start_pfn, remap_pfn_iter = remap_pfn;
ident_pfn_iter < ident_end_pfn;
@@ -321,7 +321,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
chunk = (left < REMAP_SIZE) ? left : REMAP_SIZE;
/* Map first pfn to xen_remap_buf */
- mfn = pfn_to_mfn(ident_pfn_iter);
+ mfn = pfn_to_gfn(ident_pfn_iter);
set_pte_mfn(buf, mfn, PAGE_KERNEL);
/* Save mapping information in page */
@@ -329,7 +329,7 @@ static void __init xen_do_set_identity_and_remap_chunk(
xen_remap_buf.target_pfn = remap_pfn_iter;
xen_remap_buf.size = chunk;
for (i = 0; i < chunk; i++)
- xen_remap_buf.mfns[i] = pfn_to_mfn(ident_pfn_iter + i);
+ xen_remap_buf.mfns[i] = pfn_to_gfn(ident_pfn_iter + i);
/* Put remap buf into list. */
xen_remap_mfn = mfn;
@@ -473,7 +473,7 @@ void __init xen_remap_memory(void)
unsigned long pfn_s = ~0UL;
unsigned long len = 0;
- mfn_save = virt_to_mfn(buf);
+ mfn_save = virt_to_gfn(buf);
while (xen_remap_mfn != INVALID_P2M_ENTRY) {
/* Map the remap information */
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8648438..680f281 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -395,7 +395,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
gdt_mfn = arbitrary_virt_to_mfn(gdt);
make_lowmem_page_readonly(gdt);
- make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+ make_lowmem_page_readonly(gfn_to_virt(gdt_mfn));
ctxt->gdt_frames[0] = gdt_mfn;
ctxt->gdt_ents = GDT_ENTRIES;
@@ -429,7 +429,7 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
}
#endif
ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
- ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
+ ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_gfn(swapper_pg_dir));
if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
BUG();
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 53b4c08..60624e7 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -16,9 +16,9 @@ static void xen_pv_pre_suspend(void)
{
xen_mm_pin_all();
- xen_start_info->store_mfn = mfn_to_pfn(xen_start_info->store_mfn);
+ xen_start_info->store_mfn = gfn_to_pfn(xen_start_info->store_mfn);
xen_start_info->console.domU.mfn - mfn_to_pfn(xen_start_info->console.domU.mfn);
+ gfn_to_pfn(xen_start_info->console.domU.mfn);
BUG_ON(!irqs_disabled());
@@ -51,9 +51,9 @@ static void xen_pv_post_suspend(int suspend_cancelled)
if (suspend_cancelled) {
xen_start_info->store_mfn - pfn_to_mfn(xen_start_info->store_mfn);
+ pfn_to_gfn(xen_start_info->store_mfn);
xen_start_info->console.domU.mfn - pfn_to_mfn(xen_start_info->console.domU.mfn);
+ pfn_to_gfn(xen_start_info->console.domU.mfn);
} else {
#ifdef CONFIG_SMP
BUG_ON(xen_cpu_initialized_map = NULL);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 6d89ed3..2e541a4 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -247,7 +247,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
struct blkfront_info *info)
{
struct grant *gnt_list_entry;
- unsigned long buffer_mfn;
+ unsigned long buffer_gfn;
BUG_ON(list_empty(&info->grants));
gnt_list_entry = list_first_entry(&info->grants, struct grant,
@@ -266,10 +266,10 @@ static struct grant *get_grant(grant_ref_t *gref_head,
BUG_ON(!pfn);
gnt_list_entry->pfn = pfn;
}
- buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+ buffer_gfn = pfn_to_gfn(gnt_list_entry->pfn);
gnttab_grant_foreign_access_ref(gnt_list_entry->gref,
info->xbdev->otherend_id,
- buffer_mfn, 0);
+ buffer_gfn, 0);
return gnt_list_entry;
}
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 95599e4..23d0549 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -232,7 +232,7 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
struct xenbus_transaction xbt;
ret = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_mfn(info->page), 0);
+ virt_to_gfn(info->page), 0);
if (ret < 0)
return ret;
info->gref = ret;
@@ -255,7 +255,7 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
goto error_irqh;
}
ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
- virt_to_mfn(info->page));
+ virt_to_gfn(info->page));
if (ret)
goto error_xenbus;
ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 7d50711..3b7b7c3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -314,7 +314,7 @@ static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff *skb
} else {
copy_gop->source.domid = DOMID_SELF;
copy_gop->source.u.gmfn - virt_to_mfn(page_address(page));
+ virt_to_gfn(page_address(page));
}
copy_gop->source.offset = offset;
@@ -1284,7 +1284,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue *queue,
queue->tx_copy_ops[*copy_ops].source.offset = txreq.offset;
queue->tx_copy_ops[*copy_ops].dest.u.gmfn - virt_to_mfn(skb->data);
+ virt_to_gfn(skb->data);
queue->tx_copy_ops[*copy_ops].dest.domid = DOMID_SELF;
queue->tx_copy_ops[*copy_ops].dest.offset offset_in_page(skb->data);
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index f948c46..5cdab73 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -291,7 +291,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
struct sk_buff *skb;
unsigned short id;
grant_ref_t ref;
- unsigned long pfn;
+ unsigned long gfn;
struct xen_netif_rx_request *req;
skb = xennet_alloc_one_rx_buffer(queue);
@@ -307,12 +307,12 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
BUG_ON((signed short)ref < 0);
queue->grant_rx_ref[id] = ref;
- pfn = page_to_pfn(skb_frag_page(&skb_shinfo(skb)->frags[0]));
+ gfn = page_to_gfn(skb_frag_page(&skb_shinfo(skb)->frags[0]));
req = RING_GET_REQUEST(&queue->rx, req_prod);
gnttab_grant_foreign_access_ref(ref,
queue->info->xbdev->otherend_id,
- pfn_to_mfn(pfn),
+ gfn,
0);
req->id = id;
@@ -431,7 +431,7 @@ static struct xen_netif_tx_request *xennet_make_one_txreq(
BUG_ON((signed short)ref < 0);
gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
- page_to_mfn(page), GNTMAP_readonly);
+ page_to_gfn(page), GNTMAP_readonly);
queue->tx_skbs[id].skb = skb;
queue->grant_tx_page[id] = page;
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
index fad22ca..cdf00d1 100644
--- a/drivers/scsi/xen-scsifront.c
+++ b/drivers/scsi/xen-scsifront.c
@@ -377,7 +377,6 @@ static int map_data_for_request(struct vscsifrnt_info *info,
unsigned int data_len = scsi_bufflen(sc);
unsigned int data_grants = 0, seg_grants = 0;
struct scatterlist *sg;
- unsigned long mfn;
struct scsiif_request_segment *seg;
ring_req->nr_segments = 0;
@@ -420,9 +419,8 @@ static int map_data_for_request(struct vscsifrnt_info *info,
ref = gnttab_claim_grant_reference(&gref_head);
BUG_ON(ref = -ENOSPC);
- mfn = pfn_to_mfn(page_to_pfn(page));
gnttab_grant_foreign_access_ref(ref,
- info->dev->otherend_id, mfn, 1);
+ info->dev->otherend_id, page_to_gfn(page), 1);
shadow->gref[ref_cnt] = ref;
ring_req->seg[ref_cnt].gref = ref;
ring_req->seg[ref_cnt].offset = (uint16_t)off;
@@ -454,9 +452,9 @@ static int map_data_for_request(struct vscsifrnt_info *info,
ref = gnttab_claim_grant_reference(&gref_head);
BUG_ON(ref = -ENOSPC);
- mfn = pfn_to_mfn(page_to_pfn(page));
gnttab_grant_foreign_access_ref(ref,
- info->dev->otherend_id, mfn, grant_ro);
+ info->dev->otherend_id, page_to_gfn(page),
+ grant_ro);
shadow->gref[ref_cnt] = ref;
seg->gref = ref;
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index a9d837f..efe5124 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -265,7 +265,8 @@ static int xen_pv_console_init(void)
return 0;
}
info->evtchn = xen_start_info->console.domU.evtchn;
- info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+ /* GFN = MFN for PV guest */
+ info->intf = gfn_to_virt(xen_start_info->console.domU.mfn);
info->vtermno = HVC_COOKIE;
spin_lock(&xencons_lock);
@@ -390,7 +391,7 @@ static int xencons_connect_backend(struct xenbus_device *dev,
if (IS_ERR(info->hvc))
return PTR_ERR(info->hvc);
if (xen_pv_domain())
- mfn = virt_to_mfn(info->intf);
+ mfn = virt_to_gfn(info->intf);
else
mfn = __pa(info->intf) >> PAGE_SHIFT;
ret = gnttab_alloc_grant_references(1, &gref_head);
diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct xenbus_device *dev)
static unsigned long vmalloc_to_mfn(void *address)
{
- return pfn_to_mfn(vmalloc_to_pfn(address));
+ return pfn_to_gfn(vmalloc_to_pfn(address));
}
static void xenfb_init_shared_page(struct xenfb_info *info,
@@ -586,7 +586,7 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
goto unbind_irq;
}
ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
- virt_to_mfn(info->page));
+ virt_to_gfn(info->page));
if (ret)
goto error_xenbus;
ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index fd93369..9734649 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -441,7 +441,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
/* Update direct mapping, invalidate P2M, and add to balloon. */
for (i = 0; i < nr_pages; i++) {
pfn = frame_list[i];
- frame_list[i] = pfn_to_mfn(pfn);
+ frame_list[i] = pfn_to_gfn(pfn);
page = pfn_to_page(pfn);
#ifdef CONFIG_XEN_HAVE_PVMMU
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 96093ae..95a4fdb 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -1692,7 +1692,7 @@ void __init xen_init_IRQ(void)
struct physdev_pirq_eoi_gmfn eoi_gmfn;
pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
- eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+ eoi_gmfn.gmfn = virt_to_gfn(pirq_eoi_map);
rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
/* TODO: No PVH support for PIRQ EOI */
if (rc != 0) {
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index ed673e1..1d4baf5 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -111,7 +111,7 @@ static int init_control_block(int cpu,
for (i = 0; i < EVTCHN_FIFO_MAX_QUEUES; i++)
q->head[i] = 0;
- init_control.control_gfn = virt_to_mfn(control_block);
+ init_control.control_gfn = virt_to_gfn(control_block);
init_control.offset = 0;
init_control.vcpu = cpu;
@@ -167,7 +167,7 @@ static int evtchn_fifo_setup(struct irq_info *info)
/* Mask all events in this page before adding it. */
init_array_page(array_page);
- expand_array.array_gfn = virt_to_mfn(array_page);
+ expand_array.array_gfn = virt_to_gfn(array_page);
ret = HYPERVISOR_event_channel_op(EVTCHNOP_expand_array, &expand_array);
if (ret < 0)
diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index e53fe19..13e1458 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -142,7 +142,8 @@ static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
/* Grant foreign access to the page. */
rc = gnttab_grant_foreign_access(op->domid,
- pfn_to_mfn(page_to_pfn(gref->page)), readonly);
+ page_to_gfn(gref->page),
+ readonly);
if (rc < 0)
goto undo;
gref_ids[i] = gref->gref_id = rc;
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index d10effe..e12bd36 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -80,7 +80,7 @@ static int xen_suspend(void *data)
* is resuming in a new domain.
*/
si->cancelled = HYPERVISOR_suspend(xen_pv_domain()
- ? virt_to_mfn(xen_start_info)
+ ? virt_to_gfn(xen_start_info)
: 0);
xen_arch_post_suspend(si->cancelled);
diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index 239738f..28c97ff 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -131,7 +131,7 @@ static int xen_tmem_new_pool(struct tmem_pool_uuid uuid,
static int xen_tmem_put_page(u32 pool_id, struct tmem_oid oid,
u32 index, unsigned long pfn)
{
- unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
+ unsigned long gmfn = pfn_to_gfn(pfn);
return xen_tmem_op(TMEM_PUT_PAGE, pool_id, oid, index,
gmfn, 0, 0, 0);
@@ -140,7 +140,7 @@ static int xen_tmem_put_page(u32 pool_id, struct tmem_oid oid,
static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid,
u32 index, unsigned long pfn)
{
- unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
+ unsigned long gmfn = pfn_to_gfn(pfn);
return xen_tmem_op(TMEM_GET_PAGE, pool_id, oid, index,
gmfn, 0, 0, 0);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 9ad3272..daa267a 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -380,7 +380,7 @@ int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr,
for (i = 0; i < nr_pages; i++) {
err = gnttab_grant_foreign_access(dev->otherend_id,
- virt_to_mfn(vaddr), 0);
+ virt_to_gfn(vaddr), 0);
if (err < 0) {
xenbus_dev_fatal(dev, err,
"granting access to ring page");
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index b17707e..ee6d9ef 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -49,7 +49,7 @@ static long xenbus_alloc(domid_t domid)
goto out_err;
gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
- virt_to_mfn(xen_store_interface), 0 /* writable */);
+ virt_to_gfn(xen_store_interface), 0 /* writable */);
arg.dom = DOMID_SELF;
arg.remote_dom = domid;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 4308fb3..31836897 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -711,9 +711,7 @@ static int __init xenstored_local_init(void)
if (!page)
goto out_err;
- xen_store_mfn = xen_start_info->store_mfn - pfn_to_mfn(virt_to_phys((void *)page) >>
- PAGE_SHIFT);
+ xen_store_mfn = xen_start_info->store_mfn = virt_to_gfn(page);
/* Next allocate a local port which xenstored can bind to */
alloc_unbound.dom = DOMID_SELF;
@@ -787,12 +785,12 @@ static int __init xenbus_init(void)
err = xenstored_local_init();
if (err)
goto out_error;
- xen_store_interface = mfn_to_virt(xen_store_mfn);
+ xen_store_interface = gfn_to_virt(xen_store_mfn);
break;
case XS_PV:
xen_store_evtchn = xen_start_info->store_evtchn;
xen_store_mfn = xen_start_info->store_mfn;
- xen_store_interface = mfn_to_virt(xen_store_mfn);
+ xen_store_interface = gfn_to_virt(xen_store_mfn);
break;
case XS_HVM:
err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
diff --git a/include/xen/page.h b/include/xen/page.h
index c5ed20b..e7e1425 100644
--- a/include/xen/page.h
+++ b/include/xen/page.h
@@ -3,9 +3,9 @@
#include <asm/xen/page.h>
-static inline unsigned long page_to_mfn(struct page *page)
+static inline unsigned long page_to_gfn(struct page *page)
{
- return pfn_to_mfn(page_to_pfn(page));
+ return pfn_to_gfn(page_to_pfn(page));
}
struct xen_memory_region {
--
2.1.4
^ permalink raw reply related
* [PATCH 0/8] Use correctly the Xen memory terminologies in Linux
From: Julien Grall @ 2015-07-28 15:02 UTC (permalink / raw)
To: xen-devel
Cc: ian.campbell, stefano.stabellini, linux-kernel, Julien Grall,
Boris Ostrovsky, David Vrabel, Dmitry Torokhov,
Greg Kroah-Hartman, H. Peter Anvin, Ingo Molnar,
James E.J. Bottomley, Jean-Christophe Plagniol-Villard,
Jiri Slaby, Juergen Gross, Konrad Rzeszutek Wilk, linux-api,
linux-arm-kernel, linux-fbdev, linux-input, linuxppc-dev,
linux-scsi, netdev, Roger Pau Monné
Hi all,
This patch series aims to use the memory terminologies described in
include/linux/mm.h [1] for Linux xen code.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM and make the developper confused about the expected
behavior.
For instance, with pfn_to_mfn, we expect to get a MFN based on the name.
Although, if we look at the implementation on x86, it's returning a GFN.
Most of the callers are also using it this way.
The first 2 patches of this series is ARM related in order to remove
PV specific helpers which should not be used and fixing the implementation of
pfn_to_mfn.
The rest of the series is here rename most of the usage in the common code
of MFN to GFN. I also took the opportunity to replace most of the call to
pfn_to_gfn in the common code by page_to_gfn avoid construction such
as pfn_to_gfn(page_to_pfn(...).
Note the one xen-blkfront will be dropped by 64K series [2], I can include it
if necessary.
This series is based on Linux 4.2-rc4. A branch with all the patches
can be found here:
git://xenbits.xen.org/people/julieng/linux-arm.git branch page-renaming-v1
Sincerely yours,
[1] Xen tree: e758ed14f390342513405dd766e874934573e6cb
[2] https://lkml.org/lkml/2015/7/9/628
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "James E.J. Bottomley" <JBottomley@odin.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-scsi@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: x86@kernel.org
Julien Grall (8):
arm/xen: Remove helpers which are PV specific
xen: Make clear that swiotlb and biomerge are dealing with DMA address
arm/xen: implement correctly pfn_to_mfn
xen: Use the correctly the Xen memory terminologies
xen/tmem: Use page_to_gfn rather than pfn_to_gfn
video/xen-fbfront: Further s/MFN/GFN clean-up
hvc/xen: Further s/MFN/GFN clean-up
xen/privcmd: Further s/MFN/GFN/ clean-up
arch/arm/include/asm/xen/page.h | 44 +++++++++++++++---------------
arch/arm/xen/enlighten.c | 18 ++++++-------
arch/arm/xen/mm.c | 4 +--
arch/x86/include/asm/xen/page.h | 34 +++++++++++++----------
arch/x86/xen/enlighten.c | 4 +--
arch/x86/xen/mmu.c | 48 ++++++++++++++++-----------------
arch/x86/xen/p2m.c | 32 +++++++++++-----------
arch/x86/xen/setup.c | 12 ++++-----
arch/x86/xen/smp.c | 4 +--
arch/x86/xen/suspend.c | 8 +++---
drivers/block/xen-blkfront.c | 6 ++---
drivers/input/misc/xen-kbdfront.c | 4 +--
drivers/net/xen-netback/netback.c | 4 +--
drivers/net/xen-netfront.c | 8 +++---
drivers/scsi/xen-scsifront.c | 8 +++---
drivers/tty/hvc/hvc_xen.c | 18 +++++--------
drivers/video/fbdev/xen-fbfront.c | 20 +++++++-------
drivers/xen/balloon.c | 2 +-
drivers/xen/biomerge.c | 6 ++---
drivers/xen/events/events_base.c | 2 +-
drivers/xen/events/events_fifo.c | 4 +--
drivers/xen/gntalloc.c | 3 ++-
drivers/xen/manage.c | 2 +-
drivers/xen/privcmd.c | 44 +++++++++++++++---------------
drivers/xen/swiotlb-xen.c | 16 +++++------
drivers/xen/tmem.c | 21 +++++----------
drivers/xen/xenbus/xenbus_client.c | 2 +-
drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
drivers/xen/xenbus/xenbus_probe.c | 8 +++---
drivers/xen/xlate_mmu.c | 18 ++++++-------
include/uapi/xen/privcmd.h | 4 +++
include/xen/page.h | 4 +--
include/xen/xen-ops.h | 10 +++----
33 files changed, 210 insertions(+), 214 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH] fbdev: select versatile helpers for the integrator
From: Linus Walleij @ 2015-07-28 13:31 UTC (permalink / raw)
To: linux-fbdev
Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd
"video: move Versatile CLCD helpers" missed the fact
that the Integrator/CP is also using the helper, and
as a result the platform got only stubs and no graphics.
Add this as a default selection to Kconfig so we have
graphics again.
Fixes: 11c32d7b6274 (video: move Versatile CLCD helpers)
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de535e0f..f888561568d9 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -298,7 +298,7 @@ config FB_ARMCLCD
# Helper logic selected only by the ARM Versatile platform family.
config PLAT_VERSATILE_CLCD
- def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
+ def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS || ARCH_INTEGRATOR
depends on ARM
depends on FB_ARMCLCD && FB=y
--
2.4.3
^ permalink raw reply related
* [PATCH v2 15/22] backlight: Probe backlight devices on demand
From: Tomeu Vizoso @ 2015-07-28 13:19 UTC (permalink / raw)
To: linux-kernel
Cc: Stephen Warren, Javier Martinez Canillas, Mark Brown,
Thierry Reding, Rafael J. Wysocki, linux-arm-kernel,
Dmitry Torokhov, devicetree, Linus Walleij, linux-acpi,
Arnd Bergmann, Tomeu Vizoso, linux-fbdev, Tomi Valkeinen,
Jingoo Han, Jean-Christophe Plagniol-Villard, Lee Jones
In-Reply-To: <1438089593-7696-1-git-send-email-tomeu.vizoso@collabora.com>
When looking up a backlight device through its firmware node, probe it
if it hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
---
Changes in v2: None
drivers/video/backlight/backlight.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index bddc8b17a4d8..f7151d916435 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -559,6 +559,8 @@ struct backlight_device *of_find_backlight_by_node(struct device_node *node)
{
struct device *dev;
+ fwnode_ensure_device(&node->fwnode);
+
dev = class_find_device(backlight_class, NULL, node, of_parent_match);
return dev ? to_backlight_device(dev) : NULL;
--
2.4.3
^ permalink raw reply related
* [PATCH v2 0/22] On-demand device probing
From: Tomeu Vizoso @ 2015-07-28 13:19 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Stephen Warren, Javier Martinez Canillas, Mark Brown,
Thierry Reding, Rafael J. Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Dmitry Torokhov, devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann, Tomeu Vizoso,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Terje Bergström,
Len Brown, Rob Herring, David Airlie, Michael Turquette,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA
Hello,
I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playing with initcall levels and linking order.
While reading the thread [1] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it
should be possible to achieve the same by probing devices as they are
referenced by other devices.
This basically reuses the information that is already implicit in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.
During review of v1 of this series Linus Walleij suggested that it
should be the device driver core to make sure that dependencies are
ready before probing a device. I gave this idea a try [2] but Mark Brown
pointed out to the logic duplication between the resource acquisition
and dependency discovery code paths (though I think it's fairly minor).
To address that code duplication I experimented with Arnd's devm_probe
[3] concept of having drivers declare their dependencies instead of
acquiring them during probe, and while it worked [4], I don't think we
end up winning anything when compared to just probing devices on-demand
from resource getters.
One remaining objection is to the "sprinkling" of calls to
fwnode_ensure_device() in the resource getters of each subsystem, but I
think it's the right thing to do given that the storage of resources is
currently subsystem-specific.
We could avoid the above by moving resource storage into the core, but I
don't think there's a compelling case for that.
I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
and these patches were enough to eliminate all the deferred probes
(except one in PandaBoard because omap_dma_system doesn't have a
firmware node as of yet).
With this series I get the kernel to output to the panel in 0.5s,
instead of 2.8s.
Regards,
Tomeu
[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
[1] https://lkml.org/lkml/2014/5/12/452
[2] https://lkml.org/lkml/2015/6/17/305
[3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689
[4] https://lkml.org/lkml/2015/7/21/441
Changes in v2:
- Move delay to platform.c
- Use set_primary_fwnode()
- Use of_node_full_name()
- Move the logic for finding a platform device from its firmware node to
of/platform.c as it's not needed for ACPI nodes.
- Add acpi_dev_get_device()
- Add fwnode_ensure_device() so the mechanism for probing devices on
demand is independent of the firmware format.
- Acquire regulator device lock before returning from regulator_dev_lookup()
Tomeu Vizoso (22):
platform: delay device-driver matches until late_initcall
of/platform: Set fwnode field for new devices
device property: add fwnode_get_name()
of/platform: add of_platform_device_find()
ACPI: add acpi_dev_get_device()
device property: add fwnode_ensure_device()
gpio: Probe GPIO drivers on demand
gpio: Probe pinctrl devices on demand
regulator: core: Reduce critical area in _regulator_get
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c master devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
ASoC: core: Probe components on demand
drivers/base/platform.c | 28 +++++++++++
drivers/base/property.c | 73 +++++++++++++++++++++++++++
drivers/clk/clk.c | 3 ++
drivers/dma/of-dma.c | 2 +
drivers/gpio/gpiolib-of.c | 4 ++
drivers/gpu/drm/drm_panel.c | 2 +
drivers/gpu/drm/tegra/dpaux.c | 2 +
drivers/i2c/i2c-core.c | 2 +
drivers/of/platform.c | 61 +++++++++++++++++++++++
drivers/phy/phy-core.c | 2 +
drivers/pinctrl/devicetree.c | 1 +
drivers/power/power_supply_core.c | 2 +
drivers/pwm/core.c | 2 +
drivers/regulator/core.c | 99 +++++++++++++++++++++----------------
drivers/usb/phy/phy.c | 2 +
drivers/video/backlight/backlight.c | 2 +
include/linux/acpi.h | 10 ++++
include/linux/of_platform.h | 1 +
include/linux/property.h | 4 ++
sound/soc/soc-core.c | 6 ++-
20 files changed, 264 insertions(+), 44 deletions(-)
--
2.4.3
^ permalink raw reply
* Dynamically setting new modes via framebuffer
From: Ilyes Gouta @ 2015-07-28 12:35 UTC (permalink / raw)
To: linux-fbdev
Hi,
What's the standard framebuffer (driver) behavior for when a
fbdev-based application is already running (so mode set, framebuffer
alreay mapped) and the user attempts to set a new mode using fbset
(without the first application knowing about it)?
Should the driver deny it and e.g. return -EBUSY? Is the interface
simply permissive about that? Then how could the application get
notifications about mode change and adjust its rendering parameters?
Regards,
Ilyes
P.S: please CC me as I'm not registered with the mailing-list.
^ permalink raw reply
* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-07-28 11:56 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <201507241803.42891@pali>
On Friday 24 July 2015 18:03:42 Pali Rohár wrote:
> Hello,
>
> when on N900 (real HW or qemu) I run this command
>
> / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
>
> then kernel crash with this error message
>
> / # [ 29.904113] Division by zero in kernel.
> ** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
> (cfb_imageblit+0xac/0x464)
> ** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> ** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
>
> I suspect that problem is in omapdss.
>
> I do not know if size 0 make sense, but Maemo userspace is calling above
> commands and on Nokia's 2.6.28 kernel there is no crash or error message.
>
> IMHO Division by zero in kernel should not be there even if userspace
> call "incorrect" command.
>
PING! Any idea what to do with Division by zero in kernel?
--
Pali Rohár
pali.rohar@gmail.com
^ 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