* [PATCH 3/7] OMAPDSS: fix dss_init_ports error handling
From: Tomi Valkeinen @ 2015-06-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434449789-13812-1-git-send-email-tomi.valkeinen@ti.com>
The return value of dss_init_ports() is not handled at all, causing
crashes later if the call failed.
This patch adds the error handling, and we also move the call to a
slightly earlier place to make bailing out easier.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 1ce47441efe3..28e6ff053b47 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -1125,6 +1125,10 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
if (r)
goto err_pll_init;
+ r = dss_init_ports(pdev);
+ if (r)
+ goto err_init_ports;
+
pm_runtime_enable(&pdev->dev);
r = dss_runtime_get();
@@ -1149,8 +1153,6 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
- dss_init_ports(pdev);
-
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -1167,7 +1169,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
err_runtime_get:
pm_runtime_disable(&pdev->dev);
-
+ dss_uninit_ports(pdev);
+err_init_ports:
if (dss.video1_pll)
dss_video_pll_uninit(dss.video1_pll);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/7] OMAPDSS: refactor dss probe function
From: Tomi Valkeinen @ 2015-06-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434449789-13812-1-git-send-email-tomi.valkeinen@ti.com>
Refactor dss probe function by extracting the setup for video plls into
a separate function. The call to this function is also moved to a
slightly earlier phase, so that in error case we can bail out more
easily.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 125 ++++++++++++++++++++----------------
1 file changed, 69 insertions(+), 56 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 35601ab232e3..1ce47441efe3 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -1026,14 +1026,73 @@ static void __exit dss_uninit_ports(struct platform_device *pdev)
} while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
}
+static int dss_video_pll_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct regulator *pll_regulator;
+ int r;
+
+ if (!np)
+ return 0;
+
+ if (of_property_read_bool(np, "syscon-pll-ctrl")) {
+ dss.syscon_pll_ctrl = syscon_regmap_lookup_by_phandle(np,
+ "syscon-pll-ctrl");
+ if (IS_ERR(dss.syscon_pll_ctrl)) {
+ dev_err(&pdev->dev,
+ "failed to get syscon-pll-ctrl regmap\n");
+ return PTR_ERR(dss.syscon_pll_ctrl);
+ }
+
+ if (of_property_read_u32_index(np, "syscon-pll-ctrl", 1,
+ &dss.syscon_pll_ctrl_offset)) {
+ dev_err(&pdev->dev,
+ "failed to get syscon-pll-ctrl offset\n");
+ return -EINVAL;
+ }
+ }
+
+ pll_regulator = devm_regulator_get(&pdev->dev, "vdda_video");
+ if (IS_ERR(pll_regulator)) {
+ r = PTR_ERR(pll_regulator);
+
+ switch (r) {
+ case -ENOENT:
+ pll_regulator = NULL;
+ break;
+
+ case -EPROBE_DEFER:
+ return -EPROBE_DEFER;
+
+ default:
+ DSSERR("can't get DPLL VDDA regulator\n");
+ return r;
+ }
+ }
+
+ if (of_property_match_string(np, "reg-names", "pll1") >= 0) {
+ dss.video1_pll = dss_video_pll_init(pdev, 0, pll_regulator);
+ if (IS_ERR(dss.video1_pll))
+ return PTR_ERR(dss.video1_pll);
+ }
+
+ if (of_property_match_string(np, "reg-names", "pll2") >= 0) {
+ dss.video2_pll = dss_video_pll_init(pdev, 1, pll_regulator);
+ if (IS_ERR(dss.video2_pll)) {
+ dss_video_pll_uninit(dss.video1_pll);
+ return PTR_ERR(dss.video2_pll);
+ }
+ }
+
+ return 0;
+}
+
/* DSS HW IP initialisation */
static int __init omap_dsshw_probe(struct platform_device *pdev)
{
struct resource *dss_mem;
- struct device_node *np = pdev->dev.of_node;
u32 rev;
int r;
- struct regulator *pll_regulator;
dss.pdev = pdev;
@@ -1062,6 +1121,10 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
if (r)
goto err_setup_clocks;
+ r = dss_video_pll_probe(pdev);
+ if (r)
+ goto err_pll_init;
+
pm_runtime_enable(&pdev->dev);
r = dss_runtime_get();
@@ -1088,57 +1151,6 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
dss_init_ports(pdev);
- if (np && of_property_read_bool(np, "syscon-pll-ctrl")) {
- dss.syscon_pll_ctrl = syscon_regmap_lookup_by_phandle(np,
- "syscon-pll-ctrl");
- if (IS_ERR(dss.syscon_pll_ctrl)) {
- dev_err(&pdev->dev,
- "failed to get syscon-pll-ctrl regmap\n");
- return PTR_ERR(dss.syscon_pll_ctrl);
- }
-
- if (of_property_read_u32_index(np, "syscon-pll-ctrl", 1,
- &dss.syscon_pll_ctrl_offset)) {
- dev_err(&pdev->dev,
- "failed to get syscon-pll-ctrl offset\n");
- return -EINVAL;
- }
- }
-
- pll_regulator = devm_regulator_get(&pdev->dev, "vdda_video");
- if (IS_ERR(pll_regulator)) {
- r = PTR_ERR(pll_regulator);
-
- switch (r) {
- case -ENOENT:
- pll_regulator = NULL;
- break;
-
- case -EPROBE_DEFER:
- return -EPROBE_DEFER;
-
- default:
- DSSERR("can't get DPLL VDDA regulator\n");
- return r;
- }
- }
-
- if (of_property_match_string(np, "reg-names", "pll1") >= 0) {
- dss.video1_pll = dss_video_pll_init(pdev, 0, pll_regulator);
- if (IS_ERR(dss.video1_pll)) {
- r = PTR_ERR(dss.video1_pll);
- goto err_pll_init;
- }
- }
-
- if (of_property_match_string(np, "reg-names", "pll2") >= 0) {
- dss.video2_pll = dss_video_pll_init(pdev, 1, pll_regulator);
- if (IS_ERR(dss.video2_pll)) {
- r = PTR_ERR(dss.video2_pll);
- goto err_pll_init;
- }
- }
-
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -1153,14 +1165,15 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
return 0;
-err_pll_init:
+err_runtime_get:
+ pm_runtime_disable(&pdev->dev);
+
if (dss.video1_pll)
dss_video_pll_uninit(dss.video1_pll);
if (dss.video2_pll)
dss_video_pll_uninit(dss.video2_pll);
-err_runtime_get:
- pm_runtime_disable(&pdev->dev);
+err_pll_init:
err_setup_clocks:
dss_put_clocks();
return r;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/7] OMAPDSS: move 'dss_initialized' to dss driver
From: Tomi Valkeinen @ 2015-06-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434449789-13812-1-git-send-email-tomi.valkeinen@ti.com>
We have a flag, 'dss_initialized', which tells omapfb and omapdrm if
omapdss is available. At the moment it can be set even if the dss
submodules are not all ready, in case something gets deferred.
Move the flag to dss_core driver so that it'll signal the availability
of the dss drivers move accurately.
For now, it'll signal that dss_core is ready, which is not quite correct
but still better than previously. The following patches will add
component system to omapdss, and after those patches 'dss_initialized'
will signal that all the submodules are ready.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/core.c | 10 ----------
drivers/video/fbdev/omap2/dss/dss.c | 12 ++++++++++++
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/core.c b/drivers/video/fbdev/omap2/dss/core.c
index 16751755d433..57b6a5296c87 100644
--- a/drivers/video/fbdev/omap2/dss/core.c
+++ b/drivers/video/fbdev/omap2/dss/core.c
@@ -50,8 +50,6 @@ static char *def_disp_name;
module_param_named(def_disp, def_disp_name, charp, 0);
MODULE_PARM_DESC(def_disp, "default display name");
-static bool dss_initialized;
-
const char *omapdss_get_default_display_name(void)
{
return core.default_display_name;
@@ -65,12 +63,6 @@ enum omapdss_version omapdss_get_version(void)
}
EXPORT_SYMBOL(omapdss_get_version);
-bool omapdss_is_initialized(void)
-{
- return dss_initialized;
-}
-EXPORT_SYMBOL(omapdss_is_initialized);
-
struct platform_device *dss_get_core_pdev(void)
{
return core.pdev;
@@ -333,8 +325,6 @@ static int __init omap_dss_init(void)
dss_output_drv_loaded[i] = true;
}
- dss_initialized = true;
-
return 0;
err_dispc:
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 7f978b6a34e8..35601ab232e3 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -111,6 +111,14 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = "DSI_PLL2_HSDIV_DSI",
};
+static bool dss_initialized;
+
+bool omapdss_is_initialized(void)
+{
+ return dss_initialized;
+}
+EXPORT_SYMBOL(omapdss_is_initialized);
+
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -1141,6 +1149,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
pm_set_vt_switch(0);
+ dss_initialized = true;
+
return 0;
err_pll_init:
@@ -1158,6 +1168,8 @@ err_setup_clocks:
static int __exit omap_dsshw_remove(struct platform_device *pdev)
{
+ dss_initialized = false;
+
if (dss.video1_pll)
dss_video_pll_uninit(dss.video1_pll);
--
2.1.4
^ permalink raw reply related
* [PATCH 0/7] OMAPDSS: use components (fix probing problems)
From: Tomi Valkeinen @ 2015-06-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I noticed that on some platforms omapdss did not probe successfully. Some
resource was not available yet, but omapdss did not manage to handle deferred
probing. The reason was the use of platform_driver_probe() in combination with
how the omapdss module handles the drivers.
To fix this properly, the component system felt fine for the job, and it seems
to work nicely.
Tomi
Tomi Valkeinen (7):
OMAPDSS: move 'dss_initialized' to dss driver
OMAPDSS: refactor dss probe function
OMAPDSS: fix dss_init_ports error handling
OMAPDSS: remove uses of __init/__exit
OMAPDSS: reorder uninit calls
OMAPDSS: componentize omapdss
OMAPDSS: simplify submodule reg/unreg code
drivers/video/fbdev/omap2/dss/core.c | 80 ++++--------
drivers/video/fbdev/omap2/dss/dispc.c | 42 +++++--
drivers/video/fbdev/omap2/dss/dpi.c | 36 ++++--
drivers/video/fbdev/omap2/dss/dsi.c | 27 +++-
drivers/video/fbdev/omap2/dss/dss.c | 223 +++++++++++++++++++++++-----------
drivers/video/fbdev/omap2/dss/dss.h | 32 ++---
drivers/video/fbdev/omap2/dss/hdmi4.c | 28 ++++-
drivers/video/fbdev/omap2/dss/hdmi5.c | 28 ++++-
drivers/video/fbdev/omap2/dss/rfbi.c | 32 ++++-
drivers/video/fbdev/omap2/dss/sdi.c | 35 ++++--
drivers/video/fbdev/omap2/dss/venc.c | 31 +++--
11 files changed, 396 insertions(+), 198 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [Cocci] [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Tomi Valkeinen @ 2015-06-16 7:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAB=NE6UsMMoPhkKof+VN7ZUCd81VxrwP9nqHDUj5Lr3DJLm3bA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On 22/05/15 00:23, Luis R. Rodriguez wrote:
> On Wed, May 20, 2015 at 1:54 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> On Tue, May 19, 2015 at 10:53 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>>> On Wed, Apr 29, 2015 at 02:08:47PM -0700, Luis R. Rodriguez wrote:
>>>> On Tue, Apr 21, 2015 at 1:20 PM, Luis R. Rodriguez
>>>> <mcgrof@do-not-panic.com> wrote:
>>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>>
>>>>> This series adds pci_ioremap_wc_bar() and makes use of it
>>>>> on a few framebuffer device drivers.
>>>>>
>>>>> Luis R. Rodriguez (4):
>>>>> pci: add pci_ioremap_wc_bar()
>>>>> video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
>>>>> video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
>>>>> video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
>>>>
>>>> Bjorn,
>>>>
>>>> any feedback on this series?
>>>
>>> Hey Bjorn, any feedback on this series ?
>>
>> I meant this series. Also Tomi, do I get your Acks for these as well?
>> Since they depend on pci parts do you mind if we route them through
>> the PCI tree? I'll poke you soon about another similar type of patch
>> which has dependencies on another development tree.
>
> Bjorn, Tomi, please let me know if this series is OK, if so I'll
> resubmit rebased onto Bjorn's pci tree.
For the fbdev patches:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: propagate result of fb_videomode_from_videomode()
From: Tomi Valkeinen @ 2015-06-16 7:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1434117559-32130-1-git-send-email-vladimir.murzin@arm.com>
[-- Attachment #1: Type: text/plain, Size: 993 bytes --]
On 12/06/15 16:59, Vladimir Murzin wrote:
> fb_videomode_from_videomode() may fail, but of_get_fb_videomode()
> silently covers this fact. Instead, trow the error code to the
> caller.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
> ---
> drivers/video/fbdev/core/fbmon.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
> index 01ef1b9..d787533 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -1475,7 +1475,9 @@ int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> if (ret)
> return ret;
>
> - fb_videomode_from_videomode(&vm, fb);
> + ret = fb_videomode_from_videomode(&vm, fb);
> + if (ret)
> + return ret;
>
> pr_debug("%s: got %dx%d display mode from %s\n",
> of_node_full_name(np), vm.hactive, vm.vactive, np->name);
>
Thanks, queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] video: fbdev: vesafb: use arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-06-16 6:43 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, plagnioj, bp, hpa, linux-fbdev, luto,
toshi.kani, sbsiddha, mingo, tglx, jgross, daniel.vetter, airlied,
adaplas, robdclark, jg1.han, wsa, linux-kernel
In-Reply-To: <20150615222750.GF11147@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 6362 bytes --]
On 16/06/15 01:27, Luis R. Rodriguez wrote:
> On Fri, Jun 12, 2015 at 12:04:14PM +0300, Tomi Valkeinen wrote:
>>
>>
>> On 04/06/15 19:44, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> This driver uses the same area for MTRR as for the ioremap_wc(), if
>>> anything it just uses a smaller size in case MTRR reservation fails.
>>> ioremap_wc() API is already used to take advantage of architecture
>>> write-combining when available.
>>>
>>> Convert the driver from using the x86 specific MTRR code to
>>> the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
>>> will avoid MTRR if write-combining is available.
>>>
>>> There are a few motivations for this:
>>>
>>> a) Take advantage of PAT when available
>>>
>>> b) Help bury MTRR code away, MTRR is architecture specific and on
>>> x86 its replaced by PAT
>>>
>>> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>>> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>>> de33c442e titled "x86 PAT: fix performance drop for glx,
>>> use UC minus for ioremap(), ioremap_nocache() and
>>> pci_mmap_page_range()")
>>>
>>> The conversion done is expressed by the following Coccinelle
>>> SmPL patch, it additionally required manual intervention to
>>> address all the #ifdery and removal of redundant things which
>>> arch_phys_wc_add() already addresses such as verbose message
>>> about when MTRR fails and doing nothing when we didn't get
>>> an MTRR.
>>>
>>> @ mtrr_found @
>>> expression index, base, size;
>>> @@
>>>
>>> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
>>> +index = arch_phys_wc_add(base, size);
>>>
>>> @ mtrr_rm depends on mtrr_found @
>>> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
>>> @@
>>>
>>> -mtrr_del(index, base, size);
>>> +arch_phys_wc_del(index);
>>>
>>> @ mtrr_rm_zero_arg depends on mtrr_found @
>>> expression mtrr_found.index;
>>> @@
>>>
>>> -mtrr_del(index, 0, 0);
>>> +arch_phys_wc_del(index);
>>>
>>> @ mtrr_rm_fb_info depends on mtrr_found @
>>> struct fb_info *info;
>>> expression mtrr_found.index;
>>> @@
>>>
>>> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
>>> +arch_phys_wc_del(index);
>>>
>>> @ ioremap_replace_nocache depends on mtrr_found @
>>> struct fb_info *info;
>>> expression base, size;
>>> @@
>>>
>>> -info->screen_base = ioremap_nocache(base, size);
>>> +info->screen_base = ioremap_wc(base, size);
>>>
>>> @ ioremap_replace_default depends on mtrr_found @
>>> struct fb_info *info;
>>> expression base, size;
>>> @@
>>>
>>> -info->screen_base = ioremap(base, size);
>>> +info->screen_base = ioremap_wc(base, size);
>>>
>>> Generated-by: Coccinelle SmPL
>>> Cc: Toshi Kani <toshi.kani@hp.com>
>>> Cc: Suresh Siddha <sbsiddha@gmail.com>
>>> Cc: Ingo Molnar <mingo@elte.hu>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Juergen Gross <jgross@suse.com>
>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Cc: Andy Lutomirski <luto@amacapital.net>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Antonino Daplas <adaplas@gmail.com>
>>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>>> Cc: Rob Clark <robdclark@gmail.com>
>>> Cc: Jingoo Han <jg1.han@samsung.com>
>>> Cc: Wolfram Sang <wsa@the-dreams.de>
>>> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> Cc: linux-fbdev@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>>> ---
>>> drivers/video/fbdev/vesafb.c | 29 ++++++++---------------------
>>> 1 file changed, 8 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
>>> index 3db3908..528fe91 100644
>>> --- a/drivers/video/fbdev/vesafb.c
>>> +++ b/drivers/video/fbdev/vesafb.c
>>> @@ -19,10 +19,9 @@
>>> #include <linux/init.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/screen_info.h>
>>> +#include <linux/io.h>
>>>
>>> #include <video/vga.h>
>>> -#include <asm/io.h>
>>> -#include <asm/mtrr.h>
>>>
>>> #define dac_reg (0x3c8)
>>> #define dac_val (0x3c9)
>>> @@ -180,16 +179,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
>>>
>>> static void vesafb_destroy(struct fb_info *info)
>>> {
>>> -#ifdef CONFIG_MTRR
>>> struct vesafb_par *par = info->par;
>>> -#endif
>>>
>>> fb_dealloc_cmap(&info->cmap);
>>> -
>>> -#ifdef CONFIG_MTRR
>>> - if (par->wc_cookie >= 0)
>>> - mtrr_del(par->wc_cookie, 0, 0);
>>> -#endif
>>> + arch_phys_wc_del(par->wc_cookie);
>>> if (info->screen_base)
>>> iounmap(info->screen_base);
>>> release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
>>> @@ -420,7 +413,6 @@ static int vesafb_probe(struct platform_device *dev)
>>> request_region(0x3c0, 32, "vesafb");
>>>
>>> if (mtrr == 3) {
>>> -#ifdef CONFIG_MTRR
>>> unsigned int temp_size = size_total;
>>>
>>> /* Find the largest power-of-two */
>>> @@ -428,18 +420,16 @@ static int vesafb_probe(struct platform_device *dev)
>>>
>>> /* Try and find a power of two to add */
>>> do {
>>> - par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
>>> - temp_size,
>>> - MTRR_TYPE_WRCOMB, 1);
>>> + par->wc_cookie =
>>> + arch_phys_wc_add(vesafb_fix.smem_start,
>>> + temp_size);
>>> temp_size >>= 1;
>>> - } while (temp_size >= PAGE_SIZE && par->wc_cookie == -EINVAL);
>>> -#endif
>>> + } while (temp_size >= PAGE_SIZE && par->wc_cookie < 0);
>>> +
>>
>> Looks like arch_phys_wc_add prints a warning if it fails, and the above
>> loop may retry it many (?) times. Probably not a big issue, but may be
>> somewhat confusing.
>
> On most systems arch_phys_wc_add() won't ever run so I think that's a
> fair compromise to reach as we phase out MTRR. If we really wanted
> to fix this one could generalize the whole loop control stuff and use
> a new arch_phys API to generalize all that code as tons of drivers
> borrow the same logic. I decided this was pointless as we're phasing
> this out anyway and this code will simply be a no-op on most systems
> now.
>
> Let me know if you have any other preference or ideas.
Ok, sounds fine to me. I'll queue these for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 2/2] Staging: sm750fb: correct spacing between lines of code
From: Dighe, Niranjan (N.) @ 2015-06-16 5:05 UTC (permalink / raw)
To: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com
Cc: gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
From: Niranjan Dighe <ndighe@visteon.com>
This patch corrects line spacing by removing and adding newline
characters wherever necessary
Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
---
drivers/staging/sm750fb/ddk750_dvi.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h b/drivers/staging/sm750fb/ddk750_dvi.h
index c8d31f3..83bbd6d 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -14,6 +14,7 @@ typedef long (*PFN_DVICTRL_INIT)(
unsigned char continuousSyncEnable,
unsigned char pllFilterEnable,
unsigned char pllFilterValue);
+
typedef void (*PFN_DVICTRL_RESETCHIP)(void);
typedef char* (*PFN_DVICTRL_GETCHIPSTRING)(void);
typedef unsigned short (*PFN_DVICTRL_GETVENDORID)(void);
@@ -24,8 +25,6 @@ typedef unsigned char (*PFN_DVICTRL_ISCONNECTED)(void);
typedef unsigned char (*PFN_DVICTRL_CHECKINTERRUPT)(void);
typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
-
-
/* Structure to hold all the function pointer to the DVI Controller. */
typedef struct _dvi_ctrl_device_t
{
@@ -40,9 +39,8 @@ typedef struct _dvi_ctrl_device_t
PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
} dvi_ctrl_device_t;
-#define DVI_CTRL_SII164
-
+#define DVI_CTRL_SII164
/* dvi functions prototype */
int dviInit(
@@ -61,7 +59,5 @@ int dviInit(
unsigned short dviGetVendorID(void);
unsigned short dviGetDeviceID(void);
-
-
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] Staging: sm750fb: replace spaces by tabs
From: Dighe, Niranjan (N.) @ 2015-06-16 5:04 UTC (permalink / raw)
To: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com
Cc: gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
From: Niranjan Dighe <ndighe@visteon.com>
This patch replaces spaces by tabs at the start of the line and in
between variable declarations.
Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
---
drivers/staging/sm750fb/ddk750_dvi.h | 60 +++++++++++++++++-----------------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h b/drivers/staging/sm750fb/ddk750_dvi.h
index 50bcec2..c8d31f3 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -4,16 +4,16 @@
/* dvi chip stuffs structros */
typedef long (*PFN_DVICTRL_INIT)(
- unsigned char edgeSelect,
- unsigned char busSelect,
- unsigned char dualEdgeClkSelect,
- unsigned char hsyncEnable,
- unsigned char vsyncEnable,
- unsigned char deskewEnable,
- unsigned char deskewSetting,
- unsigned char continuousSyncEnable,
- unsigned char pllFilterEnable,
- unsigned char pllFilterValue);
+ unsigned char edgeSelect,
+ unsigned char busSelect,
+ unsigned char dualEdgeClkSelect,
+ unsigned char hsyncEnable,
+ unsigned char vsyncEnable,
+ unsigned char deskewEnable,
+ unsigned char deskewSetting,
+ unsigned char continuousSyncEnable,
+ unsigned char pllFilterEnable,
+ unsigned char pllFilterValue);
typedef void (*PFN_DVICTRL_RESETCHIP)(void);
typedef char* (*PFN_DVICTRL_GETCHIPSTRING)(void);
typedef unsigned short (*PFN_DVICTRL_GETVENDORID)(void);
@@ -29,16 +29,16 @@ typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
/* Structure to hold all the function pointer to the DVI Controller. */
typedef struct _dvi_ctrl_device_t
{
- PFN_DVICTRL_INIT pfnInit;
- PFN_DVICTRL_RESETCHIP pfnResetChip;
- PFN_DVICTRL_GETCHIPSTRING pfnGetChipString;
- PFN_DVICTRL_GETVENDORID pfnGetVendorId;
- PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
- PFN_DVICTRL_SETPOWER pfnSetPower;
- PFN_DVICTRL_HOTPLUGDETECTION pfnEnableHotPlugDetection;
- PFN_DVICTRL_ISCONNECTED pfnIsConnected;
- PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
- PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
+ PFN_DVICTRL_INIT pfnInit;
+ PFN_DVICTRL_RESETCHIP pfnResetChip;
+ PFN_DVICTRL_GETCHIPSTRING pfnGetChipString;
+ PFN_DVICTRL_GETVENDORID pfnGetVendorId;
+ PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
+ PFN_DVICTRL_SETPOWER pfnSetPower;
+ PFN_DVICTRL_HOTPLUGDETECTION pfnEnableHotPlugDetection;
+ PFN_DVICTRL_ISCONNECTED pfnIsConnected;
+ PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
+ PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
} dvi_ctrl_device_t;
#define DVI_CTRL_SII164
@@ -46,16 +46,16 @@ typedef struct _dvi_ctrl_device_t
/* dvi functions prototype */
int dviInit(
- unsigned char edgeSelect,
- unsigned char busSelect,
- unsigned char dualEdgeClkSelect,
- unsigned char hsyncEnable,
- unsigned char vsyncEnable,
- unsigned char deskewEnable,
- unsigned char deskewSetting,
- unsigned char continuousSyncEnable,
- unsigned char pllFilterEnable,
- unsigned char pllFilterValue
+ unsigned char edgeSelect,
+ unsigned char busSelect,
+ unsigned char dualEdgeClkSelect,
+ unsigned char hsyncEnable,
+ unsigned char vsyncEnable,
+ unsigned char deskewEnable,
+ unsigned char deskewSetting,
+ unsigned char continuousSyncEnable,
+ unsigned char pllFilterEnable,
+ unsigned char pllFilterValue
);
unsigned short dviGetVendorID(void);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 3/3] video: fbdev: vesafb: use arch_phys_wc_add()
From: Luis R. Rodriguez @ 2015-06-15 22:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Luis R. Rodriguez, plagnioj, bp, hpa, linux-fbdev, luto,
toshi.kani, sbsiddha, mingo, tglx, jgross, daniel.vetter, airlied,
adaplas, robdclark, jg1.han, wsa, linux-kernel
In-Reply-To: <557AA08E.6050606@ti.com>
On Fri, Jun 12, 2015 at 12:04:14PM +0300, Tomi Valkeinen wrote:
>
>
> On 04/06/15 19:44, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > This driver uses the same area for MTRR as for the ioremap_wc(), if
> > anything it just uses a smaller size in case MTRR reservation fails.
> > ioremap_wc() API is already used to take advantage of architecture
> > write-combining when available.
> >
> > Convert the driver from using the x86 specific MTRR code to
> > the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> > will avoid MTRR if write-combining is available.
> >
> > There are a few motivations for this:
> >
> > a) Take advantage of PAT when available
> >
> > b) Help bury MTRR code away, MTRR is architecture specific and on
> > x86 its replaced by PAT
> >
> > c) Help with the goal of eventually using _PAGE_CACHE_UC over
> > _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> > de33c442e titled "x86 PAT: fix performance drop for glx,
> > use UC minus for ioremap(), ioremap_nocache() and
> > pci_mmap_page_range()")
> >
> > The conversion done is expressed by the following Coccinelle
> > SmPL patch, it additionally required manual intervention to
> > address all the #ifdery and removal of redundant things which
> > arch_phys_wc_add() already addresses such as verbose message
> > about when MTRR fails and doing nothing when we didn't get
> > an MTRR.
> >
> > @ mtrr_found @
> > expression index, base, size;
> > @@
> >
> > -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> > +index = arch_phys_wc_add(base, size);
> >
> > @ mtrr_rm depends on mtrr_found @
> > expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> > @@
> >
> > -mtrr_del(index, base, size);
> > +arch_phys_wc_del(index);
> >
> > @ mtrr_rm_zero_arg depends on mtrr_found @
> > expression mtrr_found.index;
> > @@
> >
> > -mtrr_del(index, 0, 0);
> > +arch_phys_wc_del(index);
> >
> > @ mtrr_rm_fb_info depends on mtrr_found @
> > struct fb_info *info;
> > expression mtrr_found.index;
> > @@
> >
> > -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> > +arch_phys_wc_del(index);
> >
> > @ ioremap_replace_nocache depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> >
> > -info->screen_base = ioremap_nocache(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> >
> > @ ioremap_replace_default depends on mtrr_found @
> > struct fb_info *info;
> > expression base, size;
> > @@
> >
> > -info->screen_base = ioremap(base, size);
> > +info->screen_base = ioremap_wc(base, size);
> >
> > Generated-by: Coccinelle SmPL
> > Cc: Toshi Kani <toshi.kani@hp.com>
> > Cc: Suresh Siddha <sbsiddha@gmail.com>
> > Cc: Ingo Molnar <mingo@elte.hu>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Juergen Gross <jgross@suse.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Andy Lutomirski <luto@amacapital.net>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Antonino Daplas <adaplas@gmail.com>
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> > drivers/video/fbdev/vesafb.c | 29 ++++++++---------------------
> > 1 file changed, 8 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> > index 3db3908..528fe91 100644
> > --- a/drivers/video/fbdev/vesafb.c
> > +++ b/drivers/video/fbdev/vesafb.c
> > @@ -19,10 +19,9 @@
> > #include <linux/init.h>
> > #include <linux/platform_device.h>
> > #include <linux/screen_info.h>
> > +#include <linux/io.h>
> >
> > #include <video/vga.h>
> > -#include <asm/io.h>
> > -#include <asm/mtrr.h>
> >
> > #define dac_reg (0x3c8)
> > #define dac_val (0x3c9)
> > @@ -180,16 +179,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
> >
> > static void vesafb_destroy(struct fb_info *info)
> > {
> > -#ifdef CONFIG_MTRR
> > struct vesafb_par *par = info->par;
> > -#endif
> >
> > fb_dealloc_cmap(&info->cmap);
> > -
> > -#ifdef CONFIG_MTRR
> > - if (par->wc_cookie >= 0)
> > - mtrr_del(par->wc_cookie, 0, 0);
> > -#endif
> > + arch_phys_wc_del(par->wc_cookie);
> > if (info->screen_base)
> > iounmap(info->screen_base);
> > release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
> > @@ -420,7 +413,6 @@ static int vesafb_probe(struct platform_device *dev)
> > request_region(0x3c0, 32, "vesafb");
> >
> > if (mtrr = 3) {
> > -#ifdef CONFIG_MTRR
> > unsigned int temp_size = size_total;
> >
> > /* Find the largest power-of-two */
> > @@ -428,18 +420,16 @@ static int vesafb_probe(struct platform_device *dev)
> >
> > /* Try and find a power of two to add */
> > do {
> > - par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
> > - temp_size,
> > - MTRR_TYPE_WRCOMB, 1);
> > + par->wc_cookie > > + arch_phys_wc_add(vesafb_fix.smem_start,
> > + temp_size);
> > temp_size >>= 1;
> > - } while (temp_size >= PAGE_SIZE && par->wc_cookie = -EINVAL);
> > -#endif
> > + } while (temp_size >= PAGE_SIZE && par->wc_cookie < 0);
> > +
>
> Looks like arch_phys_wc_add prints a warning if it fails, and the above
> loop may retry it many (?) times. Probably not a big issue, but may be
> somewhat confusing.
On most systems arch_phys_wc_add() won't ever run so I think that's a
fair compromise to reach as we phase out MTRR. If we really wanted
to fix this one could generalize the whole loop control stuff and use
a new arch_phys API to generalize all that code as tons of drivers
borrow the same logic. I decided this was pointless as we're phasing
this out anyway and this code will simply be a no-op on most systems
now.
Let me know if you have any other preference or ideas.
Luis
^ permalink raw reply
* Re: [PATCH] Staging: sm750fb: Fix checkpatch.pl warnings
From: Dighe, Niranjan (N.) @ 2015-06-15 10:23 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: teddy.wang@siliconmotion.com, gregkh@linuxfoundation.org,
linux-fbdev@vger.kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20150615052733.GB21087@sudip-PC>
On Mon, Jun 15, 2015 at 10:57:33AM +0530, Sudip Mukherjee wrote:
> On Sun, Jun 14, 2015 at 05:17:43PM +0000, Dighe, Niranjan (N.) wrote:
> > From: Niranjan Dighe <ndighe@visteon.com>
> >
> > This patch removes spaces at the start of the line and replaces it
> > by tabs
> You are also removing blank lines, adding blank lines, moving a ')' to
> next line.
>
> regards
> sudip
Alright. I will modify the patch and resend.
Thanks,
Niranjan
^ permalink raw reply
* Re: [PATCH 00/21] On-demand device registration
From: Alexander Holler @ 2015-06-15 9:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Tomeu Vizoso, Grant Likely, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Torokhov,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
DRM PANEL DRIVERS, dmaengine-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkdaVZmq_w_qgEgTP5oqfH3K1+80O7z7o7CJx-dhivUGhDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am 15.06.2015 um 10:58 schrieb Linus Walleij:
> On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>
>> And because you've said that "problem space is a bit convoluted" and I
>> disagree, here's a summary from my point of view:
>>
>> 1. All the necessary information (dependencies between drivers) already
>> exists at compile time. The set of dependencies between drivers might become
>> smaller by configuration, but will not become larger. So there should be NO
>> need to collect them at runtime, e.g. by instrumenting function calls.
>
> I think you arrived at the core of the crux here.
I've hoped so, that's why I've written it.
> I guess your suggested approach then need to introduce a special
> build tool to order the initcalls accordingly.
>
> Again this will fall short if you don't know at compile time exactly
> *which* board file will be executed.
I've just tried to describe the facts in order to make the problem space
more clear, because, as said, I don't think it's convoluted.
Besides that, I didn't want to suggest anything else other than what
I've already posted working patches for. What I've mentioned as possible
other solutions above is stuff which might be possible too in order to
give some starting points for people which are searching another
solution. But I wouldn't have written my patches as they are, if I would
think there is another more easier solution.
And of course, there is still a bit to resolve at runtime, even in the
DT case (look at the "compatible" attribute). But there is already a
runtime solution to find the right driver (in case of DT) and I haven't
mentioned it in order to no confuse people again. Mentioning every
little detail doesn't make sense if you want to describe something
understandable (which is what I've tried).
> So the only practical way to solve this at compile time is to predict
> an initcall ordering sequence for all possible boot paths, compile in
> all of them, and choose the right one at boot. But the number of boot
> paths is equal to the number of device trees / ACPI tables or
> board files supported, and that space is uncontrolled and ordered
> infinite.
You just need one working ordered sequence which includes all options.
This one will work for all others too.
> Basically I think the root problem with your approach is that you
> assume we know what hardware we will boot on at compile time. We
Totally wrong. If you assume that I assume this, than either I was
totally unable to describe something clearly, or you were unable or
unwilling to understand what I've written. And as the result is the
same, we don't need to find out which was reason.
Anyway, have fun. I'm quitting the discussion here as I don't have any
business with the kernel and already decided some time again to not post
patches anymore as it seems to be a waste of my (and maybe others) time.
Regards,
Alexander Holler
^ permalink raw reply
* Re: [PATCH 00/21] On-demand device registration
From: Linus Walleij @ 2015-06-15 8:58 UTC (permalink / raw)
To: Alexander Holler
Cc: Tomeu Vizoso, Grant Likely, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Torokhov,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
DRM PANEL DRIVERS, dmaengine-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <557C7609.30400-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
On Sat, Jun 13, 2015 at 8:27 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> And because you've said that "problem space is a bit convoluted" and I
> disagree, here's a summary from my point of view:
>
> 1. All the necessary information (dependencies between drivers) already
> exists at compile time. The set of dependencies between drivers might become
> smaller by configuration, but will not become larger. So there should be NO
> need to collect them at runtime, e.g. by instrumenting function calls.
I think you arrived at the core of the crux here.
When we look up a resource provided from another driver, e.g. from
regulator_get(), clk_get(), pinctrl_get(), gpiod_get() etc - the dependency
is resolved by looking in a cross-reference table for either a struct device*
pointer or a string, an index, or both or all three. Examples:
struct regulator *regulator_get(struct device *dev, const char *id);
struct clk *clk_get(struct device *dev, const char *id);
struct gpio_desc *__must_check __gpiod_get(struct device *dev,
const char *con_id,
enum gpiod_flags flags);
(...)
(*_index() variants exist on some of the resource retrieveal
functions.)
struct device * is the device requesting the resource, con_id
is the string name of the resource on the provider side. This is all
solved by looking in cross reference tables. ONE way of resolving
that cross reference is to look into the device tree or the ACPI table.
But for the board file case, this is resolved at runtime by the cross
reference table, registered with calls such as gpiod_add_lookup_table().
It is true that in the theoretical sense, all of this exist at compile time
especially if you can parse something like a device tree and
figure out what struct device * nodes will correspond to the struct
device_node:s in it. For ACPI I guess a similar procedure is viable.
Problem: this requires the kernel compile to know exactly *which* device tree
or ACPI table it is going to boot on. The expressed goal of device tree
and ACPI is to have *ONE* kernel booting several device trees.
Here your approach stops short: you are suggesting instrumenting
the kernel at compile time to one single device tree or ACPI table.
But we never know really what device tree or ACPI table will be used.
This just cannot be done at compile time for that reason alone.
Example: in boot case (A) the regulator may be provided by regulator
"foo" driver on an i2c bus. But in boot case (B) the very same regulator
may be provided by regulator "bar" on an SPI bus. These are very
real usecases, for example for drivers/net/ethernet/smsc/smsc911x.c,
will get regulators from the most diverse places depending on what
device tree is used.
For board files, it is neither possible in theory: you need to compile the
code to figure out the struct device * provider, and/or the string name
of the providing device (.name field in struct device for the provider)
to resolve dependencies at compile time.
For the board file case, resolving dependencies at compile time will
require a quite complex two-stage rocket: compile the code to
get resources out, then recompile with known resources.
I guess your suggested approach then need to introduce a special
build tool to order the initcalls accordingly.
Again this will fall short if you don't know at compile time exactly
*which* board file will be executed.
So the only practical way to solve this at compile time is to predict
an initcall ordering sequence for all possible boot paths, compile in
all of them, and choose the right one at boot. But the number of boot
paths is equal to the number of device trees / ACPI tables or
board files supported, and that space is uncontrolled and ordered
infinite.
Basically I think the root problem with your approach is that you
assume we know what hardware we will boot on at compile time. We
discarded that development path years ago. We have no clue, this
is resolved at runtime. Alas, people still create super-optimized
systems using exactly this knowledge, but it is not our main target
here, it is a special optimization case.
Yours,
Linus Walleij
^ permalink raw reply
* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
From: Joe Perches @ 2015-06-15 6:36 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
dan.carpenter
In-Reply-To: <20150615051712.GA21087@sudip-PC>
On Mon, 2015-06-15 at 10:47 +0530, Sudip Mukherjee wrote:
> On Sat, Jun 13, 2015 at 09:57:05AM -0700, Joe Perches wrote:
> > It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.
> instead of #ifdef __BIG_ENDIAN can i then use a bool flag to check by if-else?
I think that'd be worse. Moving the #ifdef into the .h
may be better, but <shrug>, whatever works well enough.
Another thing may be to move the vgamode array declaration
in fb7xx.h to the .c file and make it const and remove the
#define numvgamodes and just use ARRAY_SIZE directly in
the one place it's used.
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Jan Beulich @ 2015-06-15 6:20 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Luis R. Rodriguez, Bjorn Helgaas, Jej B, Toshi Kani, X86 ML,
Andrew Morton, ville.syrjala, Julia Lawall,
xen-devel@lists.xenproject.org, Dave Airlie, syrjala,
Juergen Gross, Luis Rodriguez, Borislav Petkov, Tomi Valkeinen,
linux-fbdev, linux-kernel@vger.kernel.org, linux-media,
linux-pci@vger.kernel.org
In-Reply-To: <CALCETrXWZU2NZRZy7b74z54Tt5aKmTOmgMmf5WYG1OZtEmjw7A@mail.gmail.com>
>>> On 13.06.15 at 01:15, <luto@amacapital.net> wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>> >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
>> > There are two usages on MTRRs:
>> > 1) MTRR entries set by firmware
>> > 2) MTRR entries set by OS drivers
>> >
>> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
>> > also set this up, this usage will continue to stay. So, we should not
>> > get rid of the MTRR code that looks up the MTRR entries, while we have
>> > no need to modify them.
>> >
>> > Such MTRR entries provide safe guard to /dev/mem, which allows
>> > privileged user to access a range that may require UC mapping while
>> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
>> > such a case.
>>
>> But it wouldn't be impossible to simply read the MTRRs upon boot,
>> store the information, disable MTRRs, and correctly use PAT to
>> achieve the same effect (i.e. the "blindly maps" part of course
>> would need fixing).
>
> This may crash and burn badly when we call a UEFI function or an SMI
> happens. I think we should just leave the MTRRs alone.
I buy the SMI part, but UEFI runtime calls are being done on
page tables we construct and control, so attributes could be kept
correct without relying on MTRRs.
Jan
^ permalink raw reply
* Re: [PATCH] Staging: sm750fb: Fix checkpatch.pl warnings
From: Sudip Mukherjee @ 2015-06-15 5:39 UTC (permalink / raw)
To: Dighe, Niranjan (N.)
Cc: teddy.wang@siliconmotion.com, gregkh@linuxfoundation.org,
linux-fbdev@vger.kernel.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20150614171728.GA5800@codebox>
On Sun, Jun 14, 2015 at 05:17:43PM +0000, Dighe, Niranjan (N.) wrote:
> From: Niranjan Dighe <ndighe@visteon.com>
>
> This patch removes spaces at the start of the line and replaces it
> by tabs
You are also removing blank lines, adding blank lines, moving a ')' to
next line.
regards
sudip
^ permalink raw reply
* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
From: Sudip Mukherjee @ 2015-06-15 5:29 UTC (permalink / raw)
To: Joe Perches
Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
dan.carpenter
In-Reply-To: <1434214625.2507.9.camel@perches.com>
On Sat, Jun 13, 2015 at 09:57:05AM -0700, Joe Perches wrote:
>
> It seems ready to me.
>
> As far as I can tell, there's just a few niggles
> that could be done:
>
> Something like (too lazy to separate them into multiple patches)
Thanks. I will break into patches. Call me lazy for not having it done
till now.
>
> o reduce indentation a couple of places
> o add newlines to logging messages
> o add const to static array
> o use consistent function declaration style
>
> It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.
instead of #ifdef __BIG_ENDIAN can i then use a bool flag to check by if-else?
regards
sudip
^ permalink raw reply
* Klientskie bazi tel +79133913837 Email: nonen22pp@gmail.com Yznaite podrobnee!!!
From: @ 2015-06-15 5:02 UTC (permalink / raw)
To: linux-fbdev
Klientskie bazi tel +79133913837 Email: nonen22pp@gmail.com Yznaite podrobnee!!!
^ permalink raw reply
* Re: [PATCH] Staging: sm750fb: fix checkpatch.pl indentation warnings
From: Dighe, Niranjan (N.) @ 2015-06-15 3:34 UTC (permalink / raw)
To: Markus Böhme
Cc: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <557DCBAE.8070109@mailbox.org>
On Sun, Jun 14, 2015 at 08:45:02PM +0200, Markus Böhme wrote:
> >This patch fixes indentation issues by replacing spaces by tabs at
> >the start of line
> >
> >Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
> >
> >diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
> >index b2bf7e6..c73b74a 100644
> >--- a/drivers/staging/sm750fb/ddk750_dvi.c
> >+++ b/drivers/staging/sm750fb/ddk750_dvi.c
>
> >- if(pCurrentDviCtrl->pfnInit != NULL)
> >+ if (pCurrentDviCtrl->pfnInit != NULL)
>
> You are fixing a different type of warning here. Please make only one
> kind of change per patch.
>
> Regards,
> Markus
>
Hello Markus,
Thanks for your review. I will correct and resend a new patch. Please disregard
this for the moment.
Thanks,
Niranjan Dighe
^ permalink raw reply
* Re: [PATCH] Staging: sm750fb: fix checkpatch.pl indentation warnings
From: Markus Böhme @ 2015-06-14 18:45 UTC (permalink / raw)
To: Dighe, Niranjan (N.)
Cc: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <20150614174339.GA6105@codebox>
> This patch fixes indentation issues by replacing spaces by tabs at
> the start of line
>
> Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
>
> diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
> index b2bf7e6..c73b74a 100644
> --- a/drivers/staging/sm750fb/ddk750_dvi.c
> +++ b/drivers/staging/sm750fb/ddk750_dvi.c
> - if(pCurrentDviCtrl->pfnInit != NULL)
> + if (pCurrentDviCtrl->pfnInit != NULL)
You are fixing a different type of warning here. Please make only one
kind of change per patch.
Regards,
Markus
^ permalink raw reply
* [PATCH] Staging: sm750fb: fix checkpatch.pl indentation warnings
From: Dighe, Niranjan (N.) @ 2015-06-14 17:43 UTC (permalink / raw)
To: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <20150614171728.GA5800@codebox>
From: Niranjan Dighe <ndighe@visteon.com>
This patch fixes indentation issues by replacing spaces by tabs at
the start of line
Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index b2bf7e6..c73b74a 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -1,4 +1,4 @@
-#define USE_DVICHIP
+#define USE_DVICHIP
#ifdef USE_DVICHIP
#include "ddk750_help.h"
#include "ddk750_reg.h"
@@ -12,44 +12,43 @@
static dvi_ctrl_device_t g_dcftSupportedDviController[] {
#ifdef DVI_CTRL_SII164
- {
- .pfnInit = sii164InitChip,
- .pfnGetVendorId = sii164GetVendorID,
- .pfnGetDeviceId = sii164GetDeviceID,
+ {
+ .pfnInit = sii164InitChip,
+ .pfnGetVendorId = sii164GetVendorID,
+ .pfnGetDeviceId = sii164GetDeviceID,
#ifdef SII164_FULL_FUNCTIONS
- .pfnResetChip = sii164ResetChip,
- .pfnGetChipString = sii164GetChipString,
- .pfnSetPower = sii164SetPower,
- .pfnEnableHotPlugDetection = sii164EnableHotPlugDetection,
- .pfnIsConnected = sii164IsConnected,
- .pfnCheckInterrupt = sii164CheckInterrupt,
- .pfnClearInterrupt = sii164ClearInterrupt,
+ .pfnResetChip = sii164ResetChip,
+ .pfnGetChipString = sii164GetChipString,
+ .pfnSetPower = sii164SetPower,
+ .pfnEnableHotPlugDetection = sii164EnableHotPlugDetection,
+ .pfnIsConnected = sii164IsConnected,
+ .pfnCheckInterrupt = sii164CheckInterrupt,
+ .pfnClearInterrupt = sii164ClearInterrupt,
#endif
- },
+ },
#endif
};
-
int dviInit(
- unsigned char edgeSelect,
- unsigned char busSelect,
- unsigned char dualEdgeClkSelect,
- unsigned char hsyncEnable,
- unsigned char vsyncEnable,
- unsigned char deskewEnable,
- unsigned char deskewSetting,
- unsigned char continuousSyncEnable,
- unsigned char pllFilterEnable,
- unsigned char pllFilterValue
- )
+ unsigned char edgeSelect,
+ unsigned char busSelect,
+ unsigned char dualEdgeClkSelect,
+ unsigned char hsyncEnable,
+ unsigned char vsyncEnable,
+ unsigned char deskewEnable,
+ unsigned char deskewSetting,
+ unsigned char continuousSyncEnable,
+ unsigned char pllFilterEnable,
+ unsigned char pllFilterValue
+)
{
dvi_ctrl_device_t *pCurrentDviCtrl;
pCurrentDviCtrl = g_dcftSupportedDviController;
- if(pCurrentDviCtrl->pfnInit != NULL)
+ if (pCurrentDviCtrl->pfnInit != NULL)
{
return pCurrentDviCtrl->pfnInit(edgeSelect, busSelect, dualEdgeClkSelect, hsyncEnable,
- vsyncEnable, deskewEnable, deskewSetting, continuousSyncEnable,
- pllFilterEnable, pllFilterValue);
+ vsyncEnable, deskewEnable, deskewSetting, continuousSyncEnable,
+ pllFilterEnable, pllFilterValue);
}
return -1; /* error */
}
@@ -64,13 +63,13 @@ int dviInit(
*/
unsigned short dviGetVendorID(void)
{
- dvi_ctrl_device_t *pCurrentDviCtrl;
+ dvi_ctrl_device_t *pCurrentDviCtrl;
- pCurrentDviCtrl = g_dcftSupportedDviController;
- if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
- return pCurrentDviCtrl->pfnGetVendorId();
+ pCurrentDviCtrl = g_dcftSupportedDviController;
+ if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
+ return pCurrentDviCtrl->pfnGetVendorId();
- return 0x0000;
+ return 0x0000;
}
@@ -83,15 +82,14 @@ unsigned short dviGetVendorID(void)
*/
unsigned short dviGetDeviceID(void)
{
- dvi_ctrl_device_t *pCurrentDviCtrl;
+ dvi_ctrl_device_t *pCurrentDviCtrl;
pCurrentDviCtrl = g_dcftSupportedDviController;
- if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
- return pCurrentDviCtrl->pfnGetDeviceId();
+ if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
+ return pCurrentDviCtrl->pfnGetDeviceId();
- return 0x0000;
+ return 0x0000;
}
#endif
-
--
1.9.1
^ permalink raw reply related
* [PATCH] Staging: sm750fb: Fix checkpatch.pl warnings
From: Dighe, Niranjan (N.) @ 2015-06-14 17:17 UTC (permalink / raw)
To: sudipm.mukherjee@gmail.com, teddy.wang@siliconmotion.com,
gregkh@linuxfoundation.org, linux-fbdev@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
From: Niranjan Dighe <ndighe@visteon.com>
This patch removes spaces at the start of the line and replaces it
by tabs
Signed-off-by: Niranjan Dighe <ndighe@visteon.com>
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h b/drivers/staging/sm750fb/ddk750_dvi.h
index 50bcec2..cbd87c1 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -4,16 +4,18 @@
/* dvi chip stuffs structros */
typedef long (*PFN_DVICTRL_INIT)(
- unsigned char edgeSelect,
- unsigned char busSelect,
- unsigned char dualEdgeClkSelect,
- unsigned char hsyncEnable,
- unsigned char vsyncEnable,
- unsigned char deskewEnable,
- unsigned char deskewSetting,
- unsigned char continuousSyncEnable,
- unsigned char pllFilterEnable,
- unsigned char pllFilterValue);
+ unsigned char edgeSelect,
+ unsigned char busSelect,
+ unsigned char dualEdgeClkSelect,
+ unsigned char hsyncEnable,
+ unsigned char vsyncEnable,
+ unsigned char deskewEnable,
+ unsigned char deskewSetting,
+ unsigned char continuousSyncEnable,
+ unsigned char pllFilterEnable,
+ unsigned char pllFilterValue
+);
+
typedef void (*PFN_DVICTRL_RESETCHIP)(void);
typedef char* (*PFN_DVICTRL_GETCHIPSTRING)(void);
typedef unsigned short (*PFN_DVICTRL_GETVENDORID)(void);
@@ -24,44 +26,39 @@ typedef unsigned char (*PFN_DVICTRL_ISCONNECTED)(void);
typedef unsigned char (*PFN_DVICTRL_CHECKINTERRUPT)(void);
typedef void (*PFN_DVICTRL_CLEARINTERRUPT)(void);
-
-
/* Structure to hold all the function pointer to the DVI Controller. */
typedef struct _dvi_ctrl_device_t
{
- PFN_DVICTRL_INIT pfnInit;
- PFN_DVICTRL_RESETCHIP pfnResetChip;
- PFN_DVICTRL_GETCHIPSTRING pfnGetChipString;
- PFN_DVICTRL_GETVENDORID pfnGetVendorId;
- PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
- PFN_DVICTRL_SETPOWER pfnSetPower;
- PFN_DVICTRL_HOTPLUGDETECTION pfnEnableHotPlugDetection;
- PFN_DVICTRL_ISCONNECTED pfnIsConnected;
- PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
- PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
+ PFN_DVICTRL_INIT pfnInit;
+ PFN_DVICTRL_RESETCHIP pfnResetChip;
+ PFN_DVICTRL_GETCHIPSTRING pfnGetChipString;
+ PFN_DVICTRL_GETVENDORID pfnGetVendorId;
+ PFN_DVICTRL_GETDEVICEID pfnGetDeviceId;
+ PFN_DVICTRL_SETPOWER pfnSetPower;
+ PFN_DVICTRL_HOTPLUGDETECTION pfnEnableHotPlugDetection;
+ PFN_DVICTRL_ISCONNECTED pfnIsConnected;
+ PFN_DVICTRL_CHECKINTERRUPT pfnCheckInterrupt;
+ PFN_DVICTRL_CLEARINTERRUPT pfnClearInterrupt;
} dvi_ctrl_device_t;
-#define DVI_CTRL_SII164
-
+#define DVI_CTRL_SII164
/* dvi functions prototype */
int dviInit(
- unsigned char edgeSelect,
- unsigned char busSelect,
- unsigned char dualEdgeClkSelect,
- unsigned char hsyncEnable,
- unsigned char vsyncEnable,
- unsigned char deskewEnable,
- unsigned char deskewSetting,
- unsigned char continuousSyncEnable,
- unsigned char pllFilterEnable,
- unsigned char pllFilterValue
+ unsigned char edgeSelect,
+ unsigned char busSelect,
+ unsigned char dualEdgeClkSelect,
+ unsigned char hsyncEnable,
+ unsigned char vsyncEnable,
+ unsigned char deskewEnable,
+ unsigned char deskewSetting,
+ unsigned char continuousSyncEnable,
+ unsigned char pllFilterEnable,
+ unsigned char pllFilterValue
);
unsigned short dviGetVendorID(void);
unsigned short dviGetDeviceID(void);
-
-
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH] backlight: pwm: free pwm requested by legacy API on error path
From: Vladimir Zapolskiy @ 2015-06-14 14:32 UTC (permalink / raw)
To: Lee Jones, Jingoo Han, Thierry Reding; +Cc: linux-pwm, linux-fbdev
If pwm is requested by legacy pwm_request() and if the following
backlight_device_register() call fails, add pwm_free() clean-up.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
drivers/video/backlight/pwm_bl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 9991cdb..a691247 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -307,6 +307,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
if (IS_ERR(bl)) {
dev_err(&pdev->dev, "failed to register backlight\n");
ret = PTR_ERR(bl);
+ if (pb->legacy)
+ pwm_free(pb->pwm);
goto err_alloc;
}
--
2.1.4
^ permalink raw reply related
* [PATCH] backlight: pwm: reject legacy pwm request for device defined in dt
From: Vladimir Zapolskiy @ 2015-06-14 14:29 UTC (permalink / raw)
To: Lee Jones, Jingoo Han, Thierry Reding; +Cc: linux-pwm, linux-fbdev
Platform PWM backlight data provided by board's device tree should be
complete enough to successfully request a pwm device using pwm_get()
API. This change fixes a bug, when an arbitrary (first found) PWM is
connected to a "pwm-backlight" compatible device, when explicit PWM
device reference is not given.
Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
already describes "pwms" as a required property, instead of blind
selection of a potentially wrong PWM reject legacy PWM device
registration request, leave legacy API only for non-dt cases.
Based on initial implementation done by Dmitry Eremin-Solenikov.
Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
---
drivers/video/backlight/pwm_bl.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 57cb9ec..9991cdb 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -271,15 +271,16 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
- if (IS_ERR(pb->pwm)) {
+ if (IS_ERR(pb->pwm) && !pdev->dev.of_node) {
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
- if (IS_ERR(pb->pwm)) {
- dev_err(&pdev->dev, "unable to request legacy PWM\n");
- ret = PTR_ERR(pb->pwm);
- goto err_alloc;
- }
+ }
+
+ if (IS_ERR(pb->pwm)) {
+ dev_err(&pdev->dev, "unable to request PWM\n");
+ ret = PTR_ERR(pb->pwm);
+ goto err_alloc;
}
dev_dbg(&pdev->dev, "got pwm for backlight\n");
--
2.1.4
^ permalink raw reply related
* [RFC v2 17/24] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_wri
From: Finn Thain @ 2015-06-14 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150614074607.242676098@telegraphics.com.au>
Make use of arch_nvram_ops in device drivers so that the nvram_*
function exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
arch/powerpc/kernel/setup_32.c | 8 ++++----
drivers/char/generic_nvram.c | 4 ++--
drivers/video/fbdev/controlfb.c | 4 ++--
drivers/video/fbdev/imsttfb.c | 7 +++----
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/platinumfb.c | 4 ++--
drivers/video/fbdev/valkyriefb.c | 4 ++--
7 files changed, 16 insertions(+), 17 deletions(-)
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:53.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:54.000000000 +1000
@@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-06-14 17:45:53.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-06-14 17:45:54.000000000 +1000
@@ -64,7 +64,7 @@ static ssize_t read_nvram(struct file *f
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
return -EFAULT;
*ppos = i;
return p - buf;
@@ -84,7 +84,7 @@ static ssize_t write_nvram(struct file *
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
Index: linux/drivers/video/fbdev/controlfb.c
=================================--- linux.orig/drivers/video/fbdev/controlfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/controlfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -415,7 +415,7 @@ static int __init init_control(struct fb
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -423,7 +423,7 @@ static int __init init_control(struct fb
cmodeÞfault_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode = VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:49.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:54.000000000 +1000
@@ -1888,7 +1888,7 @@ static int initMatrox2(struct matrox_fb_
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/platinumfb.c
=================================--- linux.orig/drivers/video/fbdev/platinumfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/platinumfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -349,7 +349,7 @@ static int platinum_init_fb(struct fb_in
printk(KERN_INFO "platinumfb: Monitor sense value = 0x%x, ", sense);
if (default_vmode = VMODE_NVRAM) {
#ifdef CONFIG_NVRAM
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0 || default_vmode > VMODE_MAX ||
!platinum_reg_init[default_vmode-1])
#endif
@@ -362,7 +362,7 @@ static int platinum_init_fb(struct fb_in
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-06-14 17:45:54.000000000 +1000
@@ -287,7 +287,7 @@ static void __init valkyrie_choose_mode(
/* Try to pick a video mode out of NVRAM if we have one. */
#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0
|| default_vmode > VMODE_MAX
|| !valkyrie_reg_init[default_vmode - 1])
@@ -300,7 +300,7 @@ static void __init valkyrie_choose_mode(
default_vmode = VMODE_640_480_67;
#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
/*
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -328,7 +328,6 @@ enum {
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
@@ -1391,17 +1390,17 @@ static void init_imstt(struct fb_info *i
}
}
-#if USE_NV_MODES && defined(CONFIG_PPC32)
+#if defined(CONFIG_NVRAM) && defined(CONFIG_PPC32)
{
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode <= 0 || vmode > VMODE_MAX)
vmode = VMODE_640_480_67;
}
if (cmode = -1) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if (cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
}
^ 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