* Re: [GIT PULL] On-demand device probing
From: Rob Herring @ 2015-10-23 16:34 UTC (permalink / raw)
To: Tim Bird
Cc: frowand.list@gmail.com, Greg Kroah-Hartman, Tomeu Vizoso,
Mark Brown, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <562A5602.7000208@sonymobile.com>
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent? What driver is causing long
>>> delays? Why is the long-delay-drivers not being done in their own
>>> thread? And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time. But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster.
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>> With this series I get the kernel to output to the panel in 0.5s,
>> instead of 2.8s.
>
> It's very common to want to get the display up before the
> rest of the system. So wanting to accelerate one part of the boot
> at the expense to the rest of the system is a valid use case.
> Deferred initcalls, which is out of tree primarily because it requires
> the type of manual tweaking that Tomeu describes, specifically
> addressed this issue.
Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>> http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource. But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board. So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>
> Well, I have probe order problems unrelated to boot time, that
> I solved by resorting to putting stuff into modules and loading
> them post-boot. So I'd be interested in easy solutions to managing
> boot order in mainline.
I take it that this series doesn't help those problems?
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree). But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral. (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
>
> I've been worried about DT overhead adding to boot time for a while.
Always beating up DT... ;) Yes, I'm sure there is some overhead, but
looking at bootgraph there's much longer items not related to DT (USB,
MMC and anything over I2C seem to be typical). With DT we lost most
control of the order, and at the same time we added a load of new
subsystems that are dependencies.
> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)
Exactly. That was a large part of my accepting it.
> However, when Android takes 35 seconds to boot, and most people almost never
> cold-boot your product, a few seconds of kernel time-wasting on
> cold-boot seem less important. Alas, when I started working on mobile
> phones I stopped caring much about boot time.
>
> Thus, I've never worried about the DT overhead enough to actually
> measure it, as requested by Greg. So I'll just shut up now. :-)
That would be a challenge to measure since it is distributed.
Rob
^ permalink raw reply
* [PATCH] backlight: gpio-backlight: use default-on on GPIO request
From: Stefan Agner @ 2015-10-23 23:44 UTC (permalink / raw)
To: jingoohan1, lee.jones; +Cc: linux-fbdev, linux-kernel, Stefan Agner
There are situations where the backlight should be on at boot time
(e.g. if the boot loader already turned the display on). The DT
bindings specify the "default-on" property for that purpose.
Currently, the initial state of the GPIO at request time is always
set to logical off (high or low depending on whether it is an
active high or low GPIO). Since the GPIO is requested as an output,
the GPIO will be driven low for a short period of time, which leads
to a flickering display in the above use-case.
Initialize the GPIO depending on the default-on property to be
logical on or off.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
drivers/video/backlight/gpio_backlight.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
index 5fbbc2e..1813441 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -89,6 +89,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct gpio_backlight *gbl;
struct device_node *np = pdev->dev.of_node;
+ unsigned long flags = GPIOF_DIR_OUT;
int ret;
if (!pdata && !np) {
@@ -114,9 +115,12 @@ static int gpio_backlight_probe(struct platform_device *pdev)
gbl->def_value = pdata->def_value;
}
- ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
- (gbl->active ? GPIOF_INIT_LOW
- : GPIOF_INIT_HIGH),
+ if (gbl->active)
+ flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
+ else
+ flags |= gbl->def_value ? GPIOF_INIT_LOW : GPIOF_INIT_HIGH;
+
+ ret = devm_gpio_request_one(gbl->dev, gbl->gpio, flags,
pdata ? pdata->name : "backlight");
if (ret < 0) {
dev_err(&pdev->dev, "unable to request GPIO\n");
--
2.6.2
^ permalink raw reply related
* Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Chen-Yu Tsai @ 2015-10-24 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151023165641.GB1885@excalibur.cnev.de>
On Sat, Oct 24, 2015 at 12:56 AM, Karsten Merker <merker@debian.org> wrote:
> On Fri, Oct 23, 2015 at 11:56:35PM +0800, Chen-Yu Tsai wrote:
>> On Fri, Oct 23, 2015 at 11:46 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> > On Fri, Oct 23, 2015 at 10:53 PM, Karsten Merker <merker@debian.org> wrote:
>> >> On Fri, Oct 23, 2015 at 11:50:41AM +0800, Chen-Yu Tsai wrote:
> [...]
>> >>> +/ {
>> >>> + model = "MSI Primo81 tablet";
>> >>> + compatible = "msi,primo81", "allwinner,sun6i-a31s";
>> >>> +};
> [...]
>> >>> +&i2c1 {
>> >>> + pinctrl-names = "default";
>> >>> + pinctrl-0 = <&i2c1_pins_a>;
>> >>> + status = "okay";
>> >>> +
>> >>> + ctp@5d {
>> >>> + pinctrl-names = "default";
>> >>> + pinctrl-0 = <>911_int_primo81>;
>> >>> + compatible = "goodix,gt911";
>> >>> + reg = <0x5d>;
>> >>> + interrupt-parent = <&pio>;
>> >>> + interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
>> >>
>> >> I'd like to add a
>> >>
>> >> touchscreen-swapped-x-y = "true";
>> >>
>> >> as described in
>> >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
>> >> here, as the display is in portrait mode while the touchscreen is
>> >> in landscape mode and needs to have the x and y axes swapped to
>> >> work in the same coordinate system as the display.
>> >>
>> >> Regarding the driver side: the goodix driver in kernel 4.3
>> >> doesn't yet support this property, but patches to add support for
>> >> it are on the linux-input list and should hopefully make it into
>> >> kernel 4.4.
>> >
>> > The DTS is already in Maxime's tree, and in sunxi-next. Feel free to
>> > send a follow-up patch adding them. I was waiting for those patches
>> > to be merged.
>>
>> Sorry, spoke too soon. Maxime hasn't pushed it out yet. Could you send
>> a patch adding touchscreen-swapped-x-y for Maxime to squash in?
>
> I'm happy to do so, but I have just stumbled over a problem with
> actually building the dtb for testing - it fails with
>
> arch/arm/boot/dts/sun6i-a31s-primo81.dts:242.1-14 Label or path simplefb_lcd not found
>
> The dts references simplefb_lcd:
>
> +&simplefb_lcd {
> + vcc-lcd-supply = <®_dc1sw>;
> + vdd-mipi-bridge-supply = <®_eldo3>;
> +};
>
> but I don't see where it would be defined. This is on the current
> sunxi/for-next branch of
> https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git
> with the Primo81 dts patch on top. Am I perhaps missing some
> required additional patch here?
Yes. The previous patch that adds labels to the simplefb nodes.
Both patches are now in sunxi/for-next in Maxime's tree now.
ChenYu
^ permalink raw reply
* Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Maxime Ripard @ 2015-10-24 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64xESxh0Dzsh9GijYZADbB-SM99ZVtu=9FGB2Gfz2-Z6Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
Hi,
On Fri, Oct 23, 2015 at 11:56:35PM +0800, Chen-Yu Tsai wrote:
> >> as described in
> >> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
> >> here, as the display is in portrait mode while the touchscreen is
> >> in landscape mode and needs to have the x and y axes swapped to
> >> work in the same coordinate system as the display.
> >>
> >> Regarding the driver side: the goodix driver in kernel 4.3
> >> doesn't yet support this property, but patches to add support for
> >> it are on the linux-input list and should hopefully make it into
> >> kernel 4.4.
> >
> > The DTS is already in Maxime's tree, and in sunxi-next. Feel free to
> > send a follow-up patch adding them. I was waiting for those patches
> > to be merged.
>
> Sorry, spoke too soon. Maxime hasn't pushed it out yet. Could you send
> a patch adding touchscreen-swapped-x-y for Maxime to squash in?
I did the last DT pull request for 4.4 yesterday, so I won't squash
any patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Siarhei Siamashka @ 2015-10-24 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67HO5isvUxG09traLUBrBp-0Bea9cXn_O0oqBCTYtfN=w@mail.gmail.com>
Hello,
On Fri, 23 Oct 2015 23:46:59 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Fri, Oct 23, 2015 at 10:53 PM, Karsten Merker <merker@debian.org> wrote:
> > On Fri, Oct 23, 2015 at 11:50:41AM +0800, Chen-Yu Tsai wrote:
> >
> >> From: Karsten Merker <merker@debian.org>
> >>
> >> The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
> >> 768x1024 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
> >> rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
> >> and rtl8188etv usb wifi. Has "power", "volume+" and "volume-" buttons
> >> (both volume buttons are also connected to the UBOOT_SEL pin). The
> >
> > Hello Chen-Yu,
> >
> > the volume button function is something that I wanted to confirm
> > again but forgot to ask previously: Siarhei had pointed out that
> > only the volume+ button triggers UBOOT_SEL, but for me actually
> > both volume buttons work as described above. Could you
> > cross-check that on your Primo81?
>
> IIRC both work. I can test next week.
Both buttons work this way because the Allwinner's firmware
additionally checks the buttons state via LRADC and switches
into the FEL mode in a software way. But if somebody flashes a
broken bootloader to NAND (something that is recognized by the
BROM, but dies instead of booting) then we may potentially have
a bricked device because booting from NAND has the highest
priority on A31s.
The UBOOT_SEL pin on the SoC can be used to change the default
boot order and allow to boot from the SD card or USB first
regardless of what is in NAND. So if at least one of the hardware
buttons is connected to the UBOOT_SEL pin, then we have an
unbrickable device.
Checking whether the hardware button is really connected to the
UBOOT_SEL pin can be done by reading the SRAM_VER_REG hardware
register and looking at the BOOT_SEL_PAD_STA bits:
http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
And this can be done, for example, via using the devmem2 tool:
"devmem2 0x01c00024"
Alternatively, it is also possible to use a modified variant of the
dialog tool, which is additionally polling the state of the FEL
button and interpreting long FEL button press as KEY_ENTER and
short press as KEY_DOWN:
https://github.com/ssvb/dialog-sunxi
This patched dialog tool is a part of the board type selection stub,
used for creating universal board-independent SD card based installers
for Allwinner devices, which has been available for Linux distribution
maintainers since a while ago:
http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
Regarding the UBOOT_SEL pin in the MSI Primo81 tablet. After
buying this tablet, I was happy to confirm that at least the
"volume+" button is connected to the UBOOT_SEL pin, making the
tablet unbrickable. However appears that it was not just some sane
decision made by MSI engineers, but in fact connecting both LRADC
and UBOOT_SEL to tablet buttons is a part of the standard Allwinner's
reference schematics. One can search for "a20_pad_std_v1_1.pdf",
"a13-sch.pdf", "A31_PAD_STD_V1_90_130225.pdf" documents on the
Internet to find this information. Basically, we should expect
the majority of Allwinner A31(s) tablets to have a hardware FEL
button and be perfectly unbrickable :-)
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-24 13:48 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman
Cc: Tim Bird, frowand.list@gmail.com, Tomeu Vizoso, Mark Brown,
Russell King, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse
In-Reply-To: <CAL_JsqLNSM=+j2r9HPcbSzsZrgnGEY3=kv21EXxisKwP5+57ag@mail.gmail.com>
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> <oops, sent too early...>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>>> But that's moot currently because Greg believes that the time spent
> >>>> probing devices at boot time could be reduced enough so that the order
> >>>> in which devices are probed becomes irrelevant. IME that would have to
> >>>> be under 200ms so that the user doesn't notice and that's unicorn-far
> >>>> from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent? What driver is causing long
> >>> delays? Why is the long-delay-drivers not being done in their own
> >>> thread? And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
> >>>> Given that downstreams are already carrying as many hacks as they
> >>>> could think of to speed total boot up, I think this is effectively
> >>>> telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time. But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >> With this series I get the kernel to output to the panel in 0.5s,
> >> instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system. So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
>
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).
Well, I'm not quite sure why exactly everyone is so focused on probing here.
Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary. And this is not limited
to probing, as I have already said for a few times. Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.
If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.
Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.
So perhaps it's better to start discussing about a solution for the general
issue?
Thanks,
Rafael
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Geert Uytterhoeven @ 2015-10-24 17:55 UTC (permalink / raw)
To: Frank Rowand
Cc: Greg Kroah-Hartman, Tomeu Vizoso, Rob Herring, Mark Brown,
Russell King, Michael Turquette, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood
In-Reply-To: <562930AB.1070203@gmail.com>
On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree). But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral. (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)
Yep, once in a while people still stumble on obscure subsystems and drivers
not supporting probe deferral. Usually they don't fail with a big bang, so
everything seems fine.
E.g. last week's "of_mdiobus_register_phy() and deferred probe"
(https://lkml.org/lkml/2015/10/22/377).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property
From: Karsten Merker @ 2015-10-24 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151024205716.GA16644@excalibur.cnev.de>
The MSI Primo81 has a display in portrait mode but a touchscreen
in landscape mode. To have both of them use the same coordinate
system, the touchscreen-swapped-x-y property has to be set
for the touchscreen.
Signed-off-by: Karsten Merker <merker@debian.org>
---
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
index 2d4250b..68b479b 100644
--- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -83,6 +83,7 @@
reg = <0x5d>;
interrupt-parent = <&pio>;
interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
+ touchscreen-swapped-x-y;
};
};
--
2.1.4
^ permalink raw reply related
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-24 22:06 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rob Herring, Greg Kroah-Hartman, Tim Bird, frowand.list@gmail.com,
Tomeu Vizoso, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <24100858.2KIS8Y2npV@vostro.rjw.lan>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> Well, I'm not quite sure why exactly everyone is so focused on probing here.
Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.
There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-25 13:54 UTC (permalink / raw)
To: Mark Brown
Cc: Rafael J. Wysocki, Rob Herring, Greg Kroah-Hartman, Tim Bird,
frowand.list@gmail.com, Tomeu Vizoso, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel
In-Reply-To: <20151024220648.GR29919@sirena.org.uk>
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine on a given
> system so it's constantly being highlighted to people in a way that
> other issues aren't if you're not directly having problems.
>
> There's also the understanding people had that the order things get
> bound changes the ordering for some of the other cases (perhaps it's a
> good idea to do that, it seems likely to be sensible?).
But it really doesn't do that. Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).
If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe. That should help to reduce the
noise you're referring to.
If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.
Thanks,
Rafael
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Andrew F. Davis @ 2015-10-25 19:45 UTC (permalink / raw)
To: Tim Bird, frowand.list@gmail.com, Greg Kroah-Hartman
Cc: Tomeu Vizoso, Rob Herring, Mark Brown, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, Liam Girdwood,
Felipe Balbi
In-Reply-To: <562A5602.7000208@sonymobile.com>
On 10/23/2015 10:45 AM, Tim Bird wrote:
> I've been worried about DT overhead adding to boot time for a while.
> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)
>
It has a bogosort kind of elegance. :)
Also this might be a silly question (I haven't been following this issue
for very long), but as the only place that can really know what devices
depend on each other, in a generic kernel, is the DT (or whatever
abstraction) will we not eventually need to solve this issue there? Could
we just add a "depends-on = <&phandle>;" to nodes when we know they are
needed for our board?
^ permalink raw reply
* [PATCH] fbdev: Make fb-notify a no-op if CONFIG_FB=n
From: Ezequiel Garcia @ 2015-10-25 22:59 UTC (permalink / raw)
To: linux-fbdev
There's no point in having support for framebuffer notifications
is CONFIG_FB is disabled. This commit adds the necessary stubs
for code to link properly when CONFIG_FB=n and moves fb-notify.o
to be built only when CONFIG_FB=y.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
---
drivers/video/fbdev/Kconfig | 4 ++++
drivers/video/fbdev/core/Makefile | 2 +-
include/linux/fb.h | 18 ++++++++++++++++++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8b1d371b5404..031063223698 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -5,6 +5,7 @@
menuconfig FB
tristate "Support for frame buffer devices"
select FB_CMDLINE
+ select FB_NOTIFY
---help---
The frame buffer device provides an abstraction for the graphics
hardware. It represents the frame buffer of some video hardware and
@@ -56,6 +57,9 @@ config FIRMWARE_EDID
config FB_CMDLINE
bool
+config FB_NOTIFY
+ bool
+
config FB_DDC
tristate
depends on FB
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 23d86a8b7d7b..9e3ddf225393 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,5 +1,5 @@
-obj-y += fb_notify.o
obj-$(CONFIG_FB_CMDLINE) += fb_cmdline.o
+obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
diff --git a/include/linux/fb.h b/include/linux/fb.h
index bc9afa74ee11..760fb956a00f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -175,9 +175,27 @@ struct fb_blit_caps {
u32 flags;
};
+#ifdef CONFIG_FB_NOTIFY
extern int fb_register_client(struct notifier_block *nb);
extern int fb_unregister_client(struct notifier_block *nb);
extern int fb_notifier_call_chain(unsigned long val, void *v);
+#else
+static inline int fb_register_client(struct notifier_block *nb)
+{
+ return 0;
+};
+
+static inline int fb_unregister_client(struct notifier_block *nb)
+{
+ return 0;
+};
+
+static inline int fb_notifier_call_chain(unsigned long val, void *v)
+{
+ return 0;
+};
+#endif
+
/*
* Pixmap structure definition
*
--
2.5.2
^ permalink raw reply related
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-26 1:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Rob Herring, Greg Kroah-Hartman, Tim Bird,
frowand.list@gmail.com, Tomeu Vizoso, Russell King,
Michael Turquette, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel
In-Reply-To: <CAJZ5v0hPVu7AL8zBdU4Kb7+MVfYv0mTa43RhnCyyPR+RKDbhLA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
> But it really doesn't do that. Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
Yeah, people seem to have that impression though. :(
> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe. That should help to reduce the
> noise you're referring to.
This links back to the idea of having generic support for pre-probe
actions which is also generally useful (the ability to do things like
power on regulators for devices on enumerable buses so they can be
enumerated as standard).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Michael Turquette @ 2015-10-26 10:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Mark Brown
Cc: Rafael J. Wysocki, Rob Herring, Greg Kroah-Hartman, Tim Bird,
frowand.list@gmail.com, Tomeu Vizoso, Russell King, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel
In-Reply-To: <CAJZ5v0hPVu7AL8zBdU4Kb7+MVfYv0mTa43RhnCyyPR+RKDbhLA@mail.gmail.com>
Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
> >
> > Probe deferral is really noisy even if it's working fine on a given
> > system so it's constantly being highlighted to people in a way that
> > other issues aren't if you're not directly having problems.
> >
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
>
> But it really doesn't do that. Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
>
> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe. That should help to reduce the
> noise you're referring to.
Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.
Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.
Regards,
Mike
>
> If the dependency could only be discovered at the probe time, the
> order of things might be changed in response to letting the driver
> core know about it rather than "just in case", which should be more
> efficient.
>
> Thanks,
> Rafael
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Tomeu Vizoso @ 2015-10-26 12:55 UTC (permalink / raw)
To: Michael Turquette
Cc: Rafael J. Wysocki, Mark Brown, Rafael J. Wysocki, Rob Herring,
Greg Kroah-Hartman, Tim Bird, frowand.list@gmail.com,
Russell King, Stephen Boyd, Vinod Koul, Dan Williams,
Linus Walleij, Alexandre Courbot, Thierry Reding, David Airlie,
Terje Bergström, Stephen Warren, Wolfram Sang, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel
In-Reply-To: <20151026105138.20687.13546@quantum>
On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that. Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe. That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.
Alexander Holler has been looking at that for some time already.
Regards,
Tomeu
> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [RESEND PATCH v2] backlight: pm8941-wled: Add default-brightness property
From: Bjorn Andersson @ 2015-10-26 17:45 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
Default the brightness to 2048 and add possibility to override this in
device tree.
Suggested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
Resend of v2, with updated backlight dt binding location.
Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt | 2 ++
drivers/video/backlight/pm8941-wled.c | 8 ++++++++
2 files changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
index 424f8444a6cd..e5b294dafc58 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
@@ -5,6 +5,8 @@ Required properties:
- reg: slave address
Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+ default: 2048
- 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..e1298147bcbb 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -17,6 +17,9 @@
#include <linux/of_device.h>
#include <linux/regmap.h>
+/* From DT binding */
+#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
+
#define PM8941_WLED_REG_VAL_BASE 0x40
#define PM8941_WLED_REG_VAL_MAX 0xFFF
@@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+ u32 val;
int rc;
regmap = dev_get_regmap(pdev->dev.parent, NULL);
@@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
+ val = PM8941_WLED_DEFAULT_BRIGHTNESS;
+ 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,
--
2.4.2
^ permalink raw reply related
* [PATCH] backlight: pm8941-wled: fix ptr_ret.cocci warnings
From: kbuild test robot @ 2015-10-26 18:26 UTC (permalink / raw)
To: Bjorn Andersson
Cc: kbuild-all, linux-kernel, Lee Jones, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <201510270209.ZSHdZKp5%fengguang.wu@intel.com>
drivers/video/backlight/pm8941-wled.c:404:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
CC: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
pm8941-wled.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -401,10 +401,7 @@ static int pm8941_wled_probe(struct plat
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;
+ return PTR_ERR_OR_ZERO(bl);
};
static const struct of_device_id pm8941_wled_match_table[] = {
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: fix ptr_ret.cocci warnings
From: Bjorn Andersson @ 2015-10-26 18:33 UTC (permalink / raw)
To: kbuild test robot
Cc: Bjorn Andersson, kbuild-all, linux-kernel@vger.kernel.org,
Lee Jones, Jingoo Han, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20151026182611.GA14761@roam>
On Mon, Oct 26, 2015 at 11:26 AM, kbuild test robot
<fengguang.wu@intel.com> wrote:
> drivers/video/backlight/pm8941-wled.c:404:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
Cool, I didn't know that. Thanks
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Regards,
Bjorn
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-26 23:37 UTC (permalink / raw)
To: Michael Turquette
Cc: Rafael J. Wysocki, Mark Brown, Rafael J. Wysocki, Rob Herring,
Greg Kroah-Hartman, Tim Bird, frowand.list@gmail.com,
Tomeu Vizoso, Russell King, Stephen Boyd, Vinod Koul,
Dan Williams, Linus Walleij, Alexandre Courbot, Thierry Reding,
David Airlie, Terje Bergström, Stephen Warren, Wolfram Sang,
Grant Likely, Kishon Vijay Abraham I, Sebastian Reichel
In-Reply-To: <20151026105138.20687.13546@quantum>
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that. Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe. That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
Do you mean the kernel link time or something else?
At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.
That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.
Thanks,
Rafael
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Rafael J. Wysocki @ 2015-10-27 4:35 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Brown, Rob Herring, David Woodhouse, Greg Kroah-Hartman,
Tomeu Vizoso, Russell King, Michael Turquette, Stephen Boyd,
Vinod Koul, Dan Williams, Linus Walleij, Alexandre Courbot,
Thierry Reding, David Airlie, Terje Bergström,
Stephen Warren, Wolfram Sang, Frank Rowand, Grant Likely,
Kishon Vijay Abraham I, Sebastian Reichel,
Dmitry Eremin-Solenikov
In-Reply-To: <Pine.LNX.4.44L0.1510201159400.1855-100000@iolanthe.rowland.org>
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >
> > > Furthermore, that applies only to devices that use synchronous suspend.
> > > Async suspend is becoming common, and there the only restrictions are
> > > parent-child relations plus whatever explicit requirements that drivers
> > > impose by calling device_pm_wait_for_dev().
> >
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
> > It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> >
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.
Well, good point. :-)
I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized. It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.
Thanks,
Rafael
^ permalink raw reply
* Re: [RESEND PATCH v2] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring @ 2015-10-27 7:45 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Rob Clark,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm
In-Reply-To: <1445881508-18025-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
On Mon, Oct 26, 2015 at 12:45 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> Default the brightness to 2048 and add possibility to override this in
> device tree.
>
> Suggested-by: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
>
> Resend of v2, with updated backlight dt binding location.
Acked-by: Rob Herring <robh@kernel.org>
>
> Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt | 2 ++
> drivers/video/backlight/pm8941-wled.c | 8 ++++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> index 424f8444a6cd..e5b294dafc58 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> @@ -5,6 +5,8 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> + default: 2048
> - 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..e1298147bcbb 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -17,6 +17,9 @@
> #include <linux/of_device.h>
> #include <linux/regmap.h>
>
> +/* From DT binding */
> +#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
> +
> #define PM8941_WLED_REG_VAL_BASE 0x40
> #define PM8941_WLED_REG_VAL_MAX 0xFFF
>
> @@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> + u32 val;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> + val = PM8941_WLED_DEFAULT_BRIGHTNESS;
> + 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,
> --
> 2.4.2
>
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: fix ptr_ret.cocci warnings
From: Lee Jones @ 2015-10-27 8:39 UTC (permalink / raw)
To: kbuild test robot
Cc: Bjorn Andersson, kbuild-all, linux-kernel, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <20151026182611.GA14761@roam>
On Tue, 27 Oct 2015, kbuild test robot wrote:
> drivers/video/backlight/pm8941-wled.c:404:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> CC: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
>
> pm8941-wled.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
Applied, thanks.
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -401,10 +401,7 @@ static int pm8941_wled_probe(struct plat
> 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;
> + return PTR_ERR_OR_ZERO(bl);
> };
>
> static const struct of_device_id pm8941_wled_match_table[] = {
--
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] ARM: dts: sunxi: sun6i-a31s-primo81.dts: add touchscreen axis swapping property
From: Maxime Ripard @ 2015-10-28 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445720851-2148-1-git-send-email-merker@debian.org>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi,
On Sat, Oct 24, 2015 at 11:07:31PM +0200, Karsten Merker wrote:
> The MSI Primo81 has a display in portrait mode but a touchscreen
> in landscape mode. To have both of them use the same coordinate
> system, the touchscreen-swapped-x-y property has to be set
> for the touchscreen.
>
> Signed-off-by: Karsten Merker <merker@debian.org>
Queued as a fix for 4.4.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: Philipp Zabel @ 2015-10-29 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445526750.27586.8.camel@mtksdaap41>
Hi YH,
Am Donnerstag, den 22.10.2015, 23:12 +0800 schrieb YH Huang:
> In the case of the panel disabled by the bootloader,
> your patch still has the following code and always enables the backlight
> in the probe function.
> pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> - GPIOD_OUT_HIGH);
You are right.
> What do you think if I remove these two lines in my patch?
> if (pb->enable_gpio)
> gpiod_direction_output(pb->enable_gpio, 0);
That won't work if the gpio is still configured as input. How about I
add the GPIOD_ASIS change to my patch you remove that and the above from
yours?
best regards
Philipp
^ permalink raw reply
* [PATCH] pwm-backlight: Avoid backlight flicker when probed from DT
From: Philipp Zabel @ 2015-10-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434126377-22545-1-git-send-email-p.zabel@pengutronix.de>
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backlight at the appropriate time.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
---
Changes since v2:
- Leave GPIO configuration as is (GPIOD_ASIS) when requesting,
so we can actually check the initial state.
---
drivers/video/backlight/pwm_bl.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index ae3c6b6..8e9c261 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -199,6 +199,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ int initial_blank = FB_BLANK_UNBLANK;
+ bool phandle;
int ret;
if (!data) {
@@ -242,7 +244,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enabled = false;
pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
- GPIOD_OUT_HIGH);
+ GPIOD_ASIS);
if (IS_ERR(pb->enable_gpio)) {
ret = PTR_ERR(pb->enable_gpio);
goto err_alloc;
@@ -264,12 +266,32 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enable_gpio = gpio_to_desc(data->enable_gpio);
}
+ phandle = of_find_property(pdev->dev.of_node, "phandle", NULL) != NULL;
+
+ if (pb->enable_gpio) {
+ /*
+ * If the driver is probed from the device tree and there is a
+ * phandle link pointing to the backlight node, it is safe to
+ * assume that another driver will enable the backlight at the
+ * appropriate time. Therefore, if it is disabled, keep it so.
+ */
+ if (phandle &&
+ gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
+ gpiod_get_value(pb->enable_gpio) = 0)
+ initial_blank = FB_BLANK_POWERDOWN;
+ else
+ gpiod_direction_output(pb->enable_gpio, 1);
+ }
+
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
ret = PTR_ERR(pb->power_supply);
goto err_alloc;
}
+ if (phandle && !regulator_is_enabled(pb->power_supply))
+ initial_blank = FB_BLANK_POWERDOWN;
+
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm) && PTR_ERR(pb->pwm) != -EPROBE_DEFER
&& !pdev->dev.of_node) {
@@ -320,6 +342,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
bl->props.brightness = data->dft_brightness;
+ bl->props.power = initial_blank;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.6.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox