* 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
* 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 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] 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 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: 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: 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: [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] 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: 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
* [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] 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
* 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 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 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] 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
* [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 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
* 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] backlight: pm8941-wled: Add default-brightness property
From: Rob Clark @ 2015-07-24 13:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Linux Fbdev development list,
linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> 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 +
> 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;
as discussed on IRC, it would be better if the default read back the
current settings (so-as to inherit bootloader splash smoothly..
drm/msm supports a memory-region phandle, for example, so it can take
over the bootloader splash-screen as stolen-mem)
and it would I think be useful to have a comment in the bindings file
explaining that you *should* use the default-brightness property to
set a sane default if bootloader isn't putting up a splash, and you
should *not* use the property if it is..
BR,
-R
> 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
* [PATCH] ARM/fb: ep93xx: switch framebuffer to use modedb only
From: Linus Walleij @ 2015-07-24 13:31 UTC (permalink / raw)
To: linux-arm-kernel
All the EP93xx boards exclusively use modedb to look up video
modes from the command line. Root out the parametrization of
custom video modes from the platform data and board files
and simplify the driver.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
J-C/Tomi: please ACK this if you're OK with it so I can take
it through the ARM SoC tree.
---
arch/arm/mach-ep93xx/edb93xx.c | 2 --
arch/arm/mach-ep93xx/simone.c | 2 --
arch/arm/mach-ep93xx/snappercl15.c | 2 --
arch/arm/mach-ep93xx/vision_ep9307.c | 2 --
drivers/video/fbdev/ep93xx-fb.c | 30 ++++--------------------------
include/linux/platform_data/video-ep93xx.h | 8 --------
6 files changed, 4 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 27b14ae92c7e..ad92d9f7e4df 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -205,8 +205,6 @@ static void __init edb93xx_register_pwm(void)
* EDB93xx framebuffer
*************************************************************************/
static struct ep93xxfb_mach_info __initdata edb93xxfb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = 0,
};
diff --git a/arch/arm/mach-ep93xx/simone.c b/arch/arm/mach-ep93xx/simone.c
index d0938a219443..7bb540c421ee 100644
--- a/arch/arm/mach-ep93xx/simone.c
+++ b/arch/arm/mach-ep93xx/simone.c
@@ -40,8 +40,6 @@ static struct ep93xx_eth_data __initdata simone_eth_data = {
};
static struct ep93xxfb_mach_info __initdata simone_fb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = EP93XXFB_USE_SDCSN0 | EP93XXFB_PCLK_FALLING,
};
diff --git a/arch/arm/mach-ep93xx/snappercl15.c b/arch/arm/mach-ep93xx/snappercl15.c
index aa86f86638dd..c4904264256a 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -144,8 +144,6 @@ static struct i2c_board_info __initdata snappercl15_i2c_data[] = {
};
static struct ep93xxfb_mach_info __initdata snappercl15_fb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
};
static struct platform_device snappercl15_audio_device = {
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index ff22a6a6e2bf..5cced5988498 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -106,8 +106,6 @@ static void vision_lcd_blank(int blank_mode, struct fb_info *info)
}
static struct ep93xxfb_mach_info ep93xxfb_info __initdata = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = EP93XXFB_USE_SDCSN0 | EP93XXFB_PCLK_FALLING,
.setup = vision_lcd_setup,
.teardown = vision_lcd_teardown,
diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c
index 7ec251cc9c03..5b1081030cbb 100644
--- a/drivers/video/fbdev/ep93xx-fb.c
+++ b/drivers/video/fbdev/ep93xx-fb.c
@@ -419,36 +419,15 @@ static struct fb_ops ep93xxfb_ops = {
.fb_mmap = ep93xxfb_mmap,
};
-static int ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
-{
- int i, fb_size = 0;
-
- if (mach_info->num_modes = EP93XXFB_USE_MODEDB) {
- fb_size = EP93XXFB_MAX_XRES * EP93XXFB_MAX_YRES *
- mach_info->bpp / 8;
- } else {
- for (i = 0; i < mach_info->num_modes; i++) {
- const struct fb_videomode *mode;
- int size;
-
- mode = &mach_info->modes[i];
- size = mode->xres * mode->yres * mach_info->bpp / 8;
- if (size > fb_size)
- fb_size = size;
- }
- }
-
- return fb_size;
-}
-
static int ep93xxfb_alloc_videomem(struct fb_info *info)
{
- struct ep93xx_fbi *fbi = info->par;
char __iomem *virt_addr;
dma_addr_t phys_addr;
unsigned int fb_size;
- fb_size = ep93xxfb_calc_fbsize(fbi->mach_info);
+ /* Maximum 16bpp -> used memory is maximum x*y*2 bytes */
+ fb_size = EP93XXFB_MAX_XRES * EP93XXFB_MAX_YRES * 2;
+
virt_addr = dma_alloc_writecombine(info->dev, fb_size,
&phys_addr, GFP_KERNEL);
if (!virt_addr)
@@ -550,8 +529,7 @@ static int ep93xxfb_probe(struct platform_device *pdev)
fb_get_options("ep93xx-fb", &video_mode);
err = fb_find_mode(&info->var, info, video_mode,
- fbi->mach_info->modes, fbi->mach_info->num_modes,
- fbi->mach_info->default_mode, fbi->mach_info->bpp);
+ NULL, 0, NULL, 16);
if (err = 0) {
dev_err(info->dev, "No suitable video mode found\n");
err = -EINVAL;
diff --git a/include/linux/platform_data/video-ep93xx.h b/include/linux/platform_data/video-ep93xx.h
index 92fc2b2232e7..699ac4109366 100644
--- a/include/linux/platform_data/video-ep93xx.h
+++ b/include/linux/platform_data/video-ep93xx.h
@@ -2,11 +2,8 @@
#define __VIDEO_EP93XX_H
struct platform_device;
-struct fb_videomode;
struct fb_info;
-#define EP93XXFB_USE_MODEDB 0
-
/* VideoAttributes flags */
#define EP93XXFB_STATE_MACHINE_ENABLE (1 << 0)
#define EP93XXFB_PIXEL_CLOCK_ENABLE (1 << 1)
@@ -38,12 +35,7 @@ struct fb_info;
EP93XXFB_PIXEL_DATA_ENABLE)
struct ep93xxfb_mach_info {
- unsigned int num_modes;
- const struct fb_videomode *modes;
- const struct fb_videomode *default_mode;
- int bpp;
unsigned int flags;
-
int (*setup)(struct platform_device *pdev);
void (*teardown)(struct platform_device *pdev);
void (*blank)(int blank_mode, struct fb_info *info);
--
2.4.3
^ permalink raw reply related
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring @ 2015-07-24 15:29 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Rob Clark, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson@sonymobile.com>
On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> 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,".
Well, we have "default-brightness" and "default-brightness-level" used
by 1 driver each. But default-brightness-level is much more commonly
used (in dts files) since it is in the pwm backlight binding, so we
should go with it. I'd like to see this moved to a common backlight
doc.
Really, I think all the backlight documentation should be merged with
LEDs docs. Things like "default-on" are common. But I won't ask to do
that here.
Rob
>
> [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
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring @ 2015-07-24 15:39 UTC (permalink / raw)
To: Rob Clark
Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, Linux Kernel Mailing List,
Linux Fbdev development list, linux-arm-msm
In-Reply-To: <CAF6AEGsJdLYzCA_=M8hf1XfhRxFAaY6VFdSBRP+y56uKsnQHiA@mail.gmail.com>
On Fri, Jul 24, 2015 at 8:10 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
> <bjorn.andersson@sonymobile.com> 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 +
>> 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;
>
> as discussed on IRC, it would be better if the default read back the
> current settings (so-as to inherit bootloader splash smoothly..
> drm/msm supports a memory-region phandle, for example, so it can take
> over the bootloader splash-screen as stolen-mem)
>
> and it would I think be useful to have a comment in the bindings file
> explaining that you *should* use the default-brightness property to
> set a sane default if bootloader isn't putting up a splash, and you
> should *not* use the property if it is..
+1
What if you have neither? Set to max brightness? 75%?
This could also be used for the bootloader to communicate to the
kernel what the current level is if it is not readable. I've seen one
backlight recently which you change the level by doing some number of
pulses on a gpio and a long pulse to turn off. So there is no way to
know current level without turning off the backlight (unless you
hardcode the bootloader's level in the kernel like the vendor did).
Rob
^ permalink raw reply
* omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-07-24 16:03 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
[-- Attachment #1: Type: Text/Plain, Size: 3242 bytes --]
Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above
commands and on Nokia's 2.6.28 kernel there is no crash or error message.
IMHO Division by zero in kernel should not be there even if userspace
call "incorrect" command.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH] ARM/fb: ep93xx: switch framebuffer to use modedb only
From: Hartley Sweeten @ 2015-07-24 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1437744688-29915-1-git-send-email-linus.walleij@linaro.org>
On Friday, July 24, 2015 6:31 AM, Linus Walleij wrote:
> All the EP93xx boards exclusively use modedb to look up video
> modes from the command line. Root out the parametrization of
> custom video modes from the platform data and board files
> and simplify the driver.
>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox