* [PATCH 10/15] video: au1100fb: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:54 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/au1100fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/au1100fb.c b/drivers/video/au1100fb.c
index 700cac0..606a3ba 100644
--- a/drivers/video/au1100fb.c
+++ b/drivers/video/au1100fb.c
@@ -579,7 +579,6 @@ failed:
if (fbdev->info.cmap.len != 0) {
fb_dealloc_cmap(&fbdev->info.cmap);
}
- platform_set_drvdata(dev, NULL);
return -ENODEV;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 09/15] video: vt8500: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:53 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/vt8500lcdfb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 9547e18..897484903 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -448,7 +448,6 @@ failed_free_io:
failed_free_res:
release_mem_region(res->start, resource_size(res));
failed_fbi:
- platform_set_drvdata(pdev, NULL);
kfree(fbi);
failed:
return ret;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 08/15] video: sh_mipi_dsi: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:52 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/sh_mipi_dsi.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 6cad530..8f6e8ff 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -567,7 +567,6 @@ static int sh_mipi_remove(struct platform_device *pdev)
iounmap(mipi->base);
if (res)
release_mem_region(res->start, resource_size(res));
- platform_set_drvdata(pdev, NULL);
kfree(mipi);
return 0;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 07/15] video: sa1100fb: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:51 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/sa1100fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/sa1100fb.c b/drivers/video/sa1100fb.c
index f34c858..de76da0 100644
--- a/drivers/video/sa1100fb.c
+++ b/drivers/video/sa1100fb.c
@@ -1271,7 +1271,6 @@ static int sa1100fb_probe(struct platform_device *pdev)
failed:
if (fbi)
iounmap(fbi->base);
- platform_set_drvdata(pdev, NULL);
kfree(fbi);
release_mem_region(res->start, resource_size(res));
return ret;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 06/15] video: nuc900fb: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:50 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/nuc900fb.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index 32581c7..8c527e5 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -707,7 +707,6 @@ static int nuc900fb_remove(struct platform_device *pdev)
release_resource(fbi->mem);
kfree(fbi->mem);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return 0;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 05/15] video: mxsfb: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:49 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/mxsfb.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..10210a0 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -986,8 +986,6 @@ static int mxsfb_remove(struct platform_device *pdev)
framebuffer_release(fb_info);
- platform_set_drvdata(pdev, NULL);
-
return 0;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 04/15] video: jz4740: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:48 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/jz4740_fb.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index 36979b4..2c49112 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -737,8 +737,6 @@ static int jzfb_remove(struct platform_device *pdev)
fb_dealloc_cmap(&jzfb->fb->cmap);
jzfb_free_devmem(jzfb);
- platform_set_drvdata(pdev, NULL);
-
framebuffer_release(jzfb->fb);
return 0;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 03/15] video: imxfb: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:48 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/imxfb.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..c1945b3 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -923,7 +923,6 @@ failed_getclock:
failed_req:
kfree(info->pseudo_palette);
failed_init:
- platform_set_drvdata(pdev, NULL);
framebuffer_release(info);
return ret;
}
@@ -955,8 +954,6 @@ static int imxfb_remove(struct platform_device *pdev)
iounmap(fbi->regs);
release_mem_region(res->start, resource_size(res));
- platform_set_drvdata(pdev, NULL);
-
return 0;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 02/15] video: ep93xx: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:47 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/ep93xx-fb.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index ee1ee54..28a837d 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -595,7 +595,6 @@ failed_videomem:
fb_dealloc_cmap(&info->cmap);
failed_cmap:
kfree(info);
- platform_set_drvdata(pdev, NULL);
return err;
}
@@ -614,7 +613,6 @@ static int ep93xxfb_remove(struct platform_device *pdev)
fbi->mach_info->teardown(pdev);
kfree(info);
- platform_set_drvdata(pdev, NULL);
return 0;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 01/15] video: bfin: remove unnecessary platform_set_drvdata()
From: Jingoo Han @ 2013-05-11 12:45 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/bf54x-lq043fb.c | 1 -
drivers/video/bfin-lq035q1-fb.c | 2 --
drivers/video/bfin-t350mcqb-fb.c | 2 --
3 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index 2726a5b..87f288b 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -681,7 +681,6 @@ out3:
out2:
free_dma(CH_EPPI0);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index 29d8c04..be65bae 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -759,7 +759,6 @@ static int bfin_lq035q1_probe(struct platform_device *pdev)
out2:
free_dma(CH_PPI);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
@@ -788,7 +787,6 @@ static int bfin_lq035q1_remove(struct platform_device *pdev)
bfin_lq035q1_free_ports(info->disp_info->ppi_mode =
USE_RGB565_16_BIT_PPI);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
dev_info(&pdev->dev, "unregistered LCD driver\n");
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index d46da01..48c0c4e 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -578,7 +578,6 @@ out3:
out2:
free_dma(CH_PPI);
out1:
- platform_set_drvdata(pdev, NULL);
return ret;
}
@@ -608,7 +607,6 @@ static int bfin_t350mcqb_remove(struct platform_device *pdev)
bfin_t350mcqb_request_ports(0);
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
printk(KERN_INFO DRIVER_NAME ": Unregister LCD driver.\n");
--
1.7.2.5
^ permalink raw reply related
* Re: [RFC 33/42] drivers/video/omap2: don't check resource with devm_ioremap_resource
From: Jingoo Han @ 2013-05-11 5:37 UTC (permalink / raw)
To: 'Wolfram Sang', linux-kernel
Cc: 'Tomi Valkeinen', 'Florian Tobias Schandinat',
linux-omap, linux-fbdev
In-Reply-To: <1368173847-5661-34-git-send-email-wsa@the-dreams.de>
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/omap2/vrfb.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
> index 5261229..f346b02 100644
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> @@ -353,11 +353,6 @@ static int __init vrfb_probe(struct platform_device *pdev)
> /* first resource is the register res, the rest are vrfb contexts */
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(&pdev->dev, "can't get vrfb base address\n");
> - return -EINVAL;
> - }
> -
> vrfb_base = devm_ioremap_resource(&pdev->dev, mem);
> if (IS_ERR(vrfb_base))
> return PTR_ERR(vrfb_base);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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: [RFC 34/42] drivers/video/omap2/dss: don't check resource with devm_ioremap_resource
From: Jingoo Han @ 2013-05-11 5:36 UTC (permalink / raw)
To: 'Wolfram Sang', linux-kernel
Cc: 'Tomi Valkeinen', 'Florian Tobias Schandinat',
linux-omap, linux-fbdev
In-Reply-To: <1368173847-5661-35-git-send-email-wsa@the-dreams.de>
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
It looks good.
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/omap2/dss/hdmi.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 17f4d55..7bc6762 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -1064,13 +1064,8 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
> mutex_init(&hdmi.lock);
> mutex_init(&hdmi.ip_data.lock);
>
> - res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - DSSERR("can't get IORESOURCE_MEM HDMI\n");
> - return -EINVAL;
> - }
> -
> /* Base address taken from platform */
> + res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
> hdmi.ip_data.base_wp = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(hdmi.ip_data.base_wp))
> return PTR_ERR(hdmi.ip_data.base_wp);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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: [RFC 32/42] drivers/video: don't check resource with devm_ioremap_resource
From: Jingoo Han @ 2013-05-11 5:33 UTC (permalink / raw)
To: 'Wolfram Sang', linux-kernel
Cc: 'Florian Tobias Schandinat', linux-fbdev,
'Tomi Valkeinen', 'Shawn Guo', Fabio Estevam
In-Reply-To: <1368173847-5661-33-git-send-email-wsa@the-dreams.de>
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
CC'ed Tomi Valkeinen, Shawn Guo, Fabio Estevam
It looks good.
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/video/mxsfb.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index 1b2c26d..3dc3265 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -883,12 +883,6 @@ static int mxsfb_probe(struct platform_device *pdev)
> if (of_id)
> pdev->id_entry = of_id->data;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(&pdev->dev, "Cannot get memory IO resource\n");
> - return -ENODEV;
> - }
> -
> fb_info = framebuffer_alloc(sizeof(struct mxsfb_info), &pdev->dev);
> if (!fb_info) {
> dev_err(&pdev->dev, "Failed to allocate fbdev\n");
> @@ -897,6 +891,7 @@ static int mxsfb_probe(struct platform_device *pdev)
>
> host = to_imxfb_host(fb_info);
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(host->base)) {
> dev_err(&pdev->dev, "ioremap failed\n");
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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: [RFC/PATCH v2 1/8] Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
From: Daniel Vetter @ 2013-05-10 19:34 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, dri-devel, linux-fbdev, Jerome Glisse, Alex Deucher,
Dave Airlie, Daniel Vetter
In-Reply-To: <CALCETrXbO9ePZf5nUZQXG1LSr8N7XCw34QKj7EqAF1sY3L1UdQ@mail.gmail.com>
On Fri, May 10, 2013 at 12:27:54PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> >> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> >> >> Several drivers currently use mtrr_add through various #ifdef guards
> >> >> and/or drm wrappers. The vast majority of them want to add WC MTRRs
> >> >> on x86 systems and don't actually need the MTRR if PAT (i.e.
> >> >> ioremap_wc, etc) are working.
> >> >>
> >> >> arch_phys_wc_add and arch_phys_wc_del are new functions, available
> >> >> on all architectures and configurations, that add WC MTRRs on x86 if
> >> >> needed (and handle errors) and do nothing at all otherwise. They're
> >> >> also easier to use than mtrr_add and mtrr_del, so the call sites can
> >> >> be simplified.
> >> >>
> >> >> As an added benefit, this will avoid wasting MTRRs and possibly
> >> >> warning pointlessly on PAT-supporting systems.
> >> >>
> >> >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> >> >> ---
> >> >> arch/x86/include/asm/io.h | 7 ++++++
> >> >> arch/x86/include/asm/mtrr.h | 5 ++++-
> >> >> arch/x86/kernel/cpu/mtrr/main.c | 48 +++++++++++++++++++++++++++++++++++++++++
> >> >> include/linux/io.h | 25 +++++++++++++++++++++
> >> >> 4 files changed, 84 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> >> >> index d8e8eef..34f69cb 100644
> >> >> --- a/arch/x86/include/asm/io.h
> >> >> +++ b/arch/x86/include/asm/io.h
> >> >> @@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
> >> >>
> >> >> #define IO_SPACE_LIMIT 0xffff
> >> >>
> >> >> +#ifdef CONFIG_MTRR
> >> >> +extern int __must_check arch_phys_wc_add(unsigned long base,
> >> >> + unsigned long size);
> >> >> +extern void arch_phys_wc_del(int handle);
> >> >> +#define arch_phys_wc_add arch_phys_wc_add
> >> >> +#endif
> >> >> +
> >> >> #endif /* _ASM_X86_IO_H */
> >> >> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
> >> >> index e235582..10d0fba 100644
> >> >> --- a/arch/x86/include/asm/mtrr.h
> >> >> +++ b/arch/x86/include/asm/mtrr.h
> >> >> @@ -26,7 +26,10 @@
> >> >> #include <uapi/asm/mtrr.h>
> >> >>
> >> >>
> >> >> -/* The following functions are for use by other drivers */
> >> >> +/*
> >> >> + * The following functions are for use by other drivers that cannot use
> >> >> + * arch_phys_wc_add and arch_phys_wc_del.
> >> >> + */
> >> >> # ifdef CONFIG_MTRR
> >> >> extern u8 mtrr_type_lookup(u64 addr, u64 end);
> >> >> extern void mtrr_save_fixed_ranges(void *);
> >> >> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> >> >> index 726bf96..23bd49a 100644
> >> >> --- a/arch/x86/kernel/cpu/mtrr/main.c
> >> >> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> >> >> @@ -51,6 +51,7 @@
> >> >> #include <asm/e820.h>
> >> >> #include <asm/mtrr.h>
> >> >> #include <asm/msr.h>
> >> >> +#include <asm/pat.h>
> >> >>
> >> >> #include "mtrr.h"
> >> >>
> >> >> @@ -524,6 +525,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
> >> >> }
> >> >> EXPORT_SYMBOL(mtrr_del);
> >> >>
> >> >> +/**
> >> >> + * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
> >> >> + * @base: Physical base address
> >> >> + * @size: Size of region
> >> >> + *
> >> >> + * If PAT is available, this does nothing. If PAT is unavailable, it
> >> >> + * attempts to add a WC MTRR covering size bytes starting at base and
> >> >> + * logs an error if this fails.
> >> >> + *
> >> >> + * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> >> >> + * but drivers should not try to interpret that return value.
> >> >> + */
> >> >> +int arch_phys_wc_add(unsigned long base, unsigned long size)
> >> >> +{
> >> >> + int ret;
> >> >> +
> >> >> + if (pat_enabled)
> >> >> + return 0; /* Success! (We don't need to do anything.) */
> >> >
> >> > Shouldn't we #define a big number for this case since mtrr_add returns
> >> > 0-based mtrr indices? Rather unlikely that the very first mtrr is unused I
> >> > know, but still feels like a cleaner interface. And we don't need to leak
> >> > that #define out at all to users of this interface.
> >>
> >> I did something more like that in v1, but I like having the property
> >> that arch_phys_wc_del(0) does nothing as opposed to possibly breaking
> >> the system. Given that almost all of these things are stored in
> >> kzalloced space, this seems safer to me. The return value here could
> >> just as easily be -ENOSYS, but nothing should care.
> >>
> >> There is an issue, though: the drm maps interface is leaking the
> >> return values to userspace via a couple of ioctls, so I should fix it
> >> to at least return the correct value. (Why that interface includes an
> >> mtrr number is a mystery to me.)
> >
> > Old drm interfaces are horrible. Best approach is to simply stay far away
> > from them ...
> >
> >> Have I convinced you that my bike shed color is okay? I'll send out a
> >> v3 later today with a fix for the leaking-to-userspace issue and I'll
> >> fix the i915 thing.
> >
> > A comment in your arch_phys_wc_add/del functions that we do have an mtrr
> > with index 0, but won't ever get that would be fine with me. Still feels a
> > bit irky though ;-)
>
> Hmm. Maybe you missed the hack I ended up using a couple of lines
> below. I'm always using strictly positive values to indicate a real
> MTRR -- I'm adding 1000 to the result if we actually do anything. So
> a return value of 0 is genuinely safe. (I still have to fix up the
> two places in the drm code that pass that hacked-up value back to
> userspace.)
Oops, I've indeed missed that one. Only noticed the special 0 and started
hunting down the semantics of mtrr_add. With that cleared up this is
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC/PATCH v2 1/8] Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
From: Andy Lutomirski @ 2013-05-10 19:27 UTC (permalink / raw)
To: Andy Lutomirski, linux-kernel, dri-devel, linux-fbdev,
Jerome Glisse, Alex Deucher, Dave Airlie
Cc: Daniel Vetter
In-Reply-To: <20130510190954.GS12292@phenom.ffwll.local>
On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
>> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> >> Several drivers currently use mtrr_add through various #ifdef guards
>> >> and/or drm wrappers. The vast majority of them want to add WC MTRRs
>> >> on x86 systems and don't actually need the MTRR if PAT (i.e.
>> >> ioremap_wc, etc) are working.
>> >>
>> >> arch_phys_wc_add and arch_phys_wc_del are new functions, available
>> >> on all architectures and configurations, that add WC MTRRs on x86 if
>> >> needed (and handle errors) and do nothing at all otherwise. They're
>> >> also easier to use than mtrr_add and mtrr_del, so the call sites can
>> >> be simplified.
>> >>
>> >> As an added benefit, this will avoid wasting MTRRs and possibly
>> >> warning pointlessly on PAT-supporting systems.
>> >>
>> >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> >> ---
>> >> arch/x86/include/asm/io.h | 7 ++++++
>> >> arch/x86/include/asm/mtrr.h | 5 ++++-
>> >> arch/x86/kernel/cpu/mtrr/main.c | 48 +++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/io.h | 25 +++++++++++++++++++++
>> >> 4 files changed, 84 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
>> >> index d8e8eef..34f69cb 100644
>> >> --- a/arch/x86/include/asm/io.h
>> >> +++ b/arch/x86/include/asm/io.h
>> >> @@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
>> >>
>> >> #define IO_SPACE_LIMIT 0xffff
>> >>
>> >> +#ifdef CONFIG_MTRR
>> >> +extern int __must_check arch_phys_wc_add(unsigned long base,
>> >> + unsigned long size);
>> >> +extern void arch_phys_wc_del(int handle);
>> >> +#define arch_phys_wc_add arch_phys_wc_add
>> >> +#endif
>> >> +
>> >> #endif /* _ASM_X86_IO_H */
>> >> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
>> >> index e235582..10d0fba 100644
>> >> --- a/arch/x86/include/asm/mtrr.h
>> >> +++ b/arch/x86/include/asm/mtrr.h
>> >> @@ -26,7 +26,10 @@
>> >> #include <uapi/asm/mtrr.h>
>> >>
>> >>
>> >> -/* The following functions are for use by other drivers */
>> >> +/*
>> >> + * The following functions are for use by other drivers that cannot use
>> >> + * arch_phys_wc_add and arch_phys_wc_del.
>> >> + */
>> >> # ifdef CONFIG_MTRR
>> >> extern u8 mtrr_type_lookup(u64 addr, u64 end);
>> >> extern void mtrr_save_fixed_ranges(void *);
>> >> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
>> >> index 726bf96..23bd49a 100644
>> >> --- a/arch/x86/kernel/cpu/mtrr/main.c
>> >> +++ b/arch/x86/kernel/cpu/mtrr/main.c
>> >> @@ -51,6 +51,7 @@
>> >> #include <asm/e820.h>
>> >> #include <asm/mtrr.h>
>> >> #include <asm/msr.h>
>> >> +#include <asm/pat.h>
>> >>
>> >> #include "mtrr.h"
>> >>
>> >> @@ -524,6 +525,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
>> >> }
>> >> EXPORT_SYMBOL(mtrr_del);
>> >>
>> >> +/**
>> >> + * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
>> >> + * @base: Physical base address
>> >> + * @size: Size of region
>> >> + *
>> >> + * If PAT is available, this does nothing. If PAT is unavailable, it
>> >> + * attempts to add a WC MTRR covering size bytes starting at base and
>> >> + * logs an error if this fails.
>> >> + *
>> >> + * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
>> >> + * but drivers should not try to interpret that return value.
>> >> + */
>> >> +int arch_phys_wc_add(unsigned long base, unsigned long size)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + if (pat_enabled)
>> >> + return 0; /* Success! (We don't need to do anything.) */
>> >
>> > Shouldn't we #define a big number for this case since mtrr_add returns
>> > 0-based mtrr indices? Rather unlikely that the very first mtrr is unused I
>> > know, but still feels like a cleaner interface. And we don't need to leak
>> > that #define out at all to users of this interface.
>>
>> I did something more like that in v1, but I like having the property
>> that arch_phys_wc_del(0) does nothing as opposed to possibly breaking
>> the system. Given that almost all of these things are stored in
>> kzalloced space, this seems safer to me. The return value here could
>> just as easily be -ENOSYS, but nothing should care.
>>
>> There is an issue, though: the drm maps interface is leaking the
>> return values to userspace via a couple of ioctls, so I should fix it
>> to at least return the correct value. (Why that interface includes an
>> mtrr number is a mystery to me.)
>
> Old drm interfaces are horrible. Best approach is to simply stay far away
> from them ...
>
>> Have I convinced you that my bike shed color is okay? I'll send out a
>> v3 later today with a fix for the leaking-to-userspace issue and I'll
>> fix the i915 thing.
>
> A comment in your arch_phys_wc_add/del functions that we do have an mtrr
> with index 0, but won't ever get that would be fine with me. Still feels a
> bit irky though ;-)
Hmm. Maybe you missed the hack I ended up using a couple of lines
below. I'm always using strictly positive values to indicate a real
MTRR -- I'm adding 1000 to the result if we actually do anything. So
a return value of 0 is genuinely safe. (I still have to fix up the
two places in the drm code that pass that hacked-up value back to
userspace.)
--Andy
^ permalink raw reply
* Re: [RFC/PATCH v2 1/8] Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
From: Daniel Vetter @ 2013-05-10 19:09 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, dri-devel, linux-fbdev, Jerome Glisse, Alex Deucher,
Dave Airlie, Daniel Vetter
In-Reply-To: <CALCETrVQzMjxZ87zY=+-TUKAMARnR9m3CzYdWZgEopJxF0TkDw@mail.gmail.com>
On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> >> Several drivers currently use mtrr_add through various #ifdef guards
> >> and/or drm wrappers. The vast majority of them want to add WC MTRRs
> >> on x86 systems and don't actually need the MTRR if PAT (i.e.
> >> ioremap_wc, etc) are working.
> >>
> >> arch_phys_wc_add and arch_phys_wc_del are new functions, available
> >> on all architectures and configurations, that add WC MTRRs on x86 if
> >> needed (and handle errors) and do nothing at all otherwise. They're
> >> also easier to use than mtrr_add and mtrr_del, so the call sites can
> >> be simplified.
> >>
> >> As an added benefit, this will avoid wasting MTRRs and possibly
> >> warning pointlessly on PAT-supporting systems.
> >>
> >> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> >> ---
> >> arch/x86/include/asm/io.h | 7 ++++++
> >> arch/x86/include/asm/mtrr.h | 5 ++++-
> >> arch/x86/kernel/cpu/mtrr/main.c | 48 +++++++++++++++++++++++++++++++++++++++++
> >> include/linux/io.h | 25 +++++++++++++++++++++
> >> 4 files changed, 84 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> >> index d8e8eef..34f69cb 100644
> >> --- a/arch/x86/include/asm/io.h
> >> +++ b/arch/x86/include/asm/io.h
> >> @@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
> >>
> >> #define IO_SPACE_LIMIT 0xffff
> >>
> >> +#ifdef CONFIG_MTRR
> >> +extern int __must_check arch_phys_wc_add(unsigned long base,
> >> + unsigned long size);
> >> +extern void arch_phys_wc_del(int handle);
> >> +#define arch_phys_wc_add arch_phys_wc_add
> >> +#endif
> >> +
> >> #endif /* _ASM_X86_IO_H */
> >> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
> >> index e235582..10d0fba 100644
> >> --- a/arch/x86/include/asm/mtrr.h
> >> +++ b/arch/x86/include/asm/mtrr.h
> >> @@ -26,7 +26,10 @@
> >> #include <uapi/asm/mtrr.h>
> >>
> >>
> >> -/* The following functions are for use by other drivers */
> >> +/*
> >> + * The following functions are for use by other drivers that cannot use
> >> + * arch_phys_wc_add and arch_phys_wc_del.
> >> + */
> >> # ifdef CONFIG_MTRR
> >> extern u8 mtrr_type_lookup(u64 addr, u64 end);
> >> extern void mtrr_save_fixed_ranges(void *);
> >> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> >> index 726bf96..23bd49a 100644
> >> --- a/arch/x86/kernel/cpu/mtrr/main.c
> >> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> >> @@ -51,6 +51,7 @@
> >> #include <asm/e820.h>
> >> #include <asm/mtrr.h>
> >> #include <asm/msr.h>
> >> +#include <asm/pat.h>
> >>
> >> #include "mtrr.h"
> >>
> >> @@ -524,6 +525,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
> >> }
> >> EXPORT_SYMBOL(mtrr_del);
> >>
> >> +/**
> >> + * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
> >> + * @base: Physical base address
> >> + * @size: Size of region
> >> + *
> >> + * If PAT is available, this does nothing. If PAT is unavailable, it
> >> + * attempts to add a WC MTRR covering size bytes starting at base and
> >> + * logs an error if this fails.
> >> + *
> >> + * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
> >> + * but drivers should not try to interpret that return value.
> >> + */
> >> +int arch_phys_wc_add(unsigned long base, unsigned long size)
> >> +{
> >> + int ret;
> >> +
> >> + if (pat_enabled)
> >> + return 0; /* Success! (We don't need to do anything.) */
> >
> > Shouldn't we #define a big number for this case since mtrr_add returns
> > 0-based mtrr indices? Rather unlikely that the very first mtrr is unused I
> > know, but still feels like a cleaner interface. And we don't need to leak
> > that #define out at all to users of this interface.
>
> I did something more like that in v1, but I like having the property
> that arch_phys_wc_del(0) does nothing as opposed to possibly breaking
> the system. Given that almost all of these things are stored in
> kzalloced space, this seems safer to me. The return value here could
> just as easily be -ENOSYS, but nothing should care.
>
> There is an issue, though: the drm maps interface is leaking the
> return values to userspace via a couple of ioctls, so I should fix it
> to at least return the correct value. (Why that interface includes an
> mtrr number is a mystery to me.)
Old drm interfaces are horrible. Best approach is to simply stay far away
from them ...
> Have I convinced you that my bike shed color is okay? I'll send out a
> v3 later today with a fix for the leaking-to-userspace issue and I'll
> fix the i915 thing.
A comment in your arch_phys_wc_add/del functions that we do have an mtrr
with index 0, but won't ever get that would be fine with me. Still feels a
bit irky though ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC/PATCH v2 1/8] Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
From: Andy Lutomirski @ 2013-05-10 18:00 UTC (permalink / raw)
To: Andy Lutomirski, linux-kernel, dri-devel, linux-fbdev,
Jerome Glisse, Alex Deucher, Dave Airlie
Cc: Daniel Vetter
In-Reply-To: <20130510091923.GH12292@phenom.ffwll.local>
On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> Several drivers currently use mtrr_add through various #ifdef guards
>> and/or drm wrappers. The vast majority of them want to add WC MTRRs
>> on x86 systems and don't actually need the MTRR if PAT (i.e.
>> ioremap_wc, etc) are working.
>>
>> arch_phys_wc_add and arch_phys_wc_del are new functions, available
>> on all architectures and configurations, that add WC MTRRs on x86 if
>> needed (and handle errors) and do nothing at all otherwise. They're
>> also easier to use than mtrr_add and mtrr_del, so the call sites can
>> be simplified.
>>
>> As an added benefit, this will avoid wasting MTRRs and possibly
>> warning pointlessly on PAT-supporting systems.
>>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>> ---
>> arch/x86/include/asm/io.h | 7 ++++++
>> arch/x86/include/asm/mtrr.h | 5 ++++-
>> arch/x86/kernel/cpu/mtrr/main.c | 48 +++++++++++++++++++++++++++++++++++++++++
>> include/linux/io.h | 25 +++++++++++++++++++++
>> 4 files changed, 84 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
>> index d8e8eef..34f69cb 100644
>> --- a/arch/x86/include/asm/io.h
>> +++ b/arch/x86/include/asm/io.h
>> @@ -345,4 +345,11 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec *vec1,
>>
>> #define IO_SPACE_LIMIT 0xffff
>>
>> +#ifdef CONFIG_MTRR
>> +extern int __must_check arch_phys_wc_add(unsigned long base,
>> + unsigned long size);
>> +extern void arch_phys_wc_del(int handle);
>> +#define arch_phys_wc_add arch_phys_wc_add
>> +#endif
>> +
>> #endif /* _ASM_X86_IO_H */
>> diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
>> index e235582..10d0fba 100644
>> --- a/arch/x86/include/asm/mtrr.h
>> +++ b/arch/x86/include/asm/mtrr.h
>> @@ -26,7 +26,10 @@
>> #include <uapi/asm/mtrr.h>
>>
>>
>> -/* The following functions are for use by other drivers */
>> +/*
>> + * The following functions are for use by other drivers that cannot use
>> + * arch_phys_wc_add and arch_phys_wc_del.
>> + */
>> # ifdef CONFIG_MTRR
>> extern u8 mtrr_type_lookup(u64 addr, u64 end);
>> extern void mtrr_save_fixed_ranges(void *);
>> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
>> index 726bf96..23bd49a 100644
>> --- a/arch/x86/kernel/cpu/mtrr/main.c
>> +++ b/arch/x86/kernel/cpu/mtrr/main.c
>> @@ -51,6 +51,7 @@
>> #include <asm/e820.h>
>> #include <asm/mtrr.h>
>> #include <asm/msr.h>
>> +#include <asm/pat.h>
>>
>> #include "mtrr.h"
>>
>> @@ -524,6 +525,53 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
>> }
>> EXPORT_SYMBOL(mtrr_del);
>>
>> +/**
>> + * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
>> + * @base: Physical base address
>> + * @size: Size of region
>> + *
>> + * If PAT is available, this does nothing. If PAT is unavailable, it
>> + * attempts to add a WC MTRR covering size bytes starting at base and
>> + * logs an error if this fails.
>> + *
>> + * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
>> + * but drivers should not try to interpret that return value.
>> + */
>> +int arch_phys_wc_add(unsigned long base, unsigned long size)
>> +{
>> + int ret;
>> +
>> + if (pat_enabled)
>> + return 0; /* Success! (We don't need to do anything.) */
>
> Shouldn't we #define a big number for this case since mtrr_add returns
> 0-based mtrr indices? Rather unlikely that the very first mtrr is unused I
> know, but still feels like a cleaner interface. And we don't need to leak
> that #define out at all to users of this interface.
I did something more like that in v1, but I like having the property
that arch_phys_wc_del(0) does nothing as opposed to possibly breaking
the system. Given that almost all of these things are stored in
kzalloced space, this seems safer to me. The return value here could
just as easily be -ENOSYS, but nothing should care.
There is an issue, though: the drm maps interface is leaking the
return values to userspace via a couple of ioctls, so I should fix it
to at least return the correct value. (Why that interface includes an
mtrr number is a mystery to me.)
Have I convinced you that my bike shed color is okay? I'll send out a
v3 later today with a fix for the leaking-to-userspace issue and I'll
fix the i915 thing.
--Andy
^ permalink raw reply
* Re: [PATCH 1/1] video: smscufx: Use NULL instead of 0
From: Steve Glendinning @ 2013-05-10 16:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1368185707-12852-1-git-send-email-sachin.kamat@linaro.org>
> 'info' is a pointer. Use NULL instead of 0.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Steve Glendinning <steve.glendinning@shawell.net>
^ permalink raw reply
* [PATCH 1/1] video: imxfb: Make local symbols static
From: Sachin Kamat @ 2013-05-10 12:07 UTC (permalink / raw)
To: linux-fbdev
These symbols are used only in this file.
Make them static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/imxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..0a16d82 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -960,7 +960,7 @@ static int imxfb_remove(struct platform_device *pdev)
return 0;
}
-void imxfb_shutdown(struct platform_device * dev)
+static void imxfb_shutdown(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
struct imxfb_info *fbi = info->par;
@@ -999,7 +999,7 @@ static int imxfb_setup(void)
return 0;
}
-int __init imxfb_init(void)
+static int __init imxfb_init(void)
{
int ret = imxfb_setup();
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] video: udlfb: Make local symbol static
From: Sachin Kamat @ 2013-05-10 11:58 UTC (permalink / raw)
To: linux-fbdev
'dlfb_handle_damage' is used only in this file. Make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/udlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 20353a6..d2e5bc3 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -573,7 +573,7 @@ static int dlfb_render_hline(struct dlfb_data *dev, struct urb **urb_ptr,
return 0;
}
-int dlfb_handle_damage(struct dlfb_data *dev, int x, int y,
+static int dlfb_handle_damage(struct dlfb_data *dev, int x, int y,
int width, int height, char *data)
{
int i, ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] video: udlfb: Use NULL instead of 0
From: Sachin Kamat @ 2013-05-10 11:58 UTC (permalink / raw)
To: linux-fbdev
Pointer variables should be initialized with NULL instead of 0.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/udlfb.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index ec03e72..20353a6 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -434,10 +434,10 @@ static void dlfb_compress_hline(
while ((pixel_end > pixel) &&
(cmd_buffer_end - MIN_RLX_CMD_BYTES > cmd)) {
- uint8_t *raw_pixels_count_byte = 0;
- uint8_t *cmd_pixels_count_byte = 0;
- const uint16_t *raw_pixel_start = 0;
- const uint16_t *cmd_pixel_start, *cmd_pixel_end = 0;
+ uint8_t *raw_pixels_count_byte = NULL;
+ uint8_t *cmd_pixels_count_byte = NULL;
+ const uint16_t *raw_pixel_start = NULL;
+ const uint16_t *cmd_pixel_start, *cmd_pixel_end = NULL;
prefetchw((void *) cmd); /* pull in one cache line at least */
@@ -1588,7 +1588,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
struct usb_device *usbdev;
- struct dlfb_data *dev = 0;
+ struct dlfb_data *dev = NULL;
int retval = -ENOMEM;
/* usb initialization */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/1] video: udlfb: Use NULL instead of 0
From: Sachin Kamat @ 2013-05-10 11:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1368185906-13351-1-git-send-email-sachin.kamat@linaro.org>
On 10 May 2013 17:08, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> 'dev' is a pointer. Use NULL instead of 0.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/udlfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index ec03e72..04eadc6 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1588,7 +1588,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
> const struct usb_device_id *id)
> {
> struct usb_device *usbdev;
> - struct dlfb_data *dev = 0;
> + struct dlfb_data *dev = NULL;
> int retval = -ENOMEM;
>
> /* usb initialization */
> --
> 1.7.9.5
>
Please ignore this patch. Re-sending with few more fixes.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH 1/1] video: udlfb: Use NULL instead of 0
From: Sachin Kamat @ 2013-05-10 11:50 UTC (permalink / raw)
To: linux-fbdev
'dev' is a pointer. Use NULL instead of 0.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/udlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index ec03e72..04eadc6 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1588,7 +1588,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
const struct usb_device_id *id)
{
struct usb_device *usbdev;
- struct dlfb_data *dev = 0;
+ struct dlfb_data *dev = NULL;
int retval = -ENOMEM;
/* usb initialization */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/1] video: smscufx: Use NULL instead of 0
From: Sachin Kamat @ 2013-05-10 11:47 UTC (permalink / raw)
To: linux-fbdev
'info' is a pointer. Use NULL instead of 0.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/smscufx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
index b2b33fc..e188ada 100644
--- a/drivers/video/smscufx.c
+++ b/drivers/video/smscufx.c
@@ -1622,7 +1622,7 @@ static int ufx_usb_probe(struct usb_interface *interface,
{
struct usb_device *usbdev;
struct ufx_data *dev;
- struct fb_info *info = 0;
+ struct fb_info *info = NULL;
int retval = -ENOMEM;
u32 id_rev, fpga_rev;
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC/PATCH v2 0/8] Clean up write-combining MTRR addition
From: Daniel Vetter @ 2013-05-10 9:42 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Jerome Glisse, Alex Deucher, Dave Airlie
In-Reply-To: <cover.1368128020.git.luto@amacapital.net>
On Thu, May 09, 2013 at 12:46:19PM -0700, Andy Lutomirski wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
>
> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
> otherwise. (Other architectures, if any, with a similar mechanism could
> implement them.)
>
> I've only tested the radeon driver, since I don't have test hardware
> easily available for the other drivers.
>
> Benefits include:
> - Simpler code
> - No more complaints about MTRR conflict warnings on PAT systems
> - Eventual unexporting of the MTRR API?
>
> This series eliminates about half of the mtrr_add calls in drivers/.
>
> Changes from v1:
> - Helpers renamed
> - Lots of bugs fixed
>
> The series is also at:
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup/rfc_v2
>
> Andy Lutomirski (8):
> Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
> drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
> drm_mtrr_{add,del}
> drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
> drm,agpgart: Use pgprot_writecombine for AGP maps and make the MTRR
> optional
> i915: Use arch_phys_wc_{add,del}
> radeon: Switch to arch_phys_wc_add and add a missing ..._del
> uvesafb: Clean up MTRR code
> drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
With my two comments addressed, the entire series is
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My knowledge for the userspace driver created drm maps in drm_vm.c is a
bit shoddy. Otoh most of the code I've seen using that is _horribly_
broken (as in userspace creates a register map that the kernel uses, with
no refcounting at all). Your changes look correct though, so I think this
is about as good as it gets.
Yours, Daniel
>
> Documentation/fb/uvesafb.txt | 16 +++-----
> arch/x86/include/asm/io.h | 7 ++++
> arch/x86/include/asm/mtrr.h | 5 ++-
> arch/x86/kernel/cpu/mtrr/main.c | 48 +++++++++++++++++++++++
> drivers/char/agp/frontend.c | 8 ++--
> drivers/gpu/drm/ast/ast_ttm.c | 13 ++-----
> drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 ++------
> drivers/gpu/drm/drm_bufs.c | 17 +++++----
> drivers/gpu/drm/drm_pci.c | 8 ++--
> drivers/gpu/drm/drm_stub.c | 10 +----
> drivers/gpu/drm/drm_vm.c | 22 +++++------
> drivers/gpu/drm/i915/i915_dma.c | 44 +++------------------
> drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++-----
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++-----
> drivers/gpu/drm/radeon/radeon_object.c | 5 ++-
> drivers/gpu/drm/savage/savage_bci.c | 43 ++++++++-------------
> drivers/gpu/drm/savage/savage_drv.h | 5 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 ++---
> drivers/video/uvesafb.c | 70 +++++++++-------------------------
> include/drm/drmP.h | 34 +----------------
> include/drm/drm_os_linux.h | 16 --------
> include/linux/io.h | 25 ++++++++++++
> include/video/uvesafb.h | 1 +
> 23 files changed, 181 insertions(+), 268 deletions(-)
>
> --
> 1.8.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ 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