* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Lee Jones @ 2015-07-24 8:22 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Rob Clark,
devicetree, linux-kernel, linux-fbdev, linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson@sonymobile.com>
On Thu, 23 Jul 2015, Bjorn Andersson wrote:
> Add the possibility of specifying the default brightness in DT.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
>
> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
> is used by several other backlight drivers, so I considered this to be a
> "common" property and it's hence not prefixed with "qcom,".
>
> [1] https://lkml.org/lkml/2015/7/21/906
>
> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
This needs to be in a seperate patch.
> drivers/video/backlight/pm8941-wled.c | 4 ++++
You can't send patches on top of non-existent drivers.
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> index 424f8444a6cd..37503f8c3620 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> @@ -5,6 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> +- default-brightness: value from: 0-4095
> - label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..b875e58df0fc 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> + u32 val = 0;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> + of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
> +
> memset(&props, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> + props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(&pdev->dev, wled->name,
> &pdev->dev, wled,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-07-24 6:12 UTC (permalink / raw)
To: Jingoo Han
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <254E99D1-79CE-4B90-B732-E5A4A1308DC4@gmail.com>
2015-07-08 13:34 GMT+09:00 Jingoo Han <jingoohan1@gmail.com>:
>
> On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski <k.kozlowski.k@gmail.com> wrote:
>>
>> The platform_device_id is not modified by the driver and core uses it as
>> const.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
>
> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>
> Best regards,
> Jingoo Han
Seems nobody is picking it up, so I merge it through Samsung-SoC tree.
If there are any objections please let me know.
Best regards,
Krzysztof
>
>> ---
>> drivers/video/fbdev/s3c-fb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
>> index 7e3a05fc47aa..f72dd12456f9 100644
>> --- a/drivers/video/fbdev/s3c-fb.c
>> +++ b/drivers/video/fbdev/s3c-fb.c
>> @@ -1938,7 +1938,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
>> },
>> };
>>
>> -static struct platform_device_id s3c_fb_driver_ids[] = {
>> +static const struct platform_device_id s3c_fb_driver_ids[] = {
>> {
>> .name = "s3c-fb",
>> .driver_data = (unsigned long)&s3c_fb_data_64xx,
>> --
>> 2.1.4
>>
^ permalink raw reply
* [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Bjorn Andersson @ 2015-07-23 19:52 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rob Clark, devicetree, linux-kernel, linux-fbdev, linux-arm-msm
Add the possibility of specifying the default brightness in DT.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
This depends on the patch moving pm8941-wled to backlight [1]. The dt property
is used by several other backlight drivers, so I considered this to be a
"common" property and it's hence not prefixed with "qcom,".
[1] https://lkml.org/lkml/2015/7/21/906
Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
drivers/video/backlight/pm8941-wled.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index 424f8444a6cd..37503f8c3620 100644
--- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,6 +5,7 @@ Required properties:
- reg: slave address
Optional properties:
+- default-brightness: value from: 0-4095
- label: The name of the backlight device
- qcom,cs-out: bool; enable current sink output
- qcom,cabc: bool; enable content adaptive backlight control
diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
index c704c3236034..b875e58df0fc 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+ u32 val = 0;
int rc;
regmap = dev_get_regmap(pdev->dev.parent, NULL);
@@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
+ of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
+
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
+ props.brightness = val;
props.max_brightness = PM8941_WLED_REG_VAL_MAX;
bl = devm_backlight_device_register(&pdev->dev, wled->name,
&pdev->dev, wled,
--
1.8.2.2
^ permalink raw reply related
* Re: [patch] fbdev: off by one test (harmless)
From: Dan Carpenter @ 2015-07-23 12:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20141226172657.GA14762@mwanda>
This was never merged.
regards,
dan carpenter
On Thu, Jan 15, 2015 at 02:52:29PM +0200, Tomi Valkeinen wrote:
> On 15/01/15 14:43, Dan Carpenter wrote:
> > Sounds good to me. :) Could I get a Reported-by cookie?
>
> Oh, sorry. I thought I had added that, but... seems I didn't. Well now it's
> there. So updated patch below.
>
> I'll queue it for 3.20 if there are no comments.
>
> Tomi
>
>
> From 80fa3aed6f89728e9003bb0bdbd0b4bac2bc2186 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Date: Thu, 15 Jan 2015 13:47:19 +0200
> Subject: [PATCH] fbdev: fix cea_modes array size
>
> CEA defines 64 modes, indexed from 1 to 64. modedb has cea_modes arrays,
> which contains 64 entries. However, the code uses the CEA indices
> directly, i.e. the first mode is at cea_modes[1]. This means the array
> is one too short.
>
> This does not cause references to uninitialized memory as the code in
> fbmon only allows indexes up to 63, and the cea_modes does not contain
> an entry for the mode 64 so it could not be used in any case.
>
> However, the code contains a check 'if (idx > ARRAY_SIZE(cea_modes)',
> and while that check is a no-op as at that point idx cannot be >= 63, it
> upsets static checkers.
>
> Fix this by increasing the cea_array size to be 65, and change the code
> to allow mode 64.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> drivers/video/fbdev/core/fbmon.c | 4 ++--
> drivers/video/fbdev/core/modedb.c | 2 +-
> include/linux/fb.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
> index 5b0e313849bd..1829fe34a1df 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -1059,9 +1059,9 @@ void fb_edid_add_monspecs(unsigned char *edid, struct fb_monspecs *specs)
>
> for (i = specs->modedb_len + num; i < specs->modedb_len + num + svd_n; i++) {
> int idx = svd[i - specs->modedb_len - num];
> - if (!idx || idx > 63) {
> + if (!idx || idx >= ARRAY_SIZE(cea_modes)) {
> pr_warning("Reserved SVD code %d\n", idx);
> - } else if (idx > ARRAY_SIZE(cea_modes) || !cea_modes[idx].xres) {
> + } else if (!cea_modes[idx].xres) {
> pr_warning("Unimplemented SVD code %d\n", idx);
> } else {
> memcpy(&m[i], cea_modes + idx, sizeof(m[i]));
> diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
> index 388f7971494b..b2aba4e3150a 100644
> --- a/drivers/video/fbdev/core/modedb.c
> +++ b/drivers/video/fbdev/core/modedb.c
> @@ -289,7 +289,7 @@ static const struct fb_videomode modedb[] = {
> };
>
> #ifdef CONFIG_FB_MODE_HELPERS
> -const struct fb_videomode cea_modes[64] = {
> +const struct fb_videomode cea_modes[65] = {
> /* #1: 640x480p@59.94/60Hz */
> [1] = {
> NULL, 60, 640, 480, 39722, 48, 16, 33, 10, 96, 2, 0,
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 09bb7a18d287..024260687698 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -779,7 +779,7 @@ struct fb_videomode {
>
> extern const char *fb_mode_option;
> extern const struct fb_videomode vesa_modes[];
> -extern const struct fb_videomode cea_modes[64];
> +extern const struct fb_videomode cea_modes[65];
>
> struct fb_modelist {
> struct list_head list;
> --
> 2.2.2
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] staging: sm750fb: ddk750_power.c: Remove optionnal parentheses.
From: Greg KH @ 2015-07-23 3:56 UTC (permalink / raw)
To: Antoine BLIN
Cc: sudipm.mukherjee, devel, linux-fbdev, teddy.wang, linux-kernel
In-Reply-To: <1437138274-23146-1-git-send-email-antoine.blin@lip6.fr>
On Fri, Jul 17, 2015 at 03:04:33PM +0200, Antoine BLIN wrote:
> Fix up "return is not a function, parentheses are not required" error found by
> the checkpatch.pl script.
>
> Signed-off-by: Antoine BLIN <antoine.blin@lip6.fr>
> ---
> drivers/staging/sm750fb/ddk750_power.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Someone else already sent this fix in just before you did, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Bjorn Helgaas @ 2015-07-22 13:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Luis R. Rodriguez, Luis R. Rodriguez, bp, arnd, luto, akpm,
linux-pci, linux-kernel, tomi.valkeinen, mst, toshi.kani,
linux-fbdev, xen-devel, benh
In-Reply-To: <20150722083844.GA14626@gmail.com>
Hi Ingo,
On Wed, Jul 22, 2015 at 10:38:45AM +0200, Ingo Molnar wrote:
>
> * Bjorn Helgaas <bhelgaas@google.com> wrote:
>
> > > > > Let me know if these are OK or if there are any questions.
> > > > >
> > > > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> > > >
> > > > Ingo,
> > > >
> > > > Just a friendly reminder. Let me know if there are any issues or questions.
> > >
> > > It would be nice to get an Acked-by from Bjorn for the PCI API bits.
> >
> > I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is fine
> > (although I might have named it pci_ioremap_bar_wc() for consistency).
> >
> > I declined to merge or ack them myself because they're obvious extensions of
> > pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be exported
> > the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
>
> Huh? AFAICS pci_ioremap_bar() has been a _GPL export for a long time:
> ...
> (ioremap_wc() is EXPORT_SYMBOL() mostly by accident, it's the odd one out.)
You're right, I was mistaken about pci_ioremap_bar(). But I'm not
convinced yet that ioremap_wc() is the odd one out. All the interfaces I
found, with the exception of ioremap_uc() on x86 and pci_ioremap_bar(), are
EXPORT_SYMBOL(), even the _wc and _wt flavors.
> Also, FWIIW: I personally got essentially zero feedback and help from proprietary
> binary kernel module vendors in the past couple of years as x86 maintainer,
> despite a fair chunk of kernel crashes reported on distro kernels occuring in
> them...
>
> Based on that very negative experience, when we introduce something as complex and
> as critical as new caching APIs, the last thing I want is to have obscure bugs in
> binary modules I cannot fix in any reasonable fashion. So even if the parent APIs
> of new APIs weren't already _GPL exports (as in this case), I'd export them as
> _GPL in this case.
>
> > I think using EXPORT_SYMBOL_GPL to express individual political aims rather than
> > as a hint about what might be derived work makes us look like zealots, and
> > that's not my style.
>
> As far as I'm concerned it's a pure technological choice: I don't want to export
> certain types of hard to fix and critical functionality to drivers that I cannot
> then fix.
That's a good argument that I hadn't heard before (or possibly it was there
and I missed it). It would be stronger still if we could change the parent
APIs similarly. If a proprietary driver can't use pci_ioremap_wc() because
it's exported _GPL, it's trivial to use ioremap_wc() directly.
Bjorn
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Ingo Molnar @ 2015-07-22 8:38 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Luis R. Rodriguez, Luis R. Rodriguez, bp, arnd, luto, akpm,
linux-pci, linux-kernel, tomi.valkeinen, mst, toshi.kani,
linux-fbdev, xen-devel, benh
In-Reply-To: <20150721132157.GE16841@google.com>
* Bjorn Helgaas <bhelgaas@google.com> wrote:
> > > > Let me know if these are OK or if there are any questions.
> > > >
> > > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> > >
> > > Ingo,
> > >
> > > Just a friendly reminder. Let me know if there are any issues or questions.
> >
> > It would be nice to get an Acked-by from Bjorn for the PCI API bits.
>
> I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is fine
> (although I might have named it pci_ioremap_bar_wc() for consistency).
>
> I declined to merge or ack them myself because they're obvious extensions of
> pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be exported
> the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
Huh? AFAICS pci_ioremap_bar() has been a _GPL export for a long time:
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 126)#ifdef CONFIG_HAS_IOMEM
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 127)void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar)
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 128){
1f7bf3bfb5d60 (Bjorn Helgaas 2015-03-12 12:30:11 -0500 129) struct resource *res = &pdev->resource[bar];
1f7bf3bfb5d60 (Bjorn Helgaas 2015-03-12 12:30:11 -0500 130)
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 131) /*
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 132) * Make sure the BAR is actually a memory resource, not an IO resource
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 133) */
646c0282df042 (Bjorn Helgaas 2015-03-12 12:30:15 -0500 134) if (res->flags & IORESOURCE_UNSET || !(res->flags & IORESOURCE_MEM)) {
1f7bf3bfb5d60 (Bjorn Helgaas 2015-03-12 12:30:11 -0500 135) dev_warn(&pdev->dev, "can't ioremap BAR %d: %pR\n", bar, res);
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 136) return NULL;
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 137) }
1f7bf3bfb5d60 (Bjorn Helgaas 2015-03-12 12:30:11 -0500 138) return ioremap_nocache(res->start, resource_size(res));
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 139)}
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 140)EXPORT_SYMBOL_GPL(pci_ioremap_bar);
1684f5ddd4c0c (Andrew Morton 2008-12-01 14:30:30 -0800 141)#endif
commit 1684f5ddd4c0c happened in 2008, well before you became PCI maintainer in
2012.
and I'd prefer keeping the same EXPORT_SYMBOL_GPL() pattern for the new APIs.
(ioremap_wc() is EXPORT_SYMBOL() mostly by accident, it's the odd one out.)
Also, FWIIW: I personally got essentially zero feedback and help from proprietary
binary kernel module vendors in the past couple of years as x86 maintainer,
despite a fair chunk of kernel crashes reported on distro kernels occuring in
them...
Based on that very negative experience, when we introduce something as complex and
as critical as new caching APIs, the last thing I want is to have obscure bugs in
binary modules I cannot fix in any reasonable fashion. So even if the parent APIs
of new APIs weren't already _GPL exports (as in this case), I'd export them as
_GPL in this case.
> I think using EXPORT_SYMBOL_GPL to express individual political aims rather than
> as a hint about what might be derived work makes us look like zealots, and
> that's not my style.
As far as I'm concerned it's a pure technological choice: I don't want to export
certain types of hard to fix and critical functionality to drivers that I cannot
then fix.
But I also applied EXPORT_SYMBOL() patches in the past, so I'm not one-sided about
it.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
From: Bjorn Andersson @ 2015-07-22 0:49 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Bryan Wu, Richard Purdie, Jacek Anaszewski, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rob Clark, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-leds-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1437525889-24928-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
On Tue 21 Jul 17:44 PDT 2015, Bjorn Andersson wrote:
> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> be in the backlight framework and not in the LED framework. This moves
> the driver and adapts to the backlight api instead.
>
> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> Tested-by: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
Sorry, forgot the changelog.
Changed since v1:
- Moved dt binding document to backlight
- Dropped LED_CLASS as dependency
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
From: Bjorn Andersson @ 2015-07-22 0:44 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Bryan Wu, Richard Purdie, Jacek Anaszewski, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rob Clark, devicetree, linux-kernel, linux-leds, linux-fbdev,
linux-arm-msm
In-Reply-To: <1436990540-23354-1-git-send-email-bjorn.andersson@sonymobile.com>
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Tested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
.../backlight/pm8941-wled.txt} | 5 +-
drivers/leds/Kconfig | 8 ---
drivers/leds/Makefile | 1 -
drivers/video/backlight/Kconfig | 7 +++
drivers/video/backlight/Makefile | 1 +
.../backlight/pm8941-wled.c} | 60 ++++++++++------------
6 files changed, 35 insertions(+), 47 deletions(-)
rename Documentation/devicetree/bindings/{leds/leds-pm8941-wled.txt => video/backlight/pm8941-wled.txt} (84%)
rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c} (90%)
diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
similarity index 84%
rename from Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
rename to Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index a85a964d61f5..424f8444a6cd 100644
--- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,10 +5,7 @@ Required properties:
- reg: slave address
Optional properties:
-- label: The label for this led
- See Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger: Default trigger assigned to the LED
- See Documentation/devicetree/bindings/leds/common.txt
+- label: The name of the backlight device
- qcom,cs-out: bool; enable current sink output
- qcom,cabc: bool; enable content adaptive backlight control
- qcom,ext-gen: bool; use externally generated modulator signal to dim
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9ad35f72ab4c..b8d4b965ca2a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -578,14 +578,6 @@ config LEDS_VERSATILE
This option enabled support for the LEDs on the ARM Versatile
and RealView boards. Say Y to enabled these.
-config LEDS_PM8941_WLED
- tristate "LED support for the Qualcomm PM8941 WLED block"
- depends on LEDS_CLASS
- select REGMAP
- help
- This option enables support for the 'White' LED block
- on Qualcomm PM8941 PMICs.
-
comment "LED Triggers"
source "drivers/leds/trigger/Kconfig"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a2f513..abe96d960ebe 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -63,7 +63,6 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
-obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
# LED SPI Drivers
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 0505b796d743..5ffa4b4e26c0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,6 +299,13 @@ config BACKLIGHT_TOSA
If you have an Sharp SL-6000 Zaurus say Y to enable a driver
for its backlight
+config BACKLIGHT_PM8941_WLED
+ tristate "Qualcomm PM8941 WLED Driver"
+ select REGMAP
+ help
+ If you have the Qualcomm PM8941, say Y to enable a driver for the
+ WLED block.
+
config BACKLIGHT_SAHARA
tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
depends on X86
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index d67073f9d421..16ec534cff30 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
+obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
similarity index 90%
rename from drivers/leds/leds-pm8941-wled.c
rename to drivers/video/backlight/pm8941-wled.c
index bf64a593fbf1..c704c3236034 100644
--- a/drivers/leds/leds-pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -11,7 +11,7 @@
*/
#include <linux/kernel.h>
-#include <linux/leds.h>
+#include <linux/backlight.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -76,30 +76,29 @@ struct pm8941_wled_config {
};
struct pm8941_wled {
+ const char *name;
struct regmap *regmap;
u16 addr;
- struct led_classdev cdev;
-
struct pm8941_wled_config cfg;
};
-static int pm8941_wled_set(struct led_classdev *cdev,
- enum led_brightness value)
+static int pm8941_wled_update_status(struct backlight_device *bl)
{
- struct pm8941_wled *wled;
+ struct pm8941_wled *wled = bl_get_data(bl);
+ u16 val = bl->props.brightness;
u8 ctrl = 0;
- u16 val;
int rc;
int i;
- wled = container_of(cdev, struct pm8941_wled, cdev);
+ if (bl->props.power != FB_BLANK_UNBLANK ||
+ bl->props.fb_blank != FB_BLANK_UNBLANK ||
+ bl->props.state & BL_CORE_FBBLANK)
+ val = 0;
- if (value != 0)
+ if (val != 0)
ctrl = PM8941_WLED_REG_MOD_EN_BIT;
- val = value * PM8941_WLED_REG_VAL_MAX / LED_FULL;
-
rc = regmap_update_bits(wled->regmap,
wled->addr + PM8941_WLED_REG_MOD_EN,
PM8941_WLED_REG_MOD_EN_MASK, ctrl);
@@ -128,16 +127,6 @@ static int pm8941_wled_set(struct led_classdev *cdev,
return rc;
}
-static void pm8941_wled_set_brightness(struct led_classdev *cdev,
- enum led_brightness value)
-{
- if (pm8941_wled_set(cdev, value)) {
- dev_err(cdev->dev, "Unable to set brightness\n");
- return;
- }
- cdev->brightness = value;
-}
-
static int pm8941_wled_setup(struct pm8941_wled *wled)
{
int rc;
@@ -336,12 +325,9 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
}
wled->addr = val;
- rc = of_property_read_string(dev->of_node, "label", &wled->cdev.name);
+ rc = of_property_read_string(dev->of_node, "label", &wled->name);
if (rc)
- wled->cdev.name = dev->of_node->name;
-
- wled->cdev.default_trigger = of_get_property(dev->of_node,
- "linux,default-trigger", NULL);
+ wled->name = dev->of_node->name;
*cfg = pm8941_wled_config_defaults;
for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
@@ -377,8 +363,14 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
return 0;
}
+static const struct backlight_ops pm8941_wled_ops = {
+ .update_status = pm8941_wled_update_status,
+};
+
static int pm8941_wled_probe(struct platform_device *pdev)
{
+ struct backlight_properties props;
+ struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
int rc;
@@ -403,13 +395,14 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
- wled->cdev.brightness_set = pm8941_wled_set_brightness;
-
- rc = devm_led_classdev_register(&pdev->dev, &wled->cdev);
- if (rc)
- return rc;
-
- platform_set_drvdata(pdev, wled);
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = PM8941_WLED_REG_VAL_MAX;
+ bl = devm_backlight_device_register(&pdev->dev, wled->name,
+ &pdev->dev, wled,
+ &pm8941_wled_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
return 0;
};
@@ -432,4 +425,3 @@ module_platform_driver(pm8941_wled_driver);
MODULE_DESCRIPTION("pm8941 wled driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:pm8941-wled");
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
From: Scot Doyle @ 2015-07-21 18:45 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Linux API, linux-man,
Pavel Machek
In-Reply-To: <CAKgNAkgqTckfydFTDFsoqB1b_fAEiDZGYP=7b-bhN8d4Mp-bsg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 21 Jul 2015, Michael Kerrisk (man-pages) wrote:
> On 5 July 2015 at 19:41, Scot Doyle <lkml14@scotdoyle.com> wrote:
> > On Thu, 26 Mar 2015, Scot Doyle wrote:
> >> Add a Console Private CSI sequence to specify the current console's
> >> cursor blink interval. The interval is specified as a number of
> >> milliseconds until the next cursor display state toggle, from 50 to
> >> 65535.
> >>
> >> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
>
> I've applied this, adding Pavel's Acked-by.
>
> I also added some text to note that this appeared in Linux 4.2. Okay?
Yes, thank you.
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
From: Rob Clark @ 2015-07-21 18:22 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Bryan Wu, Richard Purdie, Jacek Anaszewski, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, Linux Kernel Mailing List, linux-leds,
Linux Fbdev development list, linux-arm-msm
In-Reply-To: <1436990540-23354-1-git-send-email-bjorn.andersson@sonymobile.com>
On Wed, Jul 15, 2015 at 4:02 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> be in the backlight framework and not in the LED framework. This moves
> the driver and adapts to the backlight api instead.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Tested-by: Rob Clark <robdclark@gmail.com>
(also on a z3, with work-in-progress panel driver for the AUO panel + drm/msm)
BR,
-R
> ---
> .../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
> drivers/leds/Kconfig | 8 ---
> drivers/leds/Makefile | 1 -
> drivers/video/backlight/Kconfig | 8 +++
> drivers/video/backlight/Makefile | 1 +
> .../backlight/pm8941-wled.c} | 59 ++++++++++------------
> 6 files changed, 36 insertions(+), 46 deletions(-)
> rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c} (90%)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> index a85a964d61f5..424f8444a6cd 100644
> --- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
> @@ -5,10 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> -- label: The label for this led
> - See Documentation/devicetree/bindings/leds/common.txt
> -- linux,default-trigger: Default trigger assigned to the LED
> - See Documentation/devicetree/bindings/leds/common.txt
> +- label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> - qcom,ext-gen: bool; use externally generated modulator signal to dim
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 9ad35f72ab4c..b8d4b965ca2a 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -578,14 +578,6 @@ config LEDS_VERSATILE
> This option enabled support for the LEDs on the ARM Versatile
> and RealView boards. Say Y to enabled these.
>
> -config LEDS_PM8941_WLED
> - tristate "LED support for the Qualcomm PM8941 WLED block"
> - depends on LEDS_CLASS
> - select REGMAP
> - help
> - This option enables support for the 'White' LED block
> - on Qualcomm PM8941 PMICs.
> -
> comment "LED Triggers"
> source "drivers/leds/trigger/Kconfig"
>
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 8d6a24a2f513..abe96d960ebe 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -63,7 +63,6 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> obj-$(CONFIG_LEDS_SYSCON) += leds-syscon.o
> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> -obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
> obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
>
> # LED SPI Drivers
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 0505b796d743..6c67c5430933 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,6 +299,14 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>
> +config BACKLIGHT_PM8941_WLED
> + tristate "Qualcomm PM8941 WLED Driver"
> + depends on LEDS_CLASS
> + select REGMAP
> + help
> + If you have the Qualcomm PM8941, say Y to enable a driver for the
> + WLED block.
> +
> config BACKLIGHT_SAHARA
> tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> depends on X86
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index d67073f9d421..16ec534cff30 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
> obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
> obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> +obj-$(CONFIG_BACKLIGHT_PM8941_WLED) += pm8941-wled.o
> obj-$(CONFIG_BACKLIGHT_PWM) += pwm_bl.o
> obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
> obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
> diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> similarity index 90%
> rename from drivers/leds/leds-pm8941-wled.c
> rename to drivers/video/backlight/pm8941-wled.c
> index bf64a593fbf1..4f5ae95331a1 100644
> --- a/drivers/leds/leds-pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -11,7 +11,7 @@
> */
>
> #include <linux/kernel.h>
> -#include <linux/leds.h>
> +#include <linux/backlight.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> @@ -76,30 +76,29 @@ struct pm8941_wled_config {
> };
>
> struct pm8941_wled {
> + const char *name;
> struct regmap *regmap;
> u16 addr;
>
> - struct led_classdev cdev;
> -
> struct pm8941_wled_config cfg;
> };
>
> -static int pm8941_wled_set(struct led_classdev *cdev,
> - enum led_brightness value)
> +static int pm8941_wled_update_status(struct backlight_device *bl)
> {
> - struct pm8941_wled *wled;
> + struct pm8941_wled *wled = bl_get_data(bl);
> + u16 val = bl->props.brightness;
> u8 ctrl = 0;
> - u16 val;
> int rc;
> int i;
>
> - wled = container_of(cdev, struct pm8941_wled, cdev);
> + if (bl->props.power != FB_BLANK_UNBLANK ||
> + bl->props.fb_blank != FB_BLANK_UNBLANK ||
> + bl->props.state & BL_CORE_FBBLANK)
> + val = 0;
>
> - if (value != 0)
> + if (val != 0)
> ctrl = PM8941_WLED_REG_MOD_EN_BIT;
>
> - val = value * PM8941_WLED_REG_VAL_MAX / LED_FULL;
> -
> rc = regmap_update_bits(wled->regmap,
> wled->addr + PM8941_WLED_REG_MOD_EN,
> PM8941_WLED_REG_MOD_EN_MASK, ctrl);
> @@ -128,16 +127,6 @@ static int pm8941_wled_set(struct led_classdev *cdev,
> return rc;
> }
>
> -static void pm8941_wled_set_brightness(struct led_classdev *cdev,
> - enum led_brightness value)
> -{
> - if (pm8941_wled_set(cdev, value)) {
> - dev_err(cdev->dev, "Unable to set brightness\n");
> - return;
> - }
> - cdev->brightness = value;
> -}
> -
> static int pm8941_wled_setup(struct pm8941_wled *wled)
> {
> int rc;
> @@ -336,12 +325,9 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
> }
> wled->addr = val;
>
> - rc = of_property_read_string(dev->of_node, "label", &wled->cdev.name);
> + rc = of_property_read_string(dev->of_node, "label", &wled->name);
> if (rc)
> - wled->cdev.name = dev->of_node->name;
> -
> - wled->cdev.default_trigger = of_get_property(dev->of_node,
> - "linux,default-trigger", NULL);
> + wled->name = dev->of_node->name;
>
> *cfg = pm8941_wled_config_defaults;
> for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
> @@ -377,8 +363,14 @@ static int pm8941_wled_configure(struct pm8941_wled *wled, struct device *dev)
> return 0;
> }
>
> +static const struct backlight_ops pm8941_wled_ops = {
> + .update_status = pm8941_wled_update_status,
> +};
> +
> static int pm8941_wled_probe(struct platform_device *pdev)
> {
> + struct backlight_properties props;
> + struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> int rc;
> @@ -403,13 +395,14 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> - wled->cdev.brightness_set = pm8941_wled_set_brightness;
> -
> - rc = devm_led_classdev_register(&pdev->dev, &wled->cdev);
> - if (rc)
> - return rc;
> -
> - platform_set_drvdata(pdev, wled);
> + memset(&props, 0, sizeof(struct backlight_properties));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> + bl = devm_backlight_device_register(&pdev->dev, wled->name,
> + &pdev->dev, wled,
> + &pm8941_wled_ops, &props);
> + if (IS_ERR(bl))
> + return PTR_ERR(bl);
>
> return 0;
> };
> --
> 1.8.2.2
>
^ permalink raw reply
* Re: [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
From: Michael Kerrisk (man-pages) @ 2015-07-21 16:55 UTC (permalink / raw)
To: Scot Doyle
Cc: lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Linux API, linux-man,
Pavel Machek
In-Reply-To: <alpine.DEB.2.11.1507051724240.1696@local>
Hello Scot,
On 5 July 2015 at 19:41, Scot Doyle <lkml14@scotdoyle.com> wrote:
> On Thu, 26 Mar 2015, Scot Doyle wrote:
>> Add a Console Private CSI sequence to specify the current console's
>> cursor blink interval. The interval is specified as a number of
>> milliseconds until the next cursor display state toggle, from 50 to
>> 65535.
>>
>> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
I've applied this, adding Pavel's Acked-by.
I also added some text to note that this appeared in Linux 4.2. Okay?
Cheers,
Michael
>> ---
>> man4/console_codes.4 | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/man4/console_codes.4 b/man4/console_codes.4
>> index 34f7535..7d05076 100644
>> --- a/man4/console_codes.4
>> +++ b/man4/console_codes.4
>> @@ -377,6 +377,7 @@ ESC [ 15 ] T{
>> Bring the previous console to the front
>> (since Linux 2.6.0).
>> T}
>> +ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds.
>> .TE
>> .SS Character sets
>> The kernel knows about 4 translations of bytes into console-screen
>> --
>> 2.1.0
>>
>
> Hi Michael,
>
> Will you apply now that Linus has pulled the rest?
> (see bd63364caa8df38bad2b25b11b2a1b849475cce5)
>
> Thank you,
> Scot
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Bjorn Helgaas @ 2015-07-21 13:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Luis R. Rodriguez, Luis R. Rodriguez, bp, arnd, luto, akpm,
linux-pci, linux-kernel, tomi.valkeinen, mst, toshi.kani,
linux-fbdev, xen-devel, benh
In-Reply-To: <20150721085252.GA15861@gmail.com>
On Tue, Jul 21, 2015 at 10:52:52AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez <mcgrof@suse.com> wrote:
>
> > On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >
> > > Ingo,
> > >
> > > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > > and they have baked there for a while now. That tree receives 0-day
> > > bot testing, but other than that its not clear what other tests were
> > > run on these patches. Boris modified the commit logs a bit, and made one
> > > optimizaiton to bail early on an PCI ioremap call when it should. These
> > > patches have no modifications from what is on Boris' tree and tip-mm branch.
> > >
> > > The 0 day build bot did find issues on Boris' tree but those are related
> > > to ioremap_uc() (already upstream) and its first use on atyfb (not
> > > upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> > > another patch series prior to posting the final set for atyfb which makes
> > > use of ioremap_uc().
> > >
> > > No issues have been found with this series. Benh did note some possible issues
> > > with expectations with what is done for write-combining for PowerPC [1] but
> > > the issue is a rather general long standing issue with semantics of ioremap --
> > > in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> > > write-combine as it uses too heavy barriers. Benh notes that although
> > > writel_relaxed() today is identical to writel() this can be changed. There are
> > > other general semantics issues with ioremap() variant calls -- we seem to have
> > > all gotten together to discuss all these issues on a thread where Dan Williams
> > > is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> > > intersted on these issues or semantic concerns can drop in and chime there.
> > >
> > > Let me know if these are OK or if there are any questions.
> > >
> > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> >
> > Ingo,
> >
> > Just a friendly reminder. Let me know if there are any issues or questions.
>
> It would be nice to get an Acked-by from Bjorn for the PCI API bits.
I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is
fine (although I might have named it pci_ioremap_bar_wc() for consistency).
I declined to merge or ack them myself because they're obvious extensions
of pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be
exported the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
I think using EXPORT_SYMBOL_GPL to express individual political aims rather
than as a hint about what might be derived work makes us look like zealots,
and that's not my style.
Bjorn
^ permalink raw reply
* Re: likely signedness bug in drm and nvidia drivers
From: Daniel Thompson @ 2015-07-21 8:56 UTC (permalink / raw)
To: Ilia Mirkin, Rasmus Villemoes
Cc: linux-fbdev, Tomi Valkeinen, Ben Skeggs,
dri-devel@lists.freedesktop.org
In-Reply-To: <CAKb7UvhLp=G6yH7MgivOPp9kDDdH2Y2q4v0YDjt8vHewLzzy=w@mail.gmail.com>
On 21/07/15 03:44, Ilia Mirkin wrote:
> I think you're right. The intent is to mask off the bits above>
bits_per_pixel. So if bits_per_pixel is 24, the mask would be>
0xff000000. If it's 16, then the mask would be 0xffff0000. If it's 32,>
then the mask is 0.> > In reality, bits_per_pixel is almost exclusively
32, which will end up> with a mask of 0 (note that the shift result is
inverted at the end).> So for the majority case, there's not bug... just
a useless operation.> > I took a look at linux/bitops.h, and there's
nothing particularly> great there. GENMASK, I guess, but it's not quite
right. Just> switching to 0U should be fine there.
I really don't see GENMASK() isn't quite right.
Try:
uint32_t mask = GENMASK(32, info->var.bits_per_pixel);
Versus:
uint32_t mask = ~(~0u >> (32 - info->var.bits_per_pixel));
For me, the GENMASK() is obvious whilst the later takes a good bit of
mental decoding.
Daniel.
^ permalink raw reply
* Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
From: Ingo Molnar @ 2015-07-21 8:52 UTC (permalink / raw)
To: Luis R. Rodriguez, bhelgaas
Cc: Luis R. Rodriguez, bp, arnd, luto, akpm, linux-pci, linux-kernel,
tomi.valkeinen, mst, toshi.kani, linux-fbdev, xen-devel, benh
In-Reply-To: <20150717202923.GC30479@wotan.suse.de>
* Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Wed, Jul 08, 2015 at 06:54:11PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > Ingo,
> >
> > Boris is on vacation, he picked up these patches on his bp#tip-mm tree [0]
> > and they have baked there for a while now. That tree receives 0-day
> > bot testing, but other than that its not clear what other tests were
> > run on these patches. Boris modified the commit logs a bit, and made one
> > optimizaiton to bail early on an PCI ioremap call when it should. These
> > patches have no modifications from what is on Boris' tree and tip-mm branch.
> >
> > The 0 day build bot did find issues on Boris' tree but those are related
> > to ioremap_uc() (already upstream) and its first use on atyfb (not
> > upstream) -- I will be addressing a fix for that ioremap_uc() issue through
> > another patch series prior to posting the final set for atyfb which makes
> > use of ioremap_uc().
> >
> > No issues have been found with this series. Benh did note some possible issues
> > with expectations with what is done for write-combining for PowerPC [1] but
> > the issue is a rather general long standing issue with semantics of ioremap --
> > in the case for ioremap_wc() on PowerPC benh notes that writel() will never
> > write-combine as it uses too heavy barriers. Benh notes that although
> > writel_relaxed() today is identical to writel() this can be changed. There are
> > other general semantics issues with ioremap() variant calls -- we seem to have
> > all gotten together to discuss all these issues on a thread where Dan Williams
> > is proposing to "unify ioremap prototypes and macro aliases" [1], folks
> > intersted on these issues or semantic concerns can drop in and chime there.
> >
> > Let me know if these are OK or if there are any questions.
> >
> > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
>
> Ingo,
>
> Just a friendly reminder. Let me know if there are any issues or questions.
It would be nice to get an Acked-by from Bjorn for the PCI API bits.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Move PM8941 WLED driver to backlight
From: Lee Jones @ 2015-07-21 8:50 UTC (permalink / raw)
To: Jingoo Han
Cc: Jacek Anaszewski, Bjorn Andersson, Jacek Anaszewski, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Bryan Wu,
Richard Purdie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Rob Clark, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <9F0858DA-62D4-4511-A515-6CE38A680969@gmail.com>
On Tue, 21 Jul 2015, Jingoo Han wrote:
>
> On 2015. 7. 21., at AM 6:11, Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> >> On 20.07.2015 16:15, Jingoo Han wrote:
> >>> On Thursday, July 16, 2015 5:01 PM, Jacek Anaszewski wrote:
> >>>> On 07/15/2015 10:02 PM, Bjorn Andersson wrote:
> >>>> The Qualcomm PM8941 WLED block is used for backlight and should therefor
> >>>> be in the backlight framework and not in the LED framework. This moves
> >>>> the driver and adapts to the backlight api instead.
> >>>>
> >>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >>>> ---
> >>>> .../devicetree/bindings/leds/leds-pm8941-wled.txt | 5 +-
> >>>> drivers/leds/Kconfig | 8 ---
> >>>> drivers/leds/Makefile | 1 -
> >>>> drivers/video/backlight/Kconfig | 8 +++
> >>>> drivers/video/backlight/Makefile | 1 +
> >>>> .../backlight/pm8941-wled.c} | 59 ++++++++++------------
> >>>> 6 files changed, 36 insertions(+), 46 deletions(-)
> >>>> rename drivers/{leds/leds-pm8941-wled.c => video/backlight/pm8941-wled.c} (90%)
> >>>
> >>> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> >>
> >> If you are not an author of this driver or a maintainer affected by this patch,
> >> Just 'Reviewed-by' looks good.
> >
> > I am a LED subsystem maintainer.
>
> OK, I see.
> I didn't notice that you were added as the maintainer 2 months ago.
Please read: Sections 12 and 13 of Documentation/SubmittingPatches.
Granted, Acked-bys are used by Maintainers when reviewing changes in
subsystems they are responsible for. However, that's not the sole use
of them. Anyone can provide an Ack for code they have reviewed, but
are not an expert in. Reviewed-bys have much stronger meaning and
should only be used if the supplier knows the code and the subsystem
well. Please see SubmittingPatches for a full meaning of the
Reviewed-by tag.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 2/2] sm750fb: coding style fixes lines over 80 chars - v2
From: Dan Carpenter @ 2015-07-21 8:39 UTC (permalink / raw)
To: Vinay Simha BN
Cc: open list:STAGING SUBSYSTEM,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
Teddy Wang, Greg Kroah-Hartman, open list, Sudip Mukherjee
In-Reply-To: <1437464402-18451-2-git-send-email-simhavcs@gmail.com>
Slow down. This patch is totally wrong. You're panicking and sending
nonsense patches without a description or signed off by. It deletes
code. The v2 isn't where it should be [PATCH 2/2 v2].
There is no need to rush. Fix this and send the patch tomorrow.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] sm750fb: coding style fixes lines over 80 chars
From: Dan Carpenter @ 2015-07-21 8:35 UTC (permalink / raw)
To: Vinay Simha BN
Cc: open list:STAGING SUBSYSTEM,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
Teddy Wang, Greg Kroah-Hartman, open list, Sudip Mukherjee
In-Reply-To: <1437464402-18451-1-git-send-email-simhavcs@gmail.com>
On Tue, Jul 21, 2015 at 01:10:00PM +0530, Vinay Simha BN wrote:
> diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
> index 8dc6bd2..43d700b 100644
> --- a/drivers/staging/sm750fb/sm750_help.h
> +++ b/drivers/staging/sm750fb/sm750_help.h
> @@ -49,17 +49,23 @@
> /* Field Macros */
> #define FIELD_START(field) (0 ? field)
> #define FIELD_END(field) (1 ? field)
> -#define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
> -#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) | ((1 << (FIELD_SIZE(field)-1)) - 1)) << FIELD_START(field))
> -#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> FIELD_START(field))
> -#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & FIELD_MASK(field))
> +#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
> + FIELD_START(field))
> +#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
> + | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
> + << FIELD_START(field))
> +#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
> + FIELD_START(field))
> +#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
> + FIELD_MASK(field))
>
> #define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
> - reg ## _ ## field ## _ ## value)
> + reg ## _ ## field ## _ ## value)
> #define FIELD_INIT_VAL(reg, field, value) \
> (FIELD_DENORMALIZE(reg ## _ ## field, value))
> #define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
> - | FIELD_DENORMALIZE(r ## _ ## f, r ## _ ## f ## _ ## v)
> + | FIELD_DENORMALIZE(r ## _ ## f, \
> + r ## _ ## f ## _ ## v)
>
> #define RGB(r, g, b) \
> ( \
These are worse for reading now. Better to ignore the warning instead
of making the code ugly.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] sm750fb: coding style fixes lines over 80 chars
From: Joe Perches @ 2015-07-21 8:14 UTC (permalink / raw)
To: Vinay Simha BN
Cc: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437464402-18451-1-git-send-email-simhavcs@gmail.com>
On Tue, 2015-07-21 at 13:10 +0530, Vinay Simha BN wrote:
> scripts/checkpatch.pl kernel coding style fixes of WARNING
Please run your patches through scripts/checkpatch.pl --strict
> diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
> index b7cf6b2..abad4fe 100644
> --- a/drivers/staging/sm750fb/ddk750_power.h
> +++ b/drivers/staging/sm750fb/ddk750_power.h
> @@ -12,9 +12,9 @@ DPMS_t;
> #define setDAC(off) \
> { \
> POKE32(MISC_CTRL, FIELD_VALUE(PEEK32(MISC_CTRL), \
> - MISC_CTRL, \
> - DAC_POWER, \
> - off)); \
> + MISC_CTRL, \
> + DAC_POWER, \
> + off)); \
This is used only once and might be better expanded
in-place instead.
It's a single statement macro and doesn't need
braces or a terminating ; and it shouldn't be
indented 2 tabs.
#define setDAC(off) \
POKE32(MISC_CTRL, \
FIELD_VALUE(PEEK32(MISC_CTRL), MISC_CTRL, DAC_POWER, \
off))
> diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
[]
> @@ -5,10 +5,11 @@
[]
> + SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit
> + (always high) */
comment style isn't correct
etc...
^ permalink raw reply
* [PATCH 2/2] sm750fb: coding style fixes lines over 80 chars - v2
From: Vinay Simha BN @ 2015-07-21 7:52 UTC (permalink / raw)
Cc: Vinay Simha BN, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437464402-18451-1-git-send-email-simhavcs@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.h | 30 ++++++++++++++++++++----------
drivers/staging/sm750fb/sm750_help.h | 23 +----------------------
2 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index da067a0..c56fa99 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -259,12 +259,18 @@ unsigned int height, /* width and height of rectangle in pixel value */
unsigned int rop2);
int hw_imageblit(struct lynx_accel *accel,
- const char *pSrcbuf, /* pointer to start of source
- buffer in system memory */
- u32 srcDelta, /* Pitch value (in bytes) of the source buffer,
- +ive means top down and -ive mean button up */
- u32 startBit, /* Mono data can start at any bit in a byte,
- this value should be 0 to 7 */
+ const char *pSrcbuf, /*
+ * pointer to start of source
+ * buffer in system memory
+ */
+ u32 srcDelta, /*
+ * Pitch value (in bytes) of the source buffer,
+ * +ive means top down and -ive mean button up
+ */
+ u32 startBit, /*
+ * Mono data can start at any bit in a byte,
+ * this value should be 0 to 7
+ */
u32 dBase, /* Address of destination: offset in frame buffer */
u32 dPitch, /* Pitch value of destination surface in BYTE */
u32 bytePerPixel, /* Color depth of destination surface */
@@ -272,9 +278,13 @@ int hw_imageblit(struct lynx_accel *accel,
u32 dy, /* Starting coordinate of destination surface */
u32 width,
u32 height, /* width and height of rectange in pixel value */
- u32 fColor, /* Foreground color (corresponding to a 1 in the
- monochrome data */
- u32 bColor, /* Background color (corresponding to a 0 in the
- monochrome data */
+ u32 fColor, /*
+ * Foreground color (corresponding to a 1 in the
+ * monochrome data
+ */
+ u32 bColor, /*
+ * Background color (corresponding to a 0 in the
+ * monochrome data
+ */
u32 rop2);
#endif
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index 43d700b..c9378e2 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -1,7 +1,7 @@
#ifndef LYNX_HELP_H__
#define LYNX_HELP_H__
-/* FIELD MACROS */
+/* FIELD MACROS */
#define _LSB(f) (0 ? f)
#define _MSB(f) (1 ? f)
#define _COUNT(f) (_MSB(f) - _LSB(f) + 1)
@@ -46,27 +46,6 @@
~ _F_MASK(reg ## _ ## field) \
)
-/* Field Macros */
-#define FIELD_START(field) (0 ? field)
-#define FIELD_END(field) (1 ? field)
-#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
- FIELD_START(field))
-#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
- | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
- << FIELD_START(field))
-#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
- FIELD_START(field))
-#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
- FIELD_MASK(field))
-
-#define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
- reg ## _ ## field ## _ ## value)
-#define FIELD_INIT_VAL(reg, field, value) \
- (FIELD_DENORMALIZE(reg ## _ ## field, value))
-#define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
- | FIELD_DENORMALIZE(r ## _ ## f, \
- r ## _ ## f ## _ ## v)
-
#define RGB(r, g, b) \
( \
(unsigned long) (((r) << 16) | ((g) << 8) | (b)) \
--
2.1.2
^ permalink raw reply related
* [PATCH 1/2] sm750fb: coding style fixes lines over 80 chars
From: Vinay Simha BN @ 2015-07-21 7:52 UTC (permalink / raw)
Cc: Vinay Simha BN, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437461084-17565-1-git-send-email-simhavcs@gmail.com>
scripts/checkpatch.pl kernel coding style fixes of WARNING
WARNING: line over 80 characters
Signed-off-by: Vinay Simha BN <simhavcs@gmail.com>
---
drivers/staging/sm750fb/ddk750_display.h | 10 +++++-----
drivers/staging/sm750fb/ddk750_hwi2c.h | 6 ++++--
drivers/staging/sm750fb/ddk750_power.h | 6 +++---
drivers/staging/sm750fb/ddk750_sii164.h | 12 +++++++-----
drivers/staging/sm750fb/sm750.h | 13 ++++++++-----
drivers/staging/sm750fb/sm750_accel.h | 19 ++++++++++++-------
drivers/staging/sm750fb/sm750_help.h | 21 ++++++++++++++-------
drivers/staging/sm750fb/sm750_hw.h | 21 +++++++++++++--------
8 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_display.h b/drivers/staging/sm750fb/ddk750_display.h
index abccf84..9afa366 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -110,19 +110,19 @@ typedef enum _disp_output_t {
/* LCD1 show secondary and DSUB show primary */
LCD1_DSUB_DUAL_SWAP = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
- CRT_2_PRI|PRI_TP_ON|DAC_ON,
+ CRT_2_PRI|PRI_TP_ON|DAC_ON,
LCD1_LCD2_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|
- CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+ CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
LCD1_LCD2_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
- CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+ CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
LCD1_LCD2_DSUB_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|DAC_ON|
- CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+ CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
LCD1_LCD2_DSUB_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|DAC_ON|
- CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+ CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
}
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 0b830ba6..3d4e48b 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -5,6 +5,8 @@
int hwI2CInit(unsigned char busSpeedMode);
void hwI2CClose(void);
-unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char registerIndex);
-int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex, unsigned char data);
+unsigned char hwI2CReadReg(unsigned char deviceAddress,
+ unsigned char registerIndex);
+int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex,
+ unsigned char data);
#endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h b/drivers/staging/sm750fb/ddk750_power.h
index b7cf6b2..abad4fe 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -12,9 +12,9 @@ DPMS_t;
#define setDAC(off) \
{ \
POKE32(MISC_CTRL, FIELD_VALUE(PEEK32(MISC_CTRL), \
- MISC_CTRL, \
- DAC_POWER, \
- off)); \
+ MISC_CTRL, \
+ DAC_POWER, \
+ off)); \
}
void ddk750_setDPMS(DPMS_t);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h b/drivers/staging/sm750fb/ddk750_sii164.h
index f2610c9..a5246bd 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -5,10 +5,11 @@
/* Hot Plug detection mode structure */
typedef enum _sii164_hot_plug_mode_t {
- SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit (always high). */
- SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
- SII164_HOTPLUG_USE_RSEN, /* Use Receiver Sense detect bit. */
- SII164_HOTPLUG_USE_HTPLG /* Use Hot Plug detect bit. */
+ SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit
+ (always high) */
+ SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
+ SII164_HOTPLUG_USE_RSEN, /* Use Receiver Sense detect bit. */
+ SII164_HOTPLUG_USE_HTPLG /* Use Hot Plug detect bit. */
} sii164_hot_plug_mode_t;
@@ -39,7 +40,8 @@ unsigned char sii164IsConnected(void);
unsigned char sii164CheckInterrupt(void);
void sii164ClearInterrupt(void);
#endif
-/* below register definination is used for Silicon Image SiI164 DVI controller chip */
+/* below register definination is used for Silicon Image
+ SiI164 DVI controller chip */
/*
* Vendor ID registers
*/
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 9b101a9..e2bd920 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -32,9 +32,10 @@ struct lynx_accel {
u32, u32, u32, u32,
u32, u32, u32, u32);
- int (*de_imageblit)(struct lynx_accel *, const char *, u32, u32, u32, u32,
- u32, u32, u32, u32,
- u32, u32, u32, u32);
+ int (*de_imageblit)(struct lynx_accel *, const char *,
+ u32, u32, u32, u32,
+ u32, u32, u32, u32,
+ u32, u32, u32, u32);
};
@@ -100,7 +101,8 @@ struct lynxfb_crtc {
int channel;/* which channel this crtc stands for*/
resource_size_t vidmem_size;/* this view's video memory max size */
- /* below attributes belong to info->fix, their value depends on specific adaptor*/
+ /* below attributes belong to info->fix, their value depends on
+ specific adaptor*/
u16 line_pad;/* padding information:0,1,2,4,8,16,... */
u16 xpanstep;
u16 ypanstep;
@@ -113,7 +115,8 @@ struct lynxfb_crtc {
struct fb_fix_screeninfo*);
int (*proc_checkMode)(struct lynxfb_crtc*, struct fb_var_screeninfo*);
- int (*proc_setColReg)(struct lynxfb_crtc*, ushort, ushort, ushort, ushort);
+ int (*proc_setColReg)(struct lynxfb_crtc*, ushort, ushort, ushort,
+ ushort);
void (*clear)(struct lynxfb_crtc*);
/* pan display */
int (*proc_panDisplay)(struct lynxfb_crtc *,
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index f252e47..da067a0 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -26,7 +26,7 @@
#define DE_SOURCE_WRAP_ENABLE 1
#define DE_SOURCE_X_K1 29:16
#define DE_SOURCE_Y_K2 15:0
-#define DE_SOURCE_X_K1_MONO 20:16
+#define DE_SOURCE_X_K1_MONO { 20:16 }
#define DE_DESTINATION 0x4
#define DE_DESTINATION_WRAP 31:31
@@ -259,17 +259,22 @@ unsigned int height, /* width and height of rectangle in pixel value */
unsigned int rop2);
int hw_imageblit(struct lynx_accel *accel,
- const char *pSrcbuf, /* pointer to start of source buffer in system memory */
- u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
- u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
- u32 dBase, /* Address of destination: offset in frame buffer */
+ const char *pSrcbuf, /* pointer to start of source
+ buffer in system memory */
+ u32 srcDelta, /* Pitch value (in bytes) of the source buffer,
+ +ive means top down and -ive mean button up */
+ u32 startBit, /* Mono data can start at any bit in a byte,
+ this value should be 0 to 7 */
+ u32 dBase, /* Address of destination: offset in frame buffer */
u32 dPitch, /* Pitch value of destination surface in BYTE */
u32 bytePerPixel, /* Color depth of destination surface */
u32 dx,
u32 dy, /* Starting coordinate of destination surface */
u32 width,
u32 height, /* width and height of rectange in pixel value */
- u32 fColor, /* Foreground color (corresponding to a 1 in the monochrome data */
- u32 bColor, /* Background color (corresponding to a 0 in the monochrome data */
+ u32 fColor, /* Foreground color (corresponding to a 1 in the
+ monochrome data */
+ u32 bColor, /* Background color (corresponding to a 0 in the
+ monochrome data */
u32 rop2);
#endif
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index 8dc6bd2..43d700b 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -49,17 +49,23 @@
/* Field Macros */
#define FIELD_START(field) (0 ? field)
#define FIELD_END(field) (1 ? field)
-#define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
-#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) | ((1 << (FIELD_SIZE(field)-1)) - 1)) << FIELD_START(field))
-#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> FIELD_START(field))
-#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & FIELD_MASK(field))
+#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
+ FIELD_START(field))
+#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
+ | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
+ << FIELD_START(field))
+#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
+ FIELD_START(field))
+#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
+ FIELD_MASK(field))
#define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
- reg ## _ ## field ## _ ## value)
+ reg ## _ ## field ## _ ## value)
#define FIELD_INIT_VAL(reg, field, value) \
(FIELD_DENORMALIZE(reg ## _ ## field, value))
#define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
- | FIELD_DENORMALIZE(r ## _ ## f, r ## _ ## f ## _ ## v)
+ | FIELD_DENORMALIZE(r ## _ ## f, \
+ r ## _ ## f ## _ ## v)
#define RGB(r, g, b) \
( \
@@ -68,7 +74,8 @@
#define RGB16(r, g, b) \
( \
- (unsigned short) ((((r) & 0xF8) << 8) | (((g) & 0xFC) << 3) | (((b) & 0xF8) >> 3)) \
+ (unsigned short) ((((r) & 0xF8) << 8) | (((g) & 0xFC) << 3) | \
+ (((b) & 0xF8) >> 3)) \
)
static inline unsigned int absDiff(unsigned int a, unsigned int b)
diff --git a/drivers/staging/sm750fb/sm750_hw.h b/drivers/staging/sm750fb/sm750_hw.h
index ef0a16f..eceea39 100644
--- a/drivers/staging/sm750fb/sm750_hw.h
+++ b/drivers/staging/sm750fb/sm750_hw.h
@@ -61,13 +61,15 @@ struct sm750_state {
int yLCD;
};
-/* sm750_share stands for a presentation of two frame buffer
- that use one sm750 adaptor, it is similar to the super class of lynx_share
- in C++
- */
+/*
+ sm750_share stands for a presentation of two frame buffer
+ that use one sm750 adaptor, it is similar to the super
+ class of lynx_share in C++
+*/
struct sm750_share {
- /* it's better to put lynx_share struct to the first place of sm750_share */
+ /* it's better to put lynx_share struct to the first place of
+ sm750_share */
struct lynx_share share;
struct sm750_state state;
int hwCursor;
@@ -85,10 +87,13 @@ int hw_sm750_deWait(void);
int hw_sm750le_deWait(void);
resource_size_t hw_sm750_getVMSize(struct lynx_share *);
-int hw_sm750_output_checkMode(struct lynxfb_output*, struct fb_var_screeninfo*);
-int hw_sm750_output_setMode(struct lynxfb_output*, struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
+int hw_sm750_output_checkMode(struct lynxfb_output*,
+ struct fb_var_screeninfo*);
+int hw_sm750_output_setMode(struct lynxfb_output*,
+ struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
int hw_sm750_crtc_checkMode(struct lynxfb_crtc*, struct fb_var_screeninfo*);
-int hw_sm750_crtc_setMode(struct lynxfb_crtc*, struct fb_var_screeninfo*, struct fb_fix_screeninfo*);
+int hw_sm750_crtc_setMode(struct lynxfb_crtc*, struct fb_var_screeninfo*,
+ struct fb_fix_screeninfo*);
int hw_sm750_setColReg(struct lynxfb_crtc*, ushort, ushort, ushort, ushort);
int hw_sm750_setBLANK(struct lynxfb_output*, int);
int hw_sm750le_setBLANK(struct lynxfb_output*, int);
--
2.1.2
^ permalink raw reply related
* Re: [PATCH] sm750fb: coding style fixes in _accel.h,__help.h
From: Sudip Mukherjee @ 2015-07-21 7:43 UTC (permalink / raw)
To: Vinay Simha
Cc: Joe Perches, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <CAGWqDJ5AkG5PwQOkboZfiC1PzXw0j+x5zwaYn0SWWtiks+OP2A@mail.gmail.com>
On Tue, Jul 21, 2015 at 12:48:00PM +0530, Vinay Simha wrote:
> Yes,
> Shall i send both the patches together, patch 1 and 2 ?
yes, please send a patch giving a version number like v2 or v3 which
should apply to staging-testing keeping in mind the review that Joe has
given on your previous patch.
regards
sudip
^ permalink raw reply
* Re: [PATCH] sm750fb: coding style fixes in _accel.h,__help.h
From: Sudip Mukherjee @ 2015-07-21 7:29 UTC (permalink / raw)
To: Vinay Simha BN
Cc: Joe Perches, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437461084-17565-1-git-send-email-simhavcs@gmail.com>
On Tue, Jul 21, 2015 at 12:14:43PM +0530, Vinay Simha BN wrote:
> WARNING: line over 80 characters
> comment block , odd statement fixes
This is not applying. I think you have done the changes on top of your
previous patch.
regards
sudip
^ permalink raw reply
* [PATCH] sm750fb: coding style fixes in _accel.h,__help.h
From: Vinay Simha BN @ 2015-07-21 6:56 UTC (permalink / raw)
To: Joe Perches
Cc: Vinay Simha BN, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <1437118721.2495.54.camel@perches.com>
WARNING: line over 80 characters
comment block , odd statement fixes
Signed-off-by: Vinay Simha BN <simhavcs@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.h | 30 ++++++++++++++++++++----------
drivers/staging/sm750fb/sm750_help.h | 23 +----------------------
2 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index da067a0..c56fa99 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -259,12 +259,18 @@ unsigned int height, /* width and height of rectangle in pixel value */
unsigned int rop2);
int hw_imageblit(struct lynx_accel *accel,
- const char *pSrcbuf, /* pointer to start of source
- buffer in system memory */
- u32 srcDelta, /* Pitch value (in bytes) of the source buffer,
- +ive means top down and -ive mean button up */
- u32 startBit, /* Mono data can start at any bit in a byte,
- this value should be 0 to 7 */
+ const char *pSrcbuf, /*
+ * pointer to start of source
+ * buffer in system memory
+ */
+ u32 srcDelta, /*
+ * Pitch value (in bytes) of the source buffer,
+ * +ive means top down and -ive mean button up
+ */
+ u32 startBit, /*
+ * Mono data can start at any bit in a byte,
+ * this value should be 0 to 7
+ */
u32 dBase, /* Address of destination: offset in frame buffer */
u32 dPitch, /* Pitch value of destination surface in BYTE */
u32 bytePerPixel, /* Color depth of destination surface */
@@ -272,9 +278,13 @@ int hw_imageblit(struct lynx_accel *accel,
u32 dy, /* Starting coordinate of destination surface */
u32 width,
u32 height, /* width and height of rectange in pixel value */
- u32 fColor, /* Foreground color (corresponding to a 1 in the
- monochrome data */
- u32 bColor, /* Background color (corresponding to a 0 in the
- monochrome data */
+ u32 fColor, /*
+ * Foreground color (corresponding to a 1 in the
+ * monochrome data
+ */
+ u32 bColor, /*
+ * Background color (corresponding to a 0 in the
+ * monochrome data
+ */
u32 rop2);
#endif
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index 43d700b..c9378e2 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -1,7 +1,7 @@
#ifndef LYNX_HELP_H__
#define LYNX_HELP_H__
-/* FIELD MACROS */
+/* FIELD MACROS */
#define _LSB(f) (0 ? f)
#define _MSB(f) (1 ? f)
#define _COUNT(f) (_MSB(f) - _LSB(f) + 1)
@@ -46,27 +46,6 @@
~ _F_MASK(reg ## _ ## field) \
)
-/* Field Macros */
-#define FIELD_START(field) (0 ? field)
-#define FIELD_END(field) (1 ? field)
-#define FIELD_SIZE(field) (1 + FIELD_END(field) - \
- FIELD_START(field))
-#define FIELD_MASK(field) (((1 << (FIELD_SIZE(field)-1)) \
- | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
- << FIELD_START(field))
-#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
- FIELD_START(field))
-#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
- FIELD_MASK(field))
-
-#define FIELD_INIT(reg, field, value) FIELD_DENORMALIZE(reg ## _ ## field, \
- reg ## _ ## field ## _ ## value)
-#define FIELD_INIT_VAL(reg, field, value) \
- (FIELD_DENORMALIZE(reg ## _ ## field, value))
-#define FIELD_VAL_SET(x, r, f, v) x = x & ~FIELD_MASK(r ## _ ## f) \
- | FIELD_DENORMALIZE(r ## _ ## f, \
- r ## _ ## f ## _ ## v)
-
#define RGB(r, g, b) \
( \
(unsigned long) (((r) << 16) | ((g) << 8) | (b)) \
--
2.1.2
^ permalink raw reply related
* Re: likely signedness bug in drm and nvidia drivers
From: Ilia Mirkin @ 2015-07-21 2:44 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-fbdev, dri-devel@lists.freedesktop.org, Tomi Valkeinen,
Ben Skeggs
In-Reply-To: <87fv4io8ug.fsf@rasmusvillemoes.dk>
I think you're right. The intent is to mask off the bits above
bits_per_pixel. So if bits_per_pixel is 24, the mask would be
0xff000000. If it's 16, then the mask would be 0xffff0000. If it's 32,
then the mask is 0.
In reality, bits_per_pixel is almost exclusively 32, which will end up
with a mask of 0 (note that the shift result is inverted at the end).
So for the majority case, there's not bug... just a useless operation.
I took a look at linux/bitops.h, and there's nothing particularly
great there. GENMASK, I guess, but it's not quite right. Just
switching to 0U should be fine there.
Now that I think about it, I believe these patches have already been
sent in the past. I also just did the grep that I did before:
$ git grep -- '~0 >>'
arch/m32r/include/asm/thread_info.h: ti->flags = (ti->flags & (~0
>> (32 - TI_FLAG_FAULT_CODE_SHIFT)))
arch/sh/include/asm/thread_info.h: ti->flags = (ti->flags & (~0
>> (32 - TI_FLAG_FAULT_CODE_SHIFT)))
drivers/gpu/drm/nouveau/nv50_fbcon.c: uint32_t mask = ~(~0 >> (32 -
info->var.bits_per_pixel));
drivers/gpu/drm/nouveau/nvc0_fbcon.c: uint32_t mask = ~(~0 >> (32 -
info->var.bits_per_pixel));
drivers/video/fbdev/nvidia/nv_accel.c: u32 fg, bg, mask = ~(~0 >> (32
- info->var.bits_per_pixel));
which shows that these are the only ones. See email with subject
"[PATCH] nvidia/noveau: Fix color mask" from June 17, 2015.
-ilia
On Mon, Jul 20, 2015 at 4:46 PM, Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> Hi,
>
> The files
>
> drivers/gpu/drm/nouveau/nv50_fbcon.c
> drivers/gpu/drm/nouveau/nvc0_fbcon.c
> drivers/video/fbdev/nvidia/nv_accel.c
>
> all contain a right-shift of ~0 (aka -1) - just grep for '~0 >>'. gcc
> always does arithmetic right shift of signed types, which means that the
> result is always -1 again [type promotion/conversion doesn't kick in
> until after the shift subexpression has been evaluated], independent of
> the second operand. I can hardly believe that is intended (the result is
> used as a mask, which thus consists of all 1s). If these are indeed
> bugs, the patch is obvious (just make the literal an unsigned 0).
>
> Rasmus
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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