* [PATCH V2 3/6] fbdev: sa1100fb: make use of device clock
From: Dmitry Eremin-Solenikov @ 2014-11-24 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416870336-30114-1-git-send-email-dbaryshkov@gmail.com>
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/sa1100fb.c | 30 +++++++++++++++++++++++-------
drivers/video/fbdev/sa1100fb.h | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index 580c444e..2133cf1 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -178,6 +178,7 @@
#include <linux/dma-mapping.h>
#include <linux/mutex.h>
#include <linux/io.h>
+#include <linux/clk.h>
#include <video/sa1100fb.h>
@@ -413,9 +414,9 @@ sa1100fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
var->transp.offset);
#ifdef CONFIG_CPU_FREQ
- dev_dbg(fbi->dev, "dma period = %d ps, clock = %d kHz\n",
+ dev_dbg(fbi->dev, "dma period = %d ps, clock = %ld kHz\n",
sa1100fb_display_dma_period(var),
- cpufreq_get(smp_processor_id()));
+ clk_get_rate(fbi->clk) / 1000);
#endif
return 0;
@@ -586,9 +587,10 @@ static struct fb_ops sa1100fb_ops = {
* Calculate the PCD value from the clock rate (in picoseconds).
* We take account of the PPCR clock setting.
*/
-static inline unsigned int get_pcd(unsigned int pixclock, unsigned int cpuclock)
+static inline unsigned int get_pcd(struct sa1100fb_info *fbi,
+ unsigned int pixclock)
{
- unsigned int pcd = cpuclock / 100;
+ unsigned int pcd = clk_get_rate(fbi->clk) / 100 / 1000;
pcd *= pixclock;
pcd /= 10000000;
@@ -667,7 +669,7 @@ static int sa1100fb_activate_var(struct fb_var_screeninfo *var, struct sa1100fb_
LCCR2_BegFrmDel(var->upper_margin) +
LCCR2_EndFrmDel(var->lower_margin);
- pcd = get_pcd(var->pixclock, cpufreq_get(0));
+ pcd = get_pcd(fbi, var->pixclock);
new_regs.lccr3 = LCCR3_PixClkDiv(pcd) | fbi->inf->lccr3 |
(var->sync & FB_SYNC_HOR_HIGH_ACT ? LCCR3_HorSnchH : LCCR3_HorSnchL) |
(var->sync & FB_SYNC_VERT_HIGH_ACT ? LCCR3_VrtSnchH : LCCR3_VrtSnchL);
@@ -781,6 +783,9 @@ static void sa1100fb_enable_controller(struct sa1100fb_info *fbi)
fbi->palette_cpu[0] &= 0xcfff;
fbi->palette_cpu[0] |= palette_pbs(&fbi->fb.var);
+ /* enable LCD controller clock */
+ clk_prepare_enable(fbi->clk);
+
/* Sequence from 11.7.10 */
writel_relaxed(fbi->reg_lccr3, fbi->base + LCCR3);
writel_relaxed(fbi->reg_lccr2, fbi->base + LCCR2);
@@ -825,6 +830,9 @@ static void sa1100fb_disable_controller(struct sa1100fb_info *fbi)
schedule_timeout(20 * HZ / 1000);
remove_wait_queue(&fbi->ctrlr_wait, &wait);
+
+ /* disable LCD controller clock */
+ clk_disable_unprepare(fbi->clk);
}
/*
@@ -1003,7 +1011,6 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
void *data)
{
struct sa1100fb_info *fbi = TO_INF(nb, freq_transition);
- struct cpufreq_freqs *f = data;
u_int pcd;
switch (val) {
@@ -1012,7 +1019,7 @@ sa1100fb_freq_transition(struct notifier_block *nb, unsigned long val,
break;
case CPUFREQ_POSTCHANGE:
- pcd = get_pcd(fbi->fb.var.pixclock, f->new);
+ pcd = get_pcd(fbi, fbi->fb.var.pixclock);
fbi->reg_lccr3 = (fbi->reg_lccr3 & ~0xff) | LCCR3_PixClkDiv(pcd);
set_ctrlr_state(fbi, C_ENABLE_CLKCHANGE);
break;
@@ -1219,6 +1226,13 @@ static int sa1100fb_probe(struct platform_device *pdev)
if (!fbi)
goto failed;
+ fbi->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(fbi->clk)) {
+ ret = PTR_ERR(fbi->clk);
+ fbi->clk = NULL;
+ goto failed;
+ }
+
fbi->base = ioremap(res->start, resource_size(res));
if (!fbi->base)
goto failed;
@@ -1271,6 +1285,8 @@ static int sa1100fb_probe(struct platform_device *pdev)
failed:
if (fbi)
iounmap(fbi->base);
+ if (fbi->clk)
+ clk_put(fbi->clk);
kfree(fbi);
release_mem_region(res->start, resource_size(res));
return ret;
diff --git a/drivers/video/fbdev/sa1100fb.h b/drivers/video/fbdev/sa1100fb.h
index fc5d429..0139d13 100644
--- a/drivers/video/fbdev/sa1100fb.h
+++ b/drivers/video/fbdev/sa1100fb.h
@@ -68,6 +68,7 @@ struct sa1100fb_info {
#endif
const struct sa1100fb_mach_info *inf;
+ struct clk *clk;
};
#define TO_INF(ptr,member) container_of(ptr,struct sa1100fb_info,member)
--
2.1.3
^ permalink raw reply related
* [PATCH V2 4/6] pcmcia: soc-common: enable/disable socket clocks
From: Dmitry Eremin-Solenikov @ 2014-11-24 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416870336-30114-1-git-send-email-dbaryshkov@gmail.com>
Call clk_prepare_enable() during hw_init() and clk_disable_unprepare()
during hw_shutdown() to ensure that the clock rates returned by
clk_get_rate() are correct.
It is safe to call enable/disable functions even on NULL clock, so this
patch will not break cases when the socket clock is not set.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/soc_common.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index a2bc6ee..933f465 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -120,6 +120,8 @@ static void __soc_pcmcia_hw_shutdown(struct soc_pcmcia_socket *skt,
if (skt->ops->hw_shutdown)
skt->ops->hw_shutdown(skt);
+
+ clk_disable_unprepare(skt->clk);
}
static void soc_pcmcia_hw_shutdown(struct soc_pcmcia_socket *skt)
@@ -131,6 +133,8 @@ static int soc_pcmcia_hw_init(struct soc_pcmcia_socket *skt)
{
int ret = 0, i;
+ clk_prepare_enable(skt->clk);
+
if (skt->ops->hw_init) {
ret = skt->ops->hw_init(skt);
if (ret)
--
2.1.3
^ permalink raw reply related
* [PATCH V2 5/6] pcmcia: sa1111: provide device clock
From: Dmitry Eremin-Solenikov @ 2014-11-24 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416870336-30114-1-git-send-email-dbaryshkov@gmail.com>
Both pxa2xx (long ago) and sa1100 (now) make use of clock device to get
the cpu speed. Make sa1111 glue code provide clock to platform layer.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1111_generic.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pcmcia/sa1111_generic.c b/drivers/pcmcia/sa1111_generic.c
index 65b02c3..7bae7e5 100644
--- a/drivers/pcmcia/sa1111_generic.c
+++ b/drivers/pcmcia/sa1111_generic.c
@@ -145,6 +145,12 @@ int sa1111_pcmcia_add(struct sa1111_dev *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
s->soc.nr = ops->first + i;
+ s->soc.clk = clk_get(&dev->dev, NULL);
+ if (IS_ERR(s->soc.clk)) {
+ ret = PTR_ERR(s->soc.clk);
+ kfree(s);
+ return ret;
+ }
soc_pcmcia_init_one(&s->soc, ops, &dev->dev);
s->dev = dev;
if (s->soc.nr) {
@@ -220,6 +226,7 @@ static int pcmcia_remove(struct sa1111_dev *dev)
for (; s; s = next) {
next = s->next;
soc_pcmcia_remove_one(&s->soc);
+ clk_put(s->soc.clk);
kfree(s);
}
--
2.1.3
^ permalink raw reply related
* [PATCH V2 6/6] pcmcia: sa1100: make use of device clock
From: Dmitry Eremin-Solenikov @ 2014-11-24 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416870336-30114-1-git-send-email-dbaryshkov@gmail.com>
Use per-device clock (instead of calling cpufreq_get(0), which can
return 0 if no cpu frequency driver is selected) to program timings.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/sa1100_generic.c | 1 +
drivers/pcmcia/sa11xx_base.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/sa1100_generic.c b/drivers/pcmcia/sa1100_generic.c
index ff8a027..d2ab060 100644
--- a/drivers/pcmcia/sa1100_generic.c
+++ b/drivers/pcmcia/sa1100_generic.c
@@ -93,6 +93,7 @@ static int sa11x0_drv_pcmcia_remove(struct platform_device *dev)
for (i = 0; i < sinfo->nskt; i++)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(sinfo->clk);
kfree(sinfo);
return 0;
}
diff --git a/drivers/pcmcia/sa11xx_base.c b/drivers/pcmcia/sa11xx_base.c
index 54d3089..cf6de2c 100644
--- a/drivers/pcmcia/sa11xx_base.c
+++ b/drivers/pcmcia/sa11xx_base.c
@@ -135,14 +135,16 @@ sa1100_pcmcia_frequency_change(struct soc_pcmcia_socket *skt,
static int
sa1100_pcmcia_set_timing(struct soc_pcmcia_socket *skt)
{
- return sa1100_pcmcia_set_mecr(skt, cpufreq_get(0));
+ unsigned long clk = clk_get_rate(skt->clk);
+
+ return sa1100_pcmcia_set_mecr(skt, clk / 1000);
}
static int
sa1100_pcmcia_show_timing(struct soc_pcmcia_socket *skt, char *buf)
{
struct soc_pcmcia_timing timing;
- unsigned int clock = cpufreq_get(0);
+ unsigned int clock = clk_get_rate(skt->clk);
unsigned long mecr = MECR;
char *p = buf;
@@ -218,6 +220,11 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
struct skt_dev_info *sinfo;
struct soc_pcmcia_socket *skt;
int i, ret = 0;
+ struct clk *clk;
+
+ clk = clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
sa11xx_drv_pcmcia_ops(ops);
@@ -226,12 +233,14 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
return -ENOMEM;
sinfo->nskt = nr;
+ sinfo->clk = clk;
/* Initialize processor specific parameters */
for (i = 0; i < nr; i++) {
skt = &sinfo->skt[i];
skt->nr = first + i;
+ skt->clk = clk;
soc_pcmcia_init_one(skt, ops, dev);
ret = sa11xx_drv_pcmcia_add_one(skt);
@@ -242,6 +251,7 @@ int sa11xx_drv_pcmcia_probe(struct device *dev, struct pcmcia_low_level *ops,
if (ret) {
while (--i >= 0)
soc_pcmcia_remove_one(&sinfo->skt[i]);
+ clk_put(clk);
kfree(sinfo);
} else {
dev_set_drvdata(dev, sinfo);
--
2.1.3
^ permalink raw reply related
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
From: Tomi Valkeinen @ 2014-11-25 9:26 UTC (permalink / raw)
To: Mark Brown
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
In-Reply-To: <20141124173920.GL7712@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]
On 24/11/14 19:39, Mark Brown wrote:
> OK... this is all telling me that I *really* need to scrub this in
> detail. It's all sounding very vague, it's an area which seems to cause
> lots of problems and I don't want to be sitting here next time around
> trying to figure out if another rewrite makes things better or worse or
> if another driver should look similar or different.
I was vague as I don't have the details. I don't know much about the
audio side, except from the users side. Jyri can perhaps fill in the
details.
But a proper review for sound/ side would be appreciated.
For what it's worth, I can say from a user's perspective that with this
series the OMAP HDMI audio finally seems to work so that I'm satisfied
with it. While there's still things to improve, it works and I can keep
it enabled in the kernel while developing the video side and it doesn't
get on my way.
>> The whole series is about HDMI audio, not video.
>
> You know exactly what I mean - the early patches are in drivers/video,
> don't touch anything outside of that and have no obvious dependencies.
My point was, there's no particular reason to apply those patches
individually. It's an independent series, about HDMI audio, and applying
only some of the earlier patches does not improve the kernel in visible
manner.
>> And in any case, I don't like applying individual patches from a series.
>> Usually that just complicates things. If I would apply some of the early
>> patches to fbdev, then this series would no longer work on plain
>> mainline kernel, and would instead depend on fbdev tree. The situation
>
> But I thought everyone was saying this hardware doesn't work anyway and
> that you want to apply all these changes to fbdev?
I don't particularly _want_ to apply these via fbdev, but I think it's
the easiest way. Most of the files touched are in drivers/video/, so
hopefully merging via fbdev reduces the chances of conflicts.
And this needs your ack before it can be merged via fbdev tree. Until
you've said that you're fine getting this via fbdev, we don't know how
this will be merged, and I can't create dependencies to fbdev.
> This means we're all then stuck reading reposts of the same enormous
> series over and over again - as a reviewer a really big series that
> appears from the subject lines to be mostly about another system is
> really offputting. If you're going to do something like this please at
Well, yes, I see your point. And I agree that patches that the rest of
the series does not depend on should normally be applied individually if
the series starts getting multiple revisions (although even those
patches could cause conflicts if the rest of the patches touch code nearby).
But that's not the case here, as all the patches are needed to get a
working HDMI audio.
> least reply to the messages, that way it's clearer that there's not
> going to be a dependency problem getting the patches applied (which is
> part of what makes things offputting).
Yes, lack of communication was my mistake.
In any case, how do you want to proceed? As I said, I very much would
like to get this into the next merge window and from my point of view
the current versions looks good. If you find something to be fixed in
the sound/ side, and you're fine with merging this via fbdev, I can
start merging the earlier patches in the series so that the next
revision is easier to review.
But the merge window is getting close. If you find something very wrong
with the series, we can skip this merge window. But if there are only
issues that can be easily fixed with follow-up patches, I'd rather merge
this revision than do more full review rounds.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] video: fbdev-MMP: Fix typos for the word "destroy"
From: Tomi Valkeinen @ 2014-11-25 10:55 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, kernel-janitors,
trivial, LKML
In-Reply-To: <547368BB.2050401@users.sourceforge.net>
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
On 24/11/14 19:19, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 24 Nov 2014 15:50:15 +0100
>
> Two mistyped words were corrected in the description for
> the mmp_unregister_path() function.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/video/fbdev/mmp/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/mmp/core.c b/drivers/video/fbdev/mmp/core.c
> index b563b92..43ed576 100644
> --- a/drivers/video/fbdev/mmp/core.c
> +++ b/drivers/video/fbdev/mmp/core.c
> @@ -223,10 +223,10 @@ struct mmp_path *mmp_register_path(struct mmp_path_info *info)
> EXPORT_SYMBOL_GPL(mmp_register_path);
>
> /*
> - * mmp_unregister_path - unregister and destory path
> + * mmp_unregister_path - unregister and destroy path
> * @p: path to be destoried.
> *
> - * this function registers path and destorys it.
> + * this function registers path and destroys it.
> */
> void mmp_unregister_path(struct mmp_path *path)
> {
>
Thanks, applied this and the patch 5/6 to fbdev tree.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Tomi Valkeinen @ 2014-11-25 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416309051-26784-3-git-send-email-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On 18/11/14 13:10, Hans de Goede wrote:
> If pre-filled framebuffer nodes are used, the firmware may need extra
> properties to find the right node. This documents the properties to use
> for this on sunxi platforms.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> new file mode 100644
> index 0000000..c46ba64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
> @@ -0,0 +1,33 @@
> +Sunxi specific Simple Framebuffer bindings
> +
> +This binding documents sunxi specific extensions to the simple-framebuffer
> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
> +pre-populated simplefb nodes.
> +
> +These extensions are intended so that u-boot can select the right node based
> +on which pipeline is being used. As such they are solely intended for
> +firmware / bootloader use, and the OS should ignore them.
> +
> +Required properties:
> +- compatible: "allwinner,simple-framebuffer"
> +- allwinner,pipeline, one of:
Sorry my ignorance, but what's sunxi and what's allwinner? Both names
are mixed here.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/2] dt-bindings: simplefb: Drop the advice about using a specific path for nodes
From: Tomi Valkeinen @ 2014-11-25 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1416309051-26784-1-git-send-email-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Hi,
On 18/11/14 13:10, Hans de Goede wrote:
> Hi Tomi,
>
> So it turns out we needed a v3, as I mistakenly went with "sunxi," as vendor
> prefix for the allwinner specific properties, but the registered vendor prefix
> for allwinner is "allwinnner,", this version fixes this.
>
> Changes in v3: Use proper "allwinnner," for the compatible string and vendor
> specific properties.
>
> Changes in v2: Changed the simplefb-sunxi bindings to use a single
> sunxi,pipeline string property instead of a sunxi,pipeline int and a
> sunxi,output string property.
>
> This patch set is all acked up, and a fix to the binding changes you've
> already queued for 3.19, so please queue these 2 patches for 3.19.
The discussions about this have continued in the earlier version of this
series. Is this series still ok for everyone?
The series looks fine to me, and has Grant's acks, so I'll merge it
tomorrow to fbdev tree if no one objects (and my comment for the patch 2
about sunxi/allwinner was just my ignorance).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-25 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <547476DA.2030004@ti.com>
Hi,
On 11/25/2014 01:32 PM, Tomi Valkeinen wrote:
> On 18/11/14 13:10, Hans de Goede wrote:
>> If pre-filled framebuffer nodes are used, the firmware may need extra
>> properties to find the right node. This documents the properties to use
>> for this on sunxi platforms.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> Acked-by: Grant Likely <grant.likely@linaro.org>
>> ---
>> .../bindings/video/simple-framebuffer-sunxi.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> new file mode 100644
>> index 0000000..c46ba64
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt
>> @@ -0,0 +1,33 @@
>> +Sunxi specific Simple Framebuffer bindings
>> +
>> +This binding documents sunxi specific extensions to the simple-framebuffer
>> +bindings. The sunxi simplefb u-boot code relies on the devicetree containing
>> +pre-populated simplefb nodes.
>> +
>> +These extensions are intended so that u-boot can select the right node based
>> +on which pipeline is being used. As such they are solely intended for
>> +firmware / bootloader use, and the OS should ignore them.
>> +
>> +Required properties:
>> +- compatible: "allwinner,simple-framebuffer"
>> +- allwinner,pipeline, one of:
>
> Sorry my ignorance, but what's sunxi and what's allwinner? Both names
> are mixed here.
sunxi is the sun#i SoCs from Allwinner, Allwinner is the manufacturer and the
SoC "code" names used everywhere in the kernel for their SoCs are sun4i, sun5i,
sun6i, etc. Most people refer to these SoCs as sunxi. This is also what the
linux-sunxi mailinglist in the Cc is about.
The official devicetree vendor prefix for Allwinner is allwinner, hence the
allwinner in the compatible name, see e.g. also
Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
Which also uses sunxi / sun4i everywhere except in the compatible vendor prefix.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Tomi Valkeinen @ 2014-11-25 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54747B72.1050406@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On 25/11/14 14:52, Hans de Goede wrote:
>>> +Required properties:
>>> +- compatible: "allwinner,simple-framebuffer"
>>> +- allwinner,pipeline, one of:
>>
>> Sorry my ignorance, but what's sunxi and what's allwinner? Both names
>> are mixed here.
>
> sunxi is the sun#i SoCs from Allwinner, Allwinner is the manufacturer
> and the
> SoC "code" names used everywhere in the kernel for their SoCs are sun4i,
> sun5i,
> sun6i, etc. Most people refer to these SoCs as sunxi. This is also what the
> linux-sunxi mailinglist in the Cc is about.
>
> The official devicetree vendor prefix for Allwinner is allwinner, hence the
> allwinner in the compatible name, see e.g. also
>
> Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
>
> Which also uses sunxi / sun4i everywhere except in the compatible vendor
> prefix.
Alright, thanks for explanation.
Shouldn't the compatible then be "allwinner,sunxi-simple-framebuffer",
to differentiate from some other SoC Allwinner has or might create in
the future? That is, presuming you're confident enough that a single
compatible string covers all the current and forthcoming sunxi SoCs.
Perhaps simplefb is a bit special case, but I usually feel better if the
compatible string is defined in a more specific manner. In this case I'd
have:
allwinner,sun4i-simple-framebuffer
allwinner,sun5i-simple-framebuffer
allwinner,sun6i-simple-framebuffer
so that if sun7i has totally different display controller, there would
be no conflict.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-25 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54747DCF.9010502@ti.com>
Hi,
On 11/25/2014 02:02 PM, Tomi Valkeinen wrote:
> On 25/11/14 14:52, Hans de Goede wrote:
>
>>>> +Required properties:
>>>> +- compatible: "allwinner,simple-framebuffer"
>>>> +- allwinner,pipeline, one of:
>>>
>>> Sorry my ignorance, but what's sunxi and what's allwinner? Both names
>>> are mixed here.
>>
>> sunxi is the sun#i SoCs from Allwinner, Allwinner is the manufacturer
>> and the
>> SoC "code" names used everywhere in the kernel for their SoCs are sun4i,
>> sun5i,
>> sun6i, etc. Most people refer to these SoCs as sunxi. This is also what the
>> linux-sunxi mailinglist in the Cc is about.
>>
>> The official devicetree vendor prefix for Allwinner is allwinner, hence the
>> allwinner in the compatible name, see e.g. also
>>
>> Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
>>
>> Which also uses sunxi / sun4i everywhere except in the compatible vendor
>> prefix.
>
> Alright, thanks for explanation.
>
> Shouldn't the compatible then be "allwinner,sunxi-simple-framebuffer",
> to differentiate from some other SoC Allwinner has or might create in
> the future? That is, presuming you're confident enough that a single
> compatible string covers all the current and forthcoming sunxi SoCs.
This was discussed in an earlier thread, we (Ian Campbell, Grant and me)
decided to settle on allwinner,simple-framebuffer to make it clear that
these are allwinner extensions to the standard simple-framebuffer bindings,
and that the node otherwise is simple-framebuffer compatible.
We were afraid that e.g. sun4i-simple-framebuffer would signal that it
is not a normal simple-framebuffer node, so we decided to go with just
the allwinner, prefix to indicate that it uses allwinner specific
extensions.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Tomi Valkeinen @ 2014-11-25 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5474824F.8080000@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]
On 25/11/14 15:21, Hans de Goede wrote:
>> Shouldn't the compatible then be "allwinner,sunxi-simple-framebuffer",
>> to differentiate from some other SoC Allwinner has or might create in
>> the future? That is, presuming you're confident enough that a single
>> compatible string covers all the current and forthcoming sunxi SoCs.
>
> This was discussed in an earlier thread, we (Ian Campbell, Grant and me)
Okay. Sorry for not having time at the moment to follow the discussions
properly. =)
> decided to settle on allwinner,simple-framebuffer to make it clear that
> these are allwinner extensions to the standard simple-framebuffer bindings,
> and that the node otherwise is simple-framebuffer compatible.
>
> We were afraid that e.g. sun4i-simple-framebuffer would signal that it
> is not a normal simple-framebuffer node, so we decided to go with just
> the allwinner, prefix to indicate that it uses allwinner specific
> extensions.
Wouldn't
compatible = "allwinner,sun4i-simple-framebuffer", "simple-framebuffer";
tell that it's a simple-framebuffer, with allwinner's sun4i extensions?
I guess you can have just "allwinner,simple-framebuffer", and then if a
new Allwinner SoC has a totally different display controller, the
documentation would specify that this property is for that SoC, and this
another property is for that another SoC. But isn't the compatible
string what's supposed to use in cases like this?
And if the new SoC is not sunxi, but some totally other family, there's
need for a new compatible string anyway, as
"simple-framebuffer-sunxi.txt" is for sunxi only.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Hans de Goede @ 2014-11-25 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5474863A.5040801@ti.com>
Hi,
On 11/25/2014 02:38 PM, Tomi Valkeinen wrote:
> On 25/11/14 15:21, Hans de Goede wrote:
>
>>> Shouldn't the compatible then be "allwinner,sunxi-simple-framebuffer",
>>> to differentiate from some other SoC Allwinner has or might create in
>>> the future? That is, presuming you're confident enough that a single
>>> compatible string covers all the current and forthcoming sunxi SoCs.
>>
>> This was discussed in an earlier thread, we (Ian Campbell, Grant and me)
>
> Okay. Sorry for not having time at the moment to follow the discussions
> properly. =)
>
>> decided to settle on allwinner,simple-framebuffer to make it clear that
>> these are allwinner extensions to the standard simple-framebuffer bindings,
>> and that the node otherwise is simple-framebuffer compatible.
>>
>> We were afraid that e.g. sun4i-simple-framebuffer would signal that it
>> is not a normal simple-framebuffer node, so we decided to go with just
>> the allwinner, prefix to indicate that it uses allwinner specific
>> extensions.
>
> Wouldn't
>
> compatible = "allwinner,sun4i-simple-framebuffer", "simple-framebuffer";
>
> tell that it's a simple-framebuffer, with allwinner's sun4i extensions?
>
> I guess you can have just "allwinner,simple-framebuffer", and then if a
> new Allwinner SoC has a totally different display controller, the
> documentation would specify that this property is for that SoC, and this
> another property is for that another SoC. But isn't the compatible
> string what's supposed to use in cases like this?
The only soc specific thing in the binding is the pipeline property string
values, and we can always add new values to that, the rest is all generic,
as simplefb is generic.
As said Ian Campbell, Grant and me have decided on using this, and currently
patches are already queued up for both the dts files and u-boot to use this,
so unless there are really strong reasons to change it at this point I would
prefer to keep this as is.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
From: Mark Brown @ 2014-11-25 18:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
In-Reply-To: <54744B4C.2030105@ti.com>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote:
> On 24/11/14 19:39, Mark Brown wrote:
> >> The whole series is about HDMI audio, not video.
> > You know exactly what I mean - the early patches are in drivers/video,
> > don't touch anything outside of that and have no obvious dependencies.
> My point was, there's no particular reason to apply those patches
> individually. It's an independent series, about HDMI audio, and applying
> only some of the earlier patches does not improve the kernel in visible
> manner.
Can you please apply them, I'll try to get round to reviewing the audio
bits soon but either these will need applying if the rest of it's OK or
if there does turn out to be a problem they cut down on the size of the
series. I really do want to read it closely, but hopefully by the
weekend.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: simplefb-sunxi: Add sunxi simplefb extensions
From: Tomi Valkeinen @ 2014-11-26 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5474880F.8040908@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On 25/11/14 15:45, Hans de Goede wrote:
>> Wouldn't
>>
>> compatible = "allwinner,sun4i-simple-framebuffer", "simple-framebuffer";
>>
>> tell that it's a simple-framebuffer, with allwinner's sun4i extensions?
>>
>> I guess you can have just "allwinner,simple-framebuffer", and then if a
>> new Allwinner SoC has a totally different display controller, the
>> documentation would specify that this property is for that SoC, and this
>> another property is for that another SoC. But isn't the compatible
>> string what's supposed to use in cases like this?
>
> The only soc specific thing in the binding is the pipeline property string
> values, and we can always add new values to that, the rest is all generic,
> as simplefb is generic.
The thing I don't understand is that the compatible string states that
"this covers all Allwinner SoCs", even if we have no idea what kind of
SoCs those may be. And if it covers all kinds of SoCs, then it might as
well be fully generic, not Allwinner specific.
And if it's not fully generic, then having it cover all possible
Allwinner SoCs doesn't make sense either.
> As said Ian Campbell, Grant and me have decided on using this, and
> currently
> patches are already queued up for both the dts files and u-boot to use
> this,
> so unless there are really strong reasons to change it at this point I
> would
> prefer to keep this as is.
Ok. Well, as I said, it does not look correct to me, but if everybody
else agrees on it (and I see I didn't get any replies during the night),
I'll be applying this today.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
From: Tomi Valkeinen @ 2014-11-26 11:02 UTC (permalink / raw)
To: Mark Brown
Cc: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap, peter.ujfalusi,
liam.r.girdwood
In-Reply-To: <20141125181020.GJ7712@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
On 25/11/14 20:10, Mark Brown wrote:
> On Tue, Nov 25, 2014 at 11:26:36AM +0200, Tomi Valkeinen wrote:
>> On 24/11/14 19:39, Mark Brown wrote:
>
>>>> The whole series is about HDMI audio, not video.
>
>>> You know exactly what I mean - the early patches are in drivers/video,
>>> don't touch anything outside of that and have no obvious dependencies.
>
>> My point was, there's no particular reason to apply those patches
>> individually. It's an independent series, about HDMI audio, and applying
>> only some of the earlier patches does not improve the kernel in visible
>> manner.
>
> Can you please apply them, I'll try to get round to reviewing the audio
> bits soon but either these will need applying if the rest of it's OK or
> if there does turn out to be a problem they cut down on the size of the
> series. I really do want to read it closely, but hopefully by the
> weekend.
Ok, I've picked the following patches:
OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementation
OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
OMAPDSS: hdmi: Make hdmi structure public
OMAPDSS: hdmi_wp: Add function for getting audio dma address
OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameter
OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 1/2] backlight/lp855x: Refactor dt parsing code
From: Sean Paul @ 2014-11-26 19:11 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, milo.kim-l0cyMroinI0
Cc: seanpaul-F7+t8E8rja9g9hUCZPvPmw, Stéphane Marchesin
This patch refactors the dt parsing code to avoid setting platform_data,
instead just setting lp->pdata directly. This facilitates easier
probe deferral since the current scheme would require us to clear out
dev->platform_data before deferring.
Cc: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
drivers/video/backlight/lp855x_bl.c | 37 ++++++++++++++++++-------------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index 25fb8e3..257b3ba 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -341,8 +341,10 @@ static const struct attribute_group lp855x_attr_group = {
};
#ifdef CONFIG_OF
-static int lp855x_parse_dt(struct device *dev, struct device_node *node)
+static int lp855x_parse_dt(struct lp855x *lp)
{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
struct lp855x_platform_data *pdata;
int rom_length;
@@ -381,12 +383,12 @@ static int lp855x_parse_dt(struct device *dev, struct device_node *node)
pdata->rom_data = &rom[0];
}
- dev->platform_data = pdata;
+ lp->pdata = pdata;
return 0;
}
#else
-static int lp855x_parse_dt(struct device *dev, struct device_node *node)
+static int lp855x_parse_dt(struct lp855x *lp)
{
return -EINVAL;
}
@@ -395,18 +397,8 @@ static int lp855x_parse_dt(struct device *dev, struct device_node *node)
static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
struct lp855x *lp;
- struct lp855x_platform_data *pdata = dev_get_platdata(&cl->dev);
- struct device_node *node = cl->dev.of_node;
int ret;
- if (!pdata) {
- ret = lp855x_parse_dt(&cl->dev, node);
- if (ret < 0)
- return ret;
-
- pdata = dev_get_platdata(&cl->dev);
- }
-
if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
return -EIO;
@@ -414,16 +406,23 @@ static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
if (!lp)
return -ENOMEM;
- if (pdata->period_ns > 0)
- lp->mode = PWM_BASED;
- else
- lp->mode = REGISTER_BASED;
-
lp->client = cl;
lp->dev = &cl->dev;
- lp->pdata = pdata;
lp->chipname = id->name;
lp->chip_id = id->driver_data;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ if (!lp->pdata) {
+ ret = lp855x_parse_dt(lp);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (lp->pdata->period_ns > 0)
+ lp->mode = PWM_BASED;
+ else
+ lp->mode = REGISTER_BASED;
+
i2c_set_clientdata(cl, lp);
ret = lp855x_configure(lp);
--
2.1.1
^ permalink raw reply related
* [PATCH 2/2] backlight/lp855x: Add supply regulator to lp855x
From: Sean Paul @ 2014-11-26 19:11 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, milo.kim-l0cyMroinI0
Cc: seanpaul-F7+t8E8rja9g9hUCZPvPmw, Stéphane Marchesin,
Aaron Durbin
In-Reply-To: <1417029064-12460-1-git-send-email-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
This patch adds a supply regulator to the lp855x platform data to facilitate
powering on/off the 3V rail attached to the controller.
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
---
.../devicetree/bindings/video/backlight/lp855x.txt | 2 ++
drivers/video/backlight/lp855x_bl.c | 17 +++++++++++++++++
include/linux/platform_data/lp855x.h | 2 ++
3 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
index 96e83a5..0a3ecbc 100644
--- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
+++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
@@ -12,6 +12,7 @@ Optional properties:
- pwm-period: PWM period value. Set only PWM input mode used (u32)
- rom-addr: Register address of ROM area to be updated (u8)
- rom-val: Register value to be updated (u8)
+ - power-supply: Regulator which controls the 3V rail
Example:
@@ -56,6 +57,7 @@ Example:
backlight@2c {
compatible = "ti,lp8557";
reg = <0x2c>;
+ power-supply = <&backlight_vdd>;
dev-ctrl = /bits/ 8 <0x41>;
init-brt = /bits/ 8 <0x0a>;
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
index 257b3ba..8021009 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -17,6 +17,7 @@
#include <linux/of.h>
#include <linux/platform_data/lp855x.h>
#include <linux/pwm.h>
+#include <linux/regulator/consumer.h>
/* LP8550/1/2/3/6 Registers */
#define LP855X_BRIGHTNESS_CTRL 0x00
@@ -383,6 +384,13 @@ static int lp855x_parse_dt(struct lp855x *lp)
pdata->rom_data = &rom[0];
}
+ pdata->supply = devm_regulator_get(dev, "power");
+ if (IS_ERR(pdata->supply)) {
+ if (PTR_ERR(pdata->supply) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ pdata->supply = NULL;
+ }
+
lp->pdata = pdata;
return 0;
@@ -423,6 +431,14 @@ static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
else
lp->mode = REGISTER_BASED;
+ if (lp->pdata->supply) {
+ ret = regulator_enable(lp->pdata->supply);
+ if (ret < 0) {
+ dev_err(&cl->dev, "failed to enable supply: %d\n", ret);
+ return ret;
+ }
+ }
+
i2c_set_clientdata(cl, lp);
ret = lp855x_configure(lp);
@@ -454,6 +470,7 @@ static int lp855x_remove(struct i2c_client *cl)
lp->bl->props.brightness = 0;
backlight_update_status(lp->bl);
+ regulator_disable(lp->pdata->supply);
sysfs_remove_group(&lp->dev->kobj, &lp855x_attr_group);
return 0;
diff --git a/include/linux/platform_data/lp855x.h b/include/linux/platform_data/lp855x.h
index 1b2ba24..9c7fd1e 100644
--- a/include/linux/platform_data/lp855x.h
+++ b/include/linux/platform_data/lp855x.h
@@ -136,6 +136,7 @@ struct lp855x_rom_data {
Only valid when mode is PWM_BASED.
* @size_program : total size of lp855x_rom_data
* @rom_data : list of new eeprom/eprom registers
+ * @supply : regulator that supplies 3V input
*/
struct lp855x_platform_data {
const char *name;
@@ -144,6 +145,7 @@ struct lp855x_platform_data {
unsigned int period_ns;
int size_program;
struct lp855x_rom_data *rom_data;
+ struct regulator *supply;
};
#endif
--
2.1.1
^ permalink raw reply related
* [PATCH 1/3] video: fbdev: vt8623fb: suppress build warning
From: Lad, Prabhakar @ 2014-11-26 22:07 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel, Lad, Prabhakar
this patch fixes following build warning:
drivers/video/fbdev/vt8623fb.c: In function ‘vt8623_pci_probe’:
drivers/video/fbdev/vt8623fb.c:734:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
par->state.vgabase = (void __iomem *) vga_res.start;
^
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/vt8623fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index 5c7cbc6..ea7f056 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -731,7 +731,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *) (unsigned long) vga_res.start;
/* Find how many physical memory there is on card */
memsize1 = (vga_rseq(par->state.vgabase, 0x34) + 1) >> 1;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] video: fbdev: s3fb: suppress build warning
From: Lad, Prabhakar @ 2014-11-26 22:07 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel, Lad, Prabhakar
In-Reply-To: <1417039645-5313-1-git-send-email-prabhakar.csengg@gmail.com>
this patch fixes following build warning:
drivers/video/fbdev/s3fb.c: In function ‘s3_pci_probe’:
drivers/video/fbdev/s3fb.c:1185:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
par->state.vgabase = (void __iomem *) vga_res.start;
^
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/s3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index c43b969..f0ae61a 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -1182,7 +1182,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *) (unsigned long) vga_res.start;
/* Unlock regs */
cr38 = vga_rcrt(par->state.vgabase, 0x38);
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] video: fbdev: arkfb: suppress build warning
From: Lad, Prabhakar @ 2014-11-26 22:07 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel, Lad, Prabhakar
In-Reply-To: <1417039645-5313-1-git-send-email-prabhakar.csengg@gmail.com>
this patch fixes following build warning:
drivers/video/fbdev/arkfb.c: In function ‘ark_pci_probe’:
drivers/video/fbdev/arkfb.c:1019:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
par->state.vgabase = (void __iomem *) vga_res.start;
^
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/arkfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index adc4ea2..b305a1e 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -1016,7 +1016,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
pcibios_bus_to_resource(dev->bus, &vga_res, &bus_reg);
- par->state.vgabase = (void __iomem *) vga_res.start;
+ par->state.vgabase = (void __iomem *) (unsigned long) vga_res.start;
/* FIXME get memsize */
regval = vga_rseq(par->state.vgabase, 0x10);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] backlight/lp855x: Refactor dt parsing code
From: Kim, Milo @ 2014-11-27 1:32 UTC (permalink / raw)
To: Sean Paul, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Stéphane Marchesin, jg1.han-Sze3O3UU22JBDgjK7y7TUQ,
cooloney-Re5JQEeQqe8AvxtiuMwx3w, lee.jones-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417029064-12460-1-git-send-email-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
(Looping backlight class subsystem maintainers)
Hi Sean,
Thanks for checking this. I'd like to describe why the original code is
preferred.
The original code is copying the values of the lp855x platform data from
the DT in advance of allocating lp855x data.
It guarantees returning quickly in case of invalid platform data.
In other words, no memory allocation of lp855x proceeds if parsing the
DT gets failed.
However, this patch allocates the lp855x first and checking the DT.
Of course, devm_kzalloc() will free allocated memory later but original
code does NOT try to allocate it.
So I'd prefer to keep this way.
Best regards,
Milo
On 11/27/2014 4:11 AM, Sean Paul wrote:
> This patch refactors the dt parsing code to avoid setting platform_data,
> instead just setting lp->pdata directly. This facilitates easier
> probe deferral since the current scheme would require us to clear out
> dev->platform_data before deferring.
>
> Cc: Stéphane Marchesin <marcheu@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> ---
> drivers/video/backlight/lp855x_bl.c | 37 ++++++++++++++++++-------------------
> 1 file changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
> index 25fb8e3..257b3ba 100644
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/backlight/lp855x_bl.c
> @@ -341,8 +341,10 @@ static const struct attribute_group lp855x_attr_group = {
> };
>
> #ifdef CONFIG_OF
> -static int lp855x_parse_dt(struct device *dev, struct device_node *node)
> +static int lp855x_parse_dt(struct lp855x *lp)
> {
> + struct device *dev = lp->dev;
> + struct device_node *node = dev->of_node;
> struct lp855x_platform_data *pdata;
> int rom_length;
>
> @@ -381,12 +383,12 @@ static int lp855x_parse_dt(struct device *dev, struct device_node *node)
> pdata->rom_data = &rom[0];
> }
>
> - dev->platform_data = pdata;
> + lp->pdata = pdata;
>
> return 0;
> }
> #else
> -static int lp855x_parse_dt(struct device *dev, struct device_node *node)
> +static int lp855x_parse_dt(struct lp855x *lp)
> {
> return -EINVAL;
> }
> @@ -395,18 +397,8 @@ static int lp855x_parse_dt(struct device *dev, struct device_node *node)
> static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
> {
> struct lp855x *lp;
> - struct lp855x_platform_data *pdata = dev_get_platdata(&cl->dev);
> - struct device_node *node = cl->dev.of_node;
> int ret;
>
> - if (!pdata) {
> - ret = lp855x_parse_dt(&cl->dev, node);
> - if (ret < 0)
> - return ret;
> -
> - pdata = dev_get_platdata(&cl->dev);
> - }
> -
> if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
> return -EIO;
>
> @@ -414,16 +406,23 @@ static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
> if (!lp)
> return -ENOMEM;
>
> - if (pdata->period_ns > 0)
> - lp->mode = PWM_BASED;
> - else
> - lp->mode = REGISTER_BASED;
> -
> lp->client = cl;
> lp->dev = &cl->dev;
> - lp->pdata = pdata;
> lp->chipname = id->name;
> lp->chip_id = id->driver_data;
> + lp->pdata = dev_get_platdata(&cl->dev);
> +
> + if (!lp->pdata) {
> + ret = lp855x_parse_dt(lp);
> + if (ret < 0)
> + return ret;
> + }
> +
> + if (lp->pdata->period_ns > 0)
> + lp->mode = PWM_BASED;
> + else
> + lp->mode = REGISTER_BASED;
> +
> i2c_set_clientdata(cl, lp);
>
> ret = lp855x_configure(lp);
>
^ permalink raw reply
* Re: [PATCH 2/2] backlight/lp855x: Add supply regulator to lp855x
From: Kim, Milo @ 2014-11-27 1:32 UTC (permalink / raw)
To: Sean Paul, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Stéphane Marchesin, Aaron Durbin,
jg1.han-Sze3O3UU22JBDgjK7y7TUQ, cooloney-Re5JQEeQqe8AvxtiuMwx3w,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1417029064-12460-2-git-send-email-seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
(Looping backlight class subsystem maintainers)
Hi Sean,
Please see my comments below. Thanks!
On 11/27/2014 4:11 AM, Sean Paul wrote:
> This patch adds a supply regulator to the lp855x platform data to facilitate
> powering on/off the 3V rail attached to the controller.
>
> Cc: Stéphane Marchesin <marcheu@chromium.org>
> Cc: Aaron Durbin <adurbin@chromium.org>
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> ---
> .../devicetree/bindings/video/backlight/lp855x.txt | 2 ++
> drivers/video/backlight/lp855x_bl.c | 17 +++++++++++++++++
> include/linux/platform_data/lp855x.h | 2 ++
> 3 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
> index 96e83a5..0a3ecbc 100644
> --- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
> @@ -12,6 +12,7 @@ Optional properties:
> - pwm-period: PWM period value. Set only PWM input mode used (u32)
> - rom-addr: Register address of ROM area to be updated (u8)
> - rom-val: Register value to be updated (u8)
> + - power-supply: Regulator which controls the 3V rail
>
> Example:
>
> @@ -56,6 +57,7 @@ Example:
> backlight@2c {
> compatible = "ti,lp8557";
> reg = <0x2c>;
> + power-supply = <&backlight_vdd>;
>
> dev-ctrl = /bits/ 8 <0x41>;
> init-brt = /bits/ 8 <0x0a>;
> diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
> index 257b3ba..8021009 100644
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/backlight/lp855x_bl.c
> @@ -17,6 +17,7 @@
> #include <linux/of.h>
> #include <linux/platform_data/lp855x.h>
> #include <linux/pwm.h>
> +#include <linux/regulator/consumer.h>
>
> /* LP8550/1/2/3/6 Registers */
> #define LP855X_BRIGHTNESS_CTRL 0x00
> @@ -383,6 +384,13 @@ static int lp855x_parse_dt(struct lp855x *lp)
> pdata->rom_data = &rom[0];
> }
>
> + pdata->supply = devm_regulator_get(dev, "power");
> + if (IS_ERR(pdata->supply)) {
> + if (PTR_ERR(pdata->supply) = -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + pdata->supply = NULL;
This optional data, 'supply' is set to NULL.
Please refer to my comments below.
> + }
> +
> lp->pdata = pdata;
>
> return 0;
> @@ -423,6 +431,14 @@ static int lp855x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
> else
> lp->mode = REGISTER_BASED;
>
> + if (lp->pdata->supply) {
> + ret = regulator_enable(lp->pdata->supply);
> + if (ret < 0) {
> + dev_err(&cl->dev, "failed to enable supply: %d\n", ret);
> + return ret;
> + }
> + }
> +
> i2c_set_clientdata(cl, lp);
>
> ret = lp855x_configure(lp);
> @@ -454,6 +470,7 @@ static int lp855x_remove(struct i2c_client *cl)
>
> lp->bl->props.brightness = 0;
> backlight_update_status(lp->bl);
> + regulator_disable(lp->pdata->supply);
The 'lp->pdata->supply' is optional, what happens if it is NULL?
This will cause the kernel OOPS inside regulator_disable() API.
int regulator_disable(struct regulator *regulator)
{
struct regulator_dev *rdev = regulator->rdev;
...
}
> sysfs_remove_group(&lp->dev->kobj, &lp855x_attr_group);
>
> return 0;
> diff --git a/include/linux/platform_data/lp855x.h b/include/linux/platform_data/lp855x.h
> index 1b2ba24..9c7fd1e 100644
> --- a/include/linux/platform_data/lp855x.h
> +++ b/include/linux/platform_data/lp855x.h
> @@ -136,6 +136,7 @@ struct lp855x_rom_data {
> Only valid when mode is PWM_BASED.
> * @size_program : total size of lp855x_rom_data
> * @rom_data : list of new eeprom/eprom registers
> + * @supply : regulator that supplies 3V input
> */
> struct lp855x_platform_data {
> const char *name;
> @@ -144,6 +145,7 @@ struct lp855x_platform_data {
> unsigned int period_ns;
> int size_program;
> struct lp855x_rom_data *rom_data;
> + struct regulator *supply;
> };
>
> #endif
>
Best regards,
Milo
^ permalink raw reply
* [PATCH] Converting int usage to bool
From: Quentin Lambert @ 2014-11-27 10:41 UTC (permalink / raw)
To: Thomas Winischhofer
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
The following semantic patch was used to find
functions and variables declared as int but
used as boolean. The patch resulted in a
significant number of false positive that I
have ignored.
I am not hyper confident about the modification
I made to the functions. Some of them seem to
have quite significant side effects, which is not
necesserarily intended from a boolean function.
In particular both *_rwtest functions write data.
Moreover sisfb_find_host_bridge name may suggest
more than a boolean return.
/* match all explicit boolean functions */
@boolean_function@
identifier fbool;
typedef bool;
@@
bool fbool(...) {
...
}
/* match variables eligible for boolean conversion */
@eligible_var exists@
identifier f, boolean_function.fbool;
local idexpression int x;
identifier xname;
expression e;
position p;
@@
f@p(...) {
...when any
(
x@xname = 1;
|
x@xname = 0;
|
x@xname = (e) ? 0 : 1;
|
x@xname = (e) ? 1 : 0;
|
x@xname = fbool(...);
)
...when any
}
/* match all acceptable complex assignement */
@valid_assign exists@
identifier eligible_var.f, boolean_function.fbool;
local idexpression int eligible_var.x;
expression e;
position p;
@@
f(...) {
...when any
(
x@p = (e) ? 0 : 1;
|
x@p = (e) ? 1 : 0;
|
x@p = fbool(...);
)
...when any
}
/* match any expression where x is used as an int */
@badvar1 exists@
identifier eligible_var.f;
local idexpression int eligible_var.x;
expression e1 != {0, 1}, e2;
position p != {valid_assign.p};
@@
f(...) {
...when any
(
x@p = e1;
|
x++
|
++x
|
x--
|
--x
|
x + e2
|
x - e2
|
e2 - x
|
x & e2
|
x * e2
|
x / e2
|
e2 / x
)
...when any
}
/* match all return statement involving an eligible variable */
@valid_var_return depends on !badvar1 exists@
identifier eligible_var.f;
local idexpression int eligible_var.x;
position p;
@@
f(...) {
...when any
return x@p;
}
/* match all function eligible for boolean conversion */
/* do not match function returning only boolean variable different from the one considered */
@eligible_func exists@
identifier f;
local idexpression int x;
position valid_var_return.p;
@@
int f(...) {
...when any
(
return 1;
|
return 0;
|
return x@p;
)
}
/* match functions returning something else than a bool */
@badfunc1 exists@
identifier eligible_func.f;
expression e != {0, 1};
position p != valid_var_return.p;
@@
int
f(...) {
...when any
return e@p;
}
/* satisfied when eligible_var is variable of eligible_func */
@same_function depends on eligible_var exists@
identifier eligible_func.f;
position eligible_var.p;
@@
int
f@p(...) {
...
}
/* match variable being returned as well as other non boolean variable */
@badvar2 depends on badfunc1 && same_function exists@
local idexpression int eligible_var.x;
identifier eligible_func.f;
@@
int
f(...) {
...when any
return x;
}
@depends on (!eligible_func || eligible_func && !same_function) && !badvar1@
identifier eligible_var.f;
local idexpression int eligible_var.x;
identifier eligible_var.xname;
expression e;
@@
f(...) {
...
(
++ bool xname;
- int xname;
|
++ bool xname = false;
- int xname = 0;
|
++ bool xname = true;
- int xname = 1;
)
<...
(
x - 1;
+ true;
|
x - 0;
+ false;
|
- x = (e) ? 1 : 0;
+ x = (e) ? true : false;
|
- x = (e) ? 0 : 1;
+ x = (e) ? false : true;
)
...>
}
@depends on eligible_func && same_function && !badvar1 && !badvar2@
identifier eligible_func.f;
local idexpression int eligible_var.x;
identifier eligible_var.xname;
expression e;
@@
f(...) {
...
(
++ bool xname;
- int xname;
|
++ bool xname = false;
- int xname = 0;
|
++ bool xname = true;
- int xname = 1;
)
<...
(
x - 1;
+ true;
|
x - 0;
+ false;
|
- x = (e) ? 1 : 0;
+ x = (e) ? true : false;
|
- x = (e) ? 0 : 1;
+ x = (e) ? false : true;
)
...>
}
@depends on !badfunc1@
identifier eligible_func.f;
@@
- int
+ bool
f(...) {
<...
(
- return 1;
+ return true;
|
- return 0;
+ return false;
)
...>
}
Quentin Lambert (1):
video: fbdev: sis: sis_main.c: converting relevant int to bool
drivers/video/fbdev/sis/sis_main.c | 64 ++++++++++++++++++++------------------
1 file changed, 33 insertions(+), 31 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH] video: fbdev: sis: sis_main.c: converting relevant int to bool
From: Quentin Lambert @ 2014-11-27 10:42 UTC (permalink / raw)
To: Thomas Winischhofer
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
Convert int variables and functions to boolean when
relevant. The eligible cases were found using Coccinelle.
A simplified version of the semantic patch used to find
candidate is presented below :
@r exists@
identifier f;
local idexpression int x;
identifier xname;
@@
f(...) {
...when any
(
x@xname = 1;
|
x@xname = 0;
)
...when any
}
@bad exists@
identifier r.f;
local idexpression int r.x
expression e1 != {0, 1}, e2;
@@
f(...) {
...when any
(
x = e1;
|
x + e2
)
...when any
}
@depends on !bad@
identifier r.f;
local idexpression int r.x;
identifier r.xname;
@@
f(...) {
...
++ bool xname;
- int xname;
<...
(
x - 1;
+ true;
|
x - -1;
+ false;
)
...>
}
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
drivers/video/fbdev/sis/sis_main.c | 64 ++++++++++++++++++++------------------
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
index e5d11b1..5884846 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -108,7 +108,8 @@ sisfb_setdefaultparms(void)
static void sisfb_search_vesamode(unsigned int vesamode, bool quiet)
{
- int i = 0, j = 0;
+ bool j = false;
+ int i = 0;
/* We don't know the hardware specs yet and there is no ivideo */
@@ -137,7 +138,7 @@ static void sisfb_search_vesamode(unsigned int vesamode, bool quiet)
continue;
}
sisfb_mode_idx = i - 1;
- j = 1;
+ j = true;
break;
}
}
@@ -1185,7 +1186,8 @@ sisfb_do_set_var(struct fb_var_screeninfo *var, int isactive, struct fb_info *in
struct sis_video_info *ivideo = (struct sis_video_info *)info->par;
unsigned int htotal = 0, vtotal = 0;
unsigned int drate = 0, hrate = 0;
- int found_mode = 0, ret;
+ bool found_mode = false;
+ int ret;
int old_mode;
u32 pixclock;
@@ -1228,7 +1230,7 @@ sisfb_do_set_var(struct fb_var_screeninfo *var, int isactive, struct fb_info *in
(sisbios_mode[ivideo->sisfb_mode_idx].yres = var->yres) &&
(sisbios_mode[ivideo->sisfb_mode_idx].bpp = var->bits_per_pixel)) {
ivideo->mode_no = sisbios_mode[ivideo->sisfb_mode_idx].mode_no[ivideo->mni];
- found_mode = 1;
+ found_mode = true;
break;
}
ivideo->sisfb_mode_idx++;
@@ -1431,7 +1433,7 @@ sisfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
struct sis_video_info *ivideo = (struct sis_video_info *)info->par;
unsigned int htotal = 0, vtotal = 0, myrateindex = 0;
unsigned int drate = 0, hrate = 0, maxyres;
- int found_mode = 0;
+ bool found_mode = false;
int refresh_rate, search_idx, tidx;
bool recalc_clock = false;
u32 pixclock;
@@ -1466,7 +1468,7 @@ sisfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
(sisbios_mode[search_idx].bpp = var->bits_per_pixel)) {
if((tidx = sisfb_validate_mode(ivideo, search_idx,
ivideo->currentvbflags)) > 0) {
- found_mode = 1;
+ found_mode = true;
search_idx = tidx;
break;
}
@@ -1482,7 +1484,7 @@ sisfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
(var->bits_per_pixel = sisbios_mode[search_idx].bpp) ) {
if((tidx = sisfb_validate_mode(ivideo,search_idx,
ivideo->currentvbflags)) > 0) {
- found_mode = 1;
+ found_mode = true;
search_idx = tidx;
break;
}
@@ -3224,7 +3226,7 @@ sisfb_poh_allocate(struct SIS_HEAP *memheap, u32 size)
{
struct SIS_OH *pohThis;
struct SIS_OH *pohRoot;
- int bAllocated = 0;
+ bool bAllocated = false;
if(size > memheap->max_freesize) {
DPRINTK("sisfb: Can't allocate %dk video memory\n",
@@ -3236,7 +3238,7 @@ sisfb_poh_allocate(struct SIS_HEAP *memheap, u32 size)
while(pohThis != &memheap->oh_free) {
if(size <= pohThis->size) {
- bAllocated = 1;
+ bAllocated = true;
break;
}
pohThis = pohThis->poh_next;
@@ -3299,13 +3301,13 @@ sisfb_poh_free(struct SIS_HEAP *memheap, u32 base)
struct SIS_OH *poh_next;
u32 ulUpper;
u32 ulLower;
- int foundNode = 0;
+ bool foundNode = false;
poh_freed = memheap->oh_used.poh_next;
while(poh_freed != &memheap->oh_used) {
if(poh_freed->offset = base) {
- foundNode = 1;
+ foundNode = true;
break;
}
@@ -3892,7 +3894,7 @@ sisfb_reset_mode(struct sis_video_info *ivideo)
static void
sisfb_handle_command(struct sis_video_info *ivideo, struct sisfb_cmd *sisfb_command)
{
- int mycrt1off;
+ bool mycrt1off;
switch(sisfb_command->sisfb_cmd) {
case SISFB_CMD_GETVBFLAGS:
@@ -3919,7 +3921,7 @@ sisfb_handle_command(struct sis_video_info *ivideo, struct sisfb_cmd *sisfb_comm
sisfb_command->sisfb_result[0] = SISFB_CMD_ERR_NOCRT2;
} else {
sisfb_command->sisfb_result[0] = SISFB_CMD_ERR_OK;
- mycrt1off = sisfb_command->sisfb_arg[0] ? 0 : 1;
+ mycrt1off = sisfb_command->sisfb_arg[0] ? false : true;
if( ((ivideo->currentvbflags & VB_DISPTYPE_CRT1) && mycrt1off) ||
((!(ivideo->currentvbflags & VB_DISPTYPE_CRT1)) && !mycrt1off) ) {
ivideo->sisfb_crt1off = mycrt1off;
@@ -4037,32 +4039,32 @@ static int __init sisfb_setup(char *options)
}
#endif
-static int sisfb_check_rom(void __iomem *rom_base,
+static bool sisfb_check_rom(void __iomem *rom_base,
struct sis_video_info *ivideo)
{
void __iomem *rom;
int romptr;
if((readb(rom_base) != 0x55) || (readb(rom_base + 1) != 0xaa))
- return 0;
+ return false;
romptr = (readb(rom_base + 0x18) | (readb(rom_base + 0x19) << 8));
if(romptr > (0x10000 - 8))
- return 0;
+ return false;
rom = rom_base + romptr;
if((readb(rom) != 'P') || (readb(rom + 1) != 'C') ||
(readb(rom + 2) != 'I') || (readb(rom + 3) != 'R'))
- return 0;
+ return false;
if((readb(rom + 4) | (readb(rom + 5) << 8)) != ivideo->chip_vendor)
- return 0;
+ return false;
if((readb(rom + 6) | (readb(rom + 7) << 8)) != ivideo->chip_id)
- return 0;
+ return false;
- return 1;
+ return true;
}
static unsigned char *sisfb_find_rom(struct pci_dev *pdev)
@@ -4215,7 +4217,7 @@ static const unsigned short SiS_DRAMType[17][5] = {
{0x09,0x08,0x01,0x01,0x00}
};
-static int sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration,
+static bool sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration,
int buswidth, int PseudoRankCapacity,
int PseudoAdrPinCount, unsigned int mapsize)
{
@@ -4275,10 +4277,10 @@ static int sisfb_post_300_rwtest(struct sis_video_info *ivideo, int iteration,
/* Read data */
if(readw(FBAddr + BankNumHigh + PhysicalAdrHigh) = PhysicalAdrHigh)
- return 1;
+ return true;
}
- return 0;
+ return false;
}
static void sisfb_post_300_ramsize(struct pci_dev *pdev, unsigned int mapsize)
@@ -4539,18 +4541,18 @@ static void sisfb_post_xgi_delay(struct sis_video_info *ivideo, int delay)
}
}
-static int sisfb_find_host_bridge(struct sis_video_info *ivideo,
+static bool sisfb_find_host_bridge(struct sis_video_info *ivideo,
struct pci_dev *mypdev,
unsigned short pcivendor)
{
struct pci_dev *pdev = NULL;
unsigned short temp;
- int ret = 0;
+ bool ret = false;
while((pdev = pci_get_class(PCI_CLASS_BRIDGE_HOST, pdev))) {
temp = pdev->vendor;
if(temp = pcivendor) {
- ret = 1;
+ ret = true;
pci_dev_put(pdev);
break;
}
@@ -4559,7 +4561,7 @@ static int sisfb_find_host_bridge(struct sis_video_info *ivideo,
return ret;
}
-static int sisfb_post_xgi_rwtest(struct sis_video_info *ivideo, int starta,
+static bool sisfb_post_xgi_rwtest(struct sis_video_info *ivideo, int starta,
unsigned int enda, unsigned int mapsize)
{
unsigned int pos;
@@ -4576,18 +4578,18 @@ static int sisfb_post_xgi_rwtest(struct sis_video_info *ivideo, int starta,
sisfb_post_xgi_delay(ivideo, 150);
if(readl(ivideo->video_vbase) != 0)
- return 0;
+ return false;
for(i = starta; i <= enda; i++) {
pos = 1 << i;
if(pos < mapsize) {
if(readl(ivideo->video_vbase + pos) != pos)
- return 0;
+ return false;
} else
- return 0;
+ return false;
}
- return 1;
+ return true;
}
static int sisfb_post_xgi_ramsize(struct sis_video_info *ivideo)
--
1.9.1
^ permalink raw reply related
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