* Re: [GIT PULL] On-demand device probing
From: Russell King - ARM Linux @ 2015-10-22 15:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tomeu Vizoso, Frank Rowand, Rob Herring, Mark Brown,
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: <20151022144405.GC21861-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > 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.
+100000000000, fully agree.
There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear. So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.
If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem. I think the fact is, there is no data.
Someone prove me wrong. Someone post the verifiable data showing that
there is a problem to be solved here.
Someone show what the specific failure cases are that are hampering
vendors moving forwards. Someone show the long boot times by way of
kernel message log. Someone show some evidence of the problems that
have been alluded to.
If no one can show some evidence, there isn't a problem here. :)
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v2] pwm-backlight: fix the panel power sequence
From: YH Huang @ 2015-10-22 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1444988219.3541.3.camel@pengutronix.de>
On Fri, 2015-10-16 at 11:36 +0200, Philipp Zabel wrote:
> Am Freitag, den 16.10.2015, 17:17 +0800 schrieb YH Huang:
> > In order to match the panel power sequence, disable the enable_gpio
> > in the probe function. Also, reorder the code in the power_on and
> > power_off function to match the timing.
>
> Could you also have a look at the "pwm-backlight: Avoid backlight
> flicker when probed from DT" patch?
> I think in case of a panel left enabled by the bootloader, your patch
> will disable the backlight for a short time.
>
> best regards
> Philipp
>
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);
What do you think if I remove these two lines in my patch?
if (pb->enable_gpio)
gpiod_direction_output(pb->enable_gpio, 0);
Regards,
YH Huang
^ permalink raw reply
* Re: Alternative approach to solve the deferred probe
From: Grygorii Strashko @ 2015-10-22 15:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: frowand.list, Geert Uytterhoeven, Tomeu Vizoso, Mark Brown,
Greg Kroah-Hartman, Rob Herring, 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: <20151021182817.GM32532@n2100.arm.linux.org.uk>
Hi Russell,
On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
>
> Then you haven't properly understood my proposal.
>
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
>
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
>
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
>
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
>
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals. That's _got_ to be an improvement.
Sorry Master, but you really don't need to spend so much time typing the
same things three times - I understand what are you trying to do :(
I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.
Sorry for your time.
>
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> int level;
>>
>> for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> do_initcall_level(level);
>>
>> + wait_for_device_probe();
>> + /* Now one final round, reporting any devices that remain deferred */
>> + driver_deferred_probe_report = true;
>> + driver_deferred_probe_trigger();
>> + wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
>
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
>
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
>
Also, I've spend some time today testing your proposal - hope you'll find results
useful.
I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading.
My Changes:
- only really_probe() modified to show deferred device/drivers
From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.
So, as you've mentioned, it seems a good thing to deactivate driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).
I've found no issues during Kernel boot (built-in) time, new messages are displayed only
if probe is failed for some drivers:
[ 3.219700] =================== deferred_probe_initcalll
[ 3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[ 3.233378] platform omapdrm.0: deferring probe: == Driver omapdrm requests probe deferral
[ 3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[ 3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[ 3.256168] platform encoder@1: deferring probe: == Driver dra7evm-tpd12s015 requests probe deferral
[ 3.265763] connector-hdmi connector@1: failed to find video source
[ 3.272067] platform connector@1: Driver connector-hdmi requests probe deferral
[ 3.279410] platform connector@1: deferring probe: == Driver connector-hdmi requests probe deferral
^^ above drivers will be deferred forever
Thanks.
--
regards,
-grygorii
S/ILKP
*************** [TEST CODE] ***********
---
drivers/base/dd.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e7d2545..d61fa47 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,6 +129,27 @@ void driver_deferred_probe_del(struct device *dev)
mutex_unlock(&deferred_probe_mutex);
}
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+ if (driver_deferred_probe_report) {
+ struct va_format vaf;
+ va_list ap;
+
+ va_start(ap, fmt);
+ vaf.fmt = fmt;
+ vaf.va = ≈
+
+ dev_err(dev, "deferring probe: %pV", &vaf);
+ va_end(ap);
+ }
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
static bool driver_deferred_probe_enable = false;
/**
* driver_deferred_probe_trigger() - Kick off re-probing deferred devices
@@ -188,6 +209,15 @@ static int deferred_probe_initcall(void)
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
flush_workqueue(deferred_wq);
+
+ pr_err("=================== deferred_probe_initcalll\n");
+
+ /* Now one final round, reporting any devices that remain deferred */
+ driver_deferred_probe_report = true;
+ driver_deferred_probe_trigger();
+ /* Sort as many dependencies as possible before exiting initcalls */
+ flush_workqueue(deferred_wq);
+
return 0;
}
late_initcall(deferred_probe_initcall);
@@ -342,7 +372,8 @@ probe_failed:
switch (ret) {
case -EPROBE_DEFER:
/* Driver requested deferred probing */
- dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+ dev_err(dev, "Driver %s requests probe deferral\n", drv->name);
+ dev_warn_deferred(dev, "== Driver %s requests probe deferral\n", drv->name);
driver_deferred_probe_add(dev);
/* Did a trigger occur while probing? Need to re-trigger if yes */
if (local_trigger_count != atomic_read(&deferred_trigger_count))
--
2.6.2
*************** [BOOT LOG] ***********
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.1.10-rt10-02639-gd63d0be-dirty (lcpdbld@dflsdit-build06.dal.design.ti.com) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.05) ) #1 SMP PREEMPT RT Thu Oct 22 05:11:58 CDT 2015
[ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr\x10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] Machine model: TI DRA742
[ 0.000000] Reserved memory: created CMA memory pool at 0x95800000, size 56 MiB
[ 0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x99000000, size 64 MiB
[ 0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x9d000000, size 32 MiB
[ 0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x9f000000, size 8 MiB
[ 0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[ 0.000000] cma: Reserved 24 MiB at 0xde000000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] DRA752 ES1.1
[ 0.000000] PERCPU: Embedded 12 pages/cpu @ee9af000 s17792 r8192 d23168 u49152
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 390994
[ 0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk rootwait ip=:::::eth0:dhcp root=/dev/nfs rw nfsroot\x192.168.0.1:/home/tigtfarm07/NFS_exports/dra7xx-evm1/autofs/1d8e30535854dc371534f96e3c6d5488,nolock
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 1356664K/1570816K available (6271K kernel code, 508K rwdata, 2240K rodata, 372K init, 266K bss, 25736K reserved, 188416K cma-reserved, 768000K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0858064 (8513 kB)
[ 0.000000] .init : 0xc0859000 - 0xc08b6000 ( 372 kB)
[ 0.000000] .data : 0xc08b6000 - 0xc09352c0 ( 509 kB)
[ 0.000000] .bss : 0xc0938000 - 0xc097ab78 ( 267 kB)
[ 0.000000] SLUB: HWalignd, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Additional per-CPU info printed with stalls.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-1.
[ 0.000000] OMAP clockevent source: timer1 at 32768 Hz
[ 0.000000] clocksource 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[ 0.000427] Architected cp15 timer(s) running at 6.14MHz (virt).
[ 0.000457] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[ 0.000463] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[ 0.000470] Switching to timer-based delay loop, resolution 162ns
[ 0.001360] Console: colour dummy device 80x30
[ 0.001486] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[ 0.001488] This ensures that you still see kernel messages. Please
[ 0.001489] update your kernel commandline.
[ 0.001502] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpja475)
[ 0.001506] pid_max: default: 32768 minimum: 301
[ 0.001583] Security Framework initialized
[ 0.001620] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.001626] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.002189] Initializing cgroup subsys blkio
[ 0.002197] Initializing cgroup subsys memory
[ 0.002221] Initializing cgroup subsys devices
[ 0.002228] Initializing cgroup subsys freezer
[ 0.002236] Initializing cgroup subsys perf_event
[ 0.002278] CPU: Testing write buffer coherency: ok
[ 0.002517] /cpus/cpu@0 missing clock-frequency property
[ 0.002598] /cpus/cpu@1 missing clock-frequency property
[ 0.002609] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.002653] Setting up static identity map for 0x80008280 - 0x800082f0
[ 0.120957] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.121040] Brought up 2 CPUs
[ 0.121054] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[ 0.121061] CPU: All CPU(s) started in SVC mode.
[ 0.121513] devtmpfs: initialized
[ 0.149180] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[ 0.149968] omap_hwmod: l3_main_2 using broken dt data from ocp
[ 0.164029] omap_hwmod: tptc0 using broken dt data from edma-controller
[ 0.164509] omap_hwmod: tptc1 using broken dt data from edma-controller
[ 0.338569] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.342242] pinctrl core: initialized pinctrl subsystem
[ 0.343204] NET: Registered protocol family 16
[ 0.345772] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.354459] OMAP GPIO hardware version 0.1
[ 0.362174] irq: no irq domain found for /ocp/l4@4a000000/scm@2000/pinmux@1400 !
[ 0.388931] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.388942] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.391765] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[ 0.391775] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[ 0.392434] OMAP DMA hardware revision 0.0
[ 0.409403] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[ 0.412466] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[ 0.413035] platform fixedregulator-sd: Driver reg-fixed-voltage requests probe deferral
[ 0.418357] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[ 0.418619] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[ 0.418864] omap-iommu 58882000.mmu: 58882000.mmu registered
[ 0.419116] omap-iommu 55082000.mmu: 55082000.mmu registered
[ 0.419488] omap-iommu 41501000.mmu: 41501000.mmu registered
[ 0.419750] omap-iommu 41502000.mmu: 41502000.mmu registered
[ 0.420001] vgaarb: loaded
[ 0.420424] SCSI subsystem initialized
[ 0.421911] palmas 0-0058: IRQ missing: skipping irq request
[ 0.441468] palmas 0-0058: Muxing GPIO 2e, PWM 0, LED 0
[ 0.513681] pcf857x 0-0020: probed
[ 0.514304] pcf857x 0-0021: probed
[ 0.514450] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[ 0.531230] GPIO line 465 (vin6_sel_s0) hogged as output/low
[ 0.531421] pcf857x 1-0026: probed
[ 0.531580] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[ 0.532021] omap_i2c 48060000.i2c: bus 2 rev0.12 at 400 kHz
[ 0.532308] pps_core: LinuxPPS API ver. 1 registered
[ 0.532317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.532346] PTP clock support registered
[ 0.533009] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[ 0.533319] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[ 0.533623] Advanced Linux Sound Architecture Driver Initialized.
[ 0.534366] Switched to clocksource arch_sys_counter
[ 0.544551] NET: Registered protocol family 2
[ 0.545253] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.545334] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[ 0.545623] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.545685] UDP hash table entries: 512 (order: 3, 32768 bytes)
[ 0.545741] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[ 0.545949] NET: Registered protocol family 1
[ 0.546240] RPC: Registered named UNIX socket transport module.
[ 0.546249] RPC: Registered udp transport module.
[ 0.546256] RPC: Registered tcp transport module.
[ 0.546263] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.547419] CPU PMU: Failed to parse /pmu/interrupt-affinity[0]
[ 0.547454] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[ 0.549458] futex hash table entries: 512 (order: 3, 32768 bytes)
[ 0.549541] audit: initializing netlink subsys (disabled)
[ 0.549576] audit: type 00 audit(0.530:1): initialized
[ 0.556198] VFS: Disk quotas dquot_6.6.0
[ 0.556369] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.558508] NFS: Registering the id_resolver key type
[ 0.558542] Key type id_resolver registered
[ 0.558550] Key type id_legacy registered
[ 0.558610] jffs2: version 2.2. (NAND) (SUMMARY) 2001-2006 Red Hat, Inc.
[ 0.560591] NET: Registered protocol family 38
[ 0.560698] bounce: pool size: 64 pages
[ 0.560713] io scheduler noop registered
[ 0.560727] io scheduler deadline registered
[ 0.560879] io scheduler cfq registered (default)
[ 0.564728] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124
[ 0.574576] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[ 0.574590] pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
[ 0.574600] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[ 0.574612] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.574765] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[ 0.575026] PCI: bus0: Fast back to back transfers disabled
[ 0.575470] pci 0000:01:00.0: IOMMU is currently not supported for PCI
[ 0.575814] PCI: bus1: Fast back to back transfers disabled
[ 0.575950] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff]
[ 0.575966] pci 0000:00:00.0: BAR 8: assigned [mem 0x20200000-0x202fffff]
[ 0.575978] pci 0000:00:00.0: BAR 9: assigned [mem 0x20300000-0x203fffff pref]
[ 0.575989] pci 0000:00:00.0: BAR 1: assigned [mem 0x20020000-0x2002ffff]
[ 0.576002] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 0.576017] pci 0000:01:00.0: BAR 1: assigned [mem 0x20200000-0x2027ffff]
[ 0.576037] pci 0000:01:00.0: BAR 6: assigned [mem 0x20300000-0x2033ffff pref]
[ 0.576048] pci 0000:01:00.0: BAR 0: assigned [mem 0x20280000-0x2029ffff]
[ 0.576067] pci 0000:01:00.0: BAR 3: assigned [mem 0x202a0000-0x202a3fff]
[ 0.576086] pci 0000:01:00.0: BAR 2: assigned [io 0x1000-0x101f]
[ 0.576106] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 0.576116] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
[ 0.576128] pci 0000:00:00.0: bridge window [mem 0x20200000-0x202fffff]
[ 0.576138] pci 0000:00:00.0: bridge window [mem 0x20300000-0x203fffff pref]
[ 0.579925] OMAP DSS rev 6.1
[ 0.580244] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[ 0.580839] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[ 0.581749] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[ 0.582201] connector-hdmi connector@1: failed to find video source
[ 0.582219] platform connector@1: Driver connector-hdmi requests probe deferral
[ 0.585743] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[ 0.588508] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 299, base_baud = 3000000) is a 8250
[ 1.662547] console [ttyS0] enabled
[ 1.666661] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 300, base_baud = 3000000) is a 8250
[ 1.676287] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 301, base_baud = 3000000) is a 8250
[ 1.686280] [drm] Initialized drm 1.1.0 20060810
[ 1.700726] brd: module loaded
[ 1.708417] loop: module loaded
[ 1.712651] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.723546] mousedev: PS/2 mouse device common for all mice
[ 1.729154] i2c /dev entries driver
[ 1.734581] omap_hsmmc 4809c000.mmc: Got CD GPIO
[ 1.739413] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[ 1.746235] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[ 1.753335] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[ 1.760862] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[ 1.767334] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[ 1.774151] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[ 1.780537] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[ 1.786920] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[ 1.793302] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[ 1.800000] evm_3v3_sw: supplied by sysen1
[ 1.845119] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr104 mode
[ 1.851589] omap_hsmmc 480d1000.mmc: no pinctrl state for hs200_1_8v mode
[ 1.858426] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr50 mode
[ 1.864810] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr50 mode
[ 1.871192] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr_1_8v mode
[ 1.888212] mmc0: MAN_BKOPS_EN bit is not set
[ 1.896106] mmc0: new DDR MMC card at address 0001
[ 1.901266] mmcblk0: mmc0:0001 MMC08G 7.25 GiB
[ 1.905933] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[ 1.911994] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[ 1.918716] mmcblk0: p1 p2 p3
[ 1.995125] omap-aes 4b500000.aes: OMAP AES hw accel rev: 3.3
[ 2.001694] omap-aes 4b700000.aes: OMAP AES hw accel rev: 3.3
[ 2.009016] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[ 2.015924] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
[ 2.026077] davinci-mcasp 48468000.mcasp: ERRATA i868 workaround is enabled
[ 2.035132] davinci-mcasp 4847c000.mcasp: ERRATA i868 workaround is enabled
[ 2.042544] Initializing XFRM netlink socket
[ 2.046882] NET: Registered protocol family 17
[ 2.051375] NET: Registered protocol family 15
[ 2.055925] Key type dns_resolver registered
[ 2.060338] omap_voltage_late_init: Voltage driver support not added
[ 2.066734] sr_dev_init: Unable to get voltage domain pointer for VDD core
[ 2.073638] sr_dev_init: Unable to get voltage domain pointer for VDD mpu
[ 2.080738] Power Management for TI OMAP4+ devices.
[ 2.085863] ThumbEE CPU extension supported.
[ 2.090164] Registering SWP/SWPB emulation handler
[ 2.094984] SmartReflex Class3 initialized
[ 2.100743] dmm 4e000000.dmm: workaround for errata i878 in use
[ 2.108418] dmm 4e000000.dmm: initialized all PAT entries
[ 2.114210] platform omapdrm.0: Driver omapdrm requests probe deferral
[ 2.123162] omap_hsmmc 4809c000.mmc: Got CD GPIO
[ 2.128009] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[ 2.134830] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[ 2.196401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.203044] [drm] No driver support for vblank timestamp query.
[ 2.209023] omapdrm omapdrm.0: No connectors reported connected with modes
[ 2.215933] [drm] Cannot find any crtc or sizes - going 1024x768
[ 2.227640] [drm] Enabling DMM ywrap scrolling
[ 2.239535] Console: switching to colour frame buffer device 128x48
[ 2.251305] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[ 2.257253] omapdrm omapdrm.0: registered panic notifier
[ 2.274429] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
[ 2.280400] =================== deferred_probe_initcalll
[ 2.334387] davinci_mdio 48485000.mdio: davinci mdio revision 1.6
[ 2.340513] davinci_mdio 48485000.mdio: detected phy mask fffffff3
[ 2.344381] mmc2: host does not support reading read-only switch, assuming write-enable
[ 2.349716] mmc2: new high speed SDHC card at address e624
[ 2.354396] mmcblk1: mmc2:e624 SU04G 3.69 GiB
[ 2.362506] mmcblk1: p1 p2 p3
[ 2.372593] libphy: 48485000.mdio: probed
[ 2.376626] davinci_mdio 48485000.mdio: phy[2]: device 48485000.mdio:02, driver unknown
[ 2.384668] davinci_mdio 48485000.mdio: phy[3]: device 48485000.mdio:03, driver unknown
[ 2.393389] cpsw 48484000.ethernet: Detected MACID = b4:99:4c:0b:e4:e6
[ 2.400896] cpsw 48484000.ethernet: cpsw: Detected MACID = b4:99:4c:0b:e4:e7
[ 2.408583] hctosys: unable to open rtc device (rtc0)
[ 2.413661] sr_init: No PMIC hook to init smartreflex
[ 2.418903] sr_init: platform driver register failed for SR
[ 2.441783] net eth0: initializing cpsw version 1.15 (0)
[ 2.528312] net eth0: phy found : id is : 0x20005c7a
[ 6.531286] cpsw 48484000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 6.554382] Sending DHCP requests ., OK
[ 6.624439] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.192
[ 6.632426] IP-Config: Complete:
[ 6.635674] device=eth0, hwaddr´:99:4c:0b:e4:e6, ipaddr\x192.168.0.192, mask%5.255.255.0, gw\x192.168.0.1
[ 6.645895] host\x192.168.0.192, domain=ti.com, nis-domain=(none)
[ 6.652364] bootserver\x192.168.0.1, rootserver\x192.168.0.1, rootpath[ 6.659095] nameserver0\x192.0.2.2, nameserver1\x192.0.2.3
[ 6.665282] ldousb: disabling
[ 6.668549] vmmcwl_fixed: disabling
[ 6.672054] aic_dvdd: disabling
[ 6.675417] ALSA device list:
[ 6.678397] No soundcards found.
[ 6.687614] VFS: Mounted root (nfs filesystem) on device 0:15.
[ 6.693779] devtmpfs: mounted
[ 6.697044] Freeing unused kernel memory: 372K (c0859000 - c08b6000)
INIT: version 2.88 booting
Starting udev
[ 7.129889] udevd[175]: starting version 182
[ 7.329630] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[ 7.349436] remoteproc0: 58820000.ipu is available
[ 7.358961] remoteproc0: Note: remoteproc is still under development and considered experimental.
[ 7.431205] remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 7.452181] remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[ 7.456683] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[ 7.471645] remoteproc1: 55020000.ipu is available
[ 7.471649] remoteproc1: Note: remoteproc is still under development and considered experimental.
[ 7.471653] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 7.480262] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[ 7.510612] remoteproc2: 40800000.dsp is available
[ 7.510618] remoteproc2: Note: remoteproc is still under development and considered experimental.
[ 7.510622] remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 7.514543] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[ 7.523301] remoteproc3: 41000000.dsp is available
[ 7.523306] remoteproc3: Note: remoteproc is still under development and considered experimental.
[ 7.523309] remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[ 7.614060] remoteproc0: Falling back to user helper
[ 7.672048] aic_dvdd: supplied by evm_3v3_sw
[ 7.736112] omap_rng 48090000.rng: OMAP Random Number Generator ver. 20
[ 8.067185] media: Linux media interface: v0.10
[ 8.216475] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc0
[ 8.217206] Linux video capture interface: v2.00
[ 8.276707] random: nonblocking pool is initialized
[ 8.394957] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[ 8.420281] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[ 8.423788] ov1063x 1-0037: Failed writing register 0x0103!
[ 8.423807] ov1063x: probe of 1-0037 failed with error -121
[ 8.488870] remoteproc0: failed to load dra7-ipu1-fw.xem4
[ 8.729862] platform 488c0000.omap_dwc3_2: Driver omap-dwc3 requests probe deferral
[ 8.733069] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[ 8.733072] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[ 8.733178] e1000e 0000:01:00.0: enabling device (0140 -> 0142)
[ 8.733435] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 8.750383] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[ 8.750685] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[ 8.750692] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[ 8.779935] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[ 8.780067] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[ 8.780073] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[ 8.951061] CAN device driver interface
[ 8.963296] e1000e 0000:01:00.0 eth2: registered PHC clock
[ 8.963304] e1000e 0000:01:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 68:05:ca:36:2b:25
[ 8.963311] e1000e 0000:01:00.0 eth2: Intel(R) PRO/1000 Network Connection
[ 8.966445] e1000e 0000:01:00.0 eth2: MAC: 3, PHY: 8, PBA No: E46981-008
[ 9.024825] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[ 9.027031] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[ 9.027039] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[ 9.287323] remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[ 9.287327] remoteproc2: Falling back to user helper
[ 9.308265] omap-dwc3 48880000.omap_dwc3_1: **** dwc3_omap_probe done
[ 9.341969] platform 488c0000.omap_dwc3_2: deferring probe: == Driver omap-dwc3 requests probe deferral
[ 9.357153] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[ 9.363840] remoteproc1: registered virtio0 (type 7)
[ 9.390936] omap-dwc3 488c0000.omap_dwc3_2: **** dwc3_omap_probe done
[ 9.411821] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 9.487056] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[ 9.530380] asoc-simple-card sound@0: tlv320aic3x-hifi <-> 48468000.mcasp mapping ok
[ 9.572735] c_can_platform 4ae3c000.can: c_can_platform device registered (regsüe3c000, irq49)
[ 9.585025] vip 48970000.vip: loading firmware vpdma-1b8.bin
[ 9.592896] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[ 9.599650] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[ 9.608289] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst
[ 9.703388] scsi host0: ahci
[ 9.763672] omap-hdmi-audio omap-hdmi-audio.0.auto: snd-soc-dummy-dai <-> 58040000.encoder mapping ok
[ 9.803153] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 336
[ 10.164442] ata1: SATA link down (SStatus 0 SControl 300)
[ 10.642315] remoteproc2: failed to load dra7-dsp1-fw.xe66
[ 10.659698] remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[ 10.671669] remoteproc3: Falling back to user helper
[ 10.811525] remoteproc1: powering up 55020000.ipu
[ 10.820600] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[ 10.820686] 10 ofpart partitions found on MTD device spi32766.0
[ 10.820693] Creating 10 MTD partitions on "spi32766.0":
[ 10.820702] 0x000000000000-0x000000010000 : "QSPI.SPL"
[ 10.886395] 0x000000010000-0x000000020000 : "QSPI.SPL.backup1"
[ 10.895608] remoteproc3: failed to load dra7-dsp2-fw.xe66
[ 10.909877] 0x000000020000-0x000000030000 : "QSPI.SPL.backup2"
[ 10.912583] 0x000000030000-0x000000040000 : "QSPI.SPL.backup3"
[ 10.913546] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[ 10.914433] vip 48970000.vip: VPDMA firmware loaded
[ 10.914670] vpe 489d0000.vpe: Device registered as /dev/video0
[ 10.938439] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[ 10.962444] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[ 11.011549] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[ 11.071277] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[ 11.080616] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[ 11.415621] EXT4-fs (mmcblk0p3): mounted filesystem without journal. Opts: (null)
[ 11.439508] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 11.476702] remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3480916
[ 11.491518] EXT4-fs (mmcblk1p3): mounted filesystem without journal. Opts: (null)
[ 11.495115] EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
[ 11.505950] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[ 11.536011] FAT-fs (mmcblk0p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 11.641063] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 11.690531] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[ 11.894821] dwc3 48890000.usb: **** dwc3_probe done
[ 11.972740] remoteproc1: remote processor 55020000.ipu is now up
[ 11.999719] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 12.003008] virtio_rpmsg_bus virtio0: creating channel rpmsg-rpc addr 0x3b
[ 12.085055] rpmsg_rpc rpmsg0: probing service rpmsg-dce with src 1024 dst 59
[ 12.092778] rpmsg_rpc rpmsg0: published functions = 8
[ 12.387531] dwc3 488d0000.usb: **** dwc3_probe done
[ 12.555405] usbcore: registered new interface driver usbfs
[ 12.561001] usbcore: registered new interface driver hub
[ 12.566496] usbcore: registered new device driver usb
[ 12.619632] dwc3 48890000.usb: otg: primary host xhci-hcd.1.auto registered
[ 12.626635] dwc3 48890000.usb: otg: shared host xhci-hcd.1.auto registered
[ 12.633543] dwc3 48890000.usb: otg: can't start till gadget registers
[ 12.640118] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 12.645652] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[ 12.653905] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 12.662779] xhci-hcd xhci-hcd.2.auto: irq 463, io mem 0x488d0000
[ 12.668985] usb usb1: New USB device found, idVendor\x1d6b, idProduct\002
[ 12.681600] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 12.688857] usb usb1: Product: xHCI Host Controller
[ 12.693757] usb usb1: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[ 12.701448] usb usb1: SerialNumber: xhci-hcd.2.auto
[ 12.707274] hub 1-0:1.0: USB hub found
[ 12.711077] hub 1-0:1.0: 1 port detected
[ 12.715501] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 12.721021] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[ 12.728804] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 12.737061] usb usb2: New USB device found, idVendor\x1d6b, idProduct\003
[ 12.743880] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 12.751136] usb usb2: Product: xHCI Host Controller
[ 12.756039] usb usb2: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[ 12.763727] usb usb2: SerialNumber: xhci-hcd.2.auto
[ 12.769500] hub 2-0:1.0: USB hub found
[ 12.773298] hub 2-0:1.0: 1 port detected
bootlogd: cannot allocate pseudo tty: No such file or directory
Starting random number generator daemon.
[ 13.034435] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 13.176262] usb 1-1: New USB device found, idVendor\x154b, idProduct\07a
[ 13.183002] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 13.190859] usb 1-1: Product: USB 2.0 FD
[ 13.194810] usb 1-1: Manufacturer: PNY Technologies
[ 13.199717] usb 1-1: SerialNumber: AEC12H25YE11003156
[ 13.209498] usb 1-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 13.218598] usb 1-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[ 13.280307] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 13.287194] scsi host1: usb-storage 1-1:1.0
[ 13.293029] usbcore: registered new interface driver usb-storage
^ permalink raw reply related
* Re: [RESEND PATCH] pwm-backlight: fix the panel power sequence
From: YH Huang @ 2015-10-22 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1444984313.3180.6.camel@pengutronix.de>
On Fri, 2015-10-16 at 10:31 +0200, Lucas Stach wrote:
> Am Freitag, den 16.10.2015, 09:37 +0800 schrieb YH Huang:
> > In order to match the panel power sequence, disable the enable_gpio
> > in the probe function. Also, reorder the code in the power_on and
> > power_off function to match the timing.
> >
> You aren't specifying which panels power sequence you are matching here.
> Are you sure you aren't breaking other panels with this patch?
>
> Regards,
> Lucas
The panel sequence is:
When powering on the panel, generate pwm signals fist and then enable it
to show the backlight.
When powering off the panel, do it opposite.
In probe function, we keep the panel status from bootloader and don't
enable or disable it by default.
Do these changes break other panels?
Regards,
YH Huang
>
> > Signed-off-by: YH Huang <yh.huang@mediatek.com>
> > ---
> > drivers/video/backlight/pwm_bl.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index eff379b..99eca1e 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -54,10 +54,11 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness)
> > if (err < 0)
> > dev_err(pb->dev, "failed to enable power supply\n");
> >
> > + pwm_enable(pb->pwm);
> > +
> > if (pb->enable_gpio)
> > gpiod_set_value(pb->enable_gpio, 1);
> >
> > - pwm_enable(pb->pwm);
> > pb->enabled = true;
> > }
> >
> > @@ -66,12 +67,12 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> > if (!pb->enabled)
> > return;
> >
> > - pwm_config(pb->pwm, 0, pb->period);
> > - pwm_disable(pb->pwm);
> > -
> > if (pb->enable_gpio)
> > gpiod_set_value(pb->enable_gpio, 0);
> >
> > + pwm_config(pb->pwm, 0, pb->period);
> > + pwm_disable(pb->pwm);
> > +
> > regulator_disable(pb->power_supply);
> > pb->enabled = false;
> > }
> > @@ -241,8 +242,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> > pb->dev = &pdev->dev;
> > pb->enabled = false;
> >
> > - pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> > - GPIOD_OUT_HIGH);
> > + pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
> > if (IS_ERR(pb->enable_gpio)) {
> > ret = PTR_ERR(pb->enable_gpio);
> > goto err_alloc;
> > @@ -264,6 +264,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> > pb->enable_gpio = gpio_to_desc(data->enable_gpio);
> > }
> >
> > + if (pb->enable_gpio)
> > + gpiod_direction_output(pb->enable_gpio, 0);
> > +
> > pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> > if (IS_ERR(pb->power_supply)) {
> > ret = PTR_ERR(pb->power_supply);
>
^ permalink raw reply
* Re: [PATCH RFC v2 0/2] simplefb: Add regulator handling support
From: Mark Brown @ 2015-10-22 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445407141-16459-1-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 292 bytes --]
On Wed, Oct 21, 2015 at 01:58:59PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v2 of the simplefb regulator support series. This series adds
> regulator claiming and enabling support for simplefb.
This approach seems reasonable
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] video: fbdev: pxafb: initial devicetree conversion
From: kbuild test robot @ 2015-10-22 18:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444764869-24893-2-git-send-email-robert.jarzmik@free.fr>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
Hi Robert,
[auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please suggest rules for selecting the more suitable base]
url: https://github.com/0day-ci/linux/commits/Robert-Jarzmik/video-fbdev-pxafb-loosen-the-platform-data-bond/20151014-034326
config: arm-viper_defconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/video/fbdev/pxafb: struct of_device_id is 196 bytes. The last of 1 is:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6d 0x61 0x72 0x76 0x65 0x6c 0x6c 0x2c 0x70 0x78 0x61 0x32 0x78 0x78 0x2d 0x6c 0x63 0x64 0x63 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> FATAL: drivers/video/fbdev/pxafb: struct of_device_id is not terminated with a NULL entry!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 17365 bytes --]
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Frank Rowand @ 2015-10-22 18:53 UTC (permalink / raw)
To: 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: <20151022144405.GC21861@kroah.com>
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.
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.
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.)
-Frank
> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
>
>> Sorry for the rant,
>
> No apologies needed, it's cathartic at times :)
>
> thanks,
>
> greg k-h
> .
>
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Greg Kroah-Hartman @ 2015-10-22 19:26 UTC (permalink / raw)
To: Frank Rowand
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: <562930AB.1070203@gmail.com>
On Thu, Oct 22, 2015 at 11:53:31AM -0700, 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.
>
> 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.
>
> 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 agree, there might be some small numbers that this is a problem for,
and if so, great, show us the boot logs where things are taking up all
of the time, and we can work on resolving those issues.
But without hard numbers / details, this all is just random hand-waving,
and I don't like making core kernel changes on that basis. And no one
else should ever want us to do that either.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/2] video: fbdev: pxafb: initial devicetree conversion
From: Robert Jarzmik @ 2015-10-22 19:30 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Philipp Zabel
In-Reply-To: <201510230211.r3WXXurc%fengguang.wu@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Hi Robert,
>
> [auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please
> suggest rules for selecting the more suitable base]
...
>>> FATAL: drivers/video/fbdev/pxafb: struct of_device_id is not terminated with a NULL entry!
Ah silly me ... It probably deserves a v3 of the patch to add the forgotten :
{},
at the end of the struct of_device_id ...
Cheers.
--
Robert
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Mark Brown @ 2015-10-22 23:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Greg Kroah-Hartman, Tomeu Vizoso, Frank Rowand, Rob Herring,
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: <20151022150213.GT32532@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:
> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem. I think the fact is, there is no data.
> Someone prove me wrong. Someone post the verifiable data showing that
> there is a problem to be solved here.
> Someone show what the specific failure cases are that are hampering
> vendors moving forwards. Someone show the long boot times by way of
> kernel message log. Someone show some evidence of the problems that
> have been alluded to.
> If no one can show some evidence, there isn't a problem here. :)
Yeah, I'm not convinced the timing is *such* a big deal either - I do
think that the log spam is a real problem but I think something much
less invasive like the interface you proposed is good for addressing
that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH v3 0/2] simplefb: Add regulator handling support
From: Chen-Yu Tsai @ 2015-10-23 1:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This is v3 of the simplefb regulator support series. This series adds
regulator claiming and enabling support for simplefb.
Changes since v3:
- Dropped extra "if" which is always true, leftover from v1.
- Updated commit message of patch 1
Sometimes the simplefb display output path consits of external conversion
chips and/or LCD drivers and backlights. These devices normally have
GPIOs to turn them on and/or bring them out of reset, and regulators
supplying power to them.
While the kernel does not touch unclaimed GPIOs, the regulator core
happily disables unused regulators. Thus we need simplefb to claim
and enable the regulators used throughout the display pipeline.
The binding supports any named regulator supplies under its device
node. The driver will look through its properties, and claim any
regulators by matching "*-supply", as Mark suggested.
I've not done a generic helper in the regulator core yet, instead doing
the regulator property handling in the simplefb code for now.
Patch 1 adds the regulator properties to the DT binding.
Patch 2 adds code to the simplefb driver to claim and enable regulators.
Regards
ChenYu
Chen-Yu Tsai (2):
dt-bindings: simplefb: Support regulator supply properties
simplefb: Claim and enable regulators
.../bindings/video/simple-framebuffer.txt | 13 ++-
drivers/video/fbdev/simplefb.c | 120 ++++++++++++++++++++-
2 files changed, 128 insertions(+), 5 deletions(-)
--
2.6.1
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: simplefb: Support regulator supply properties
From: Chen-Yu Tsai @ 2015-10-23 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445563918-1050-1-git-send-email-wens@csie.org>
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/video/simple-framebuffer.txt | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+ be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
--
2.6.1
^ permalink raw reply related
* [PATCH v3 2/2] simplefb: Claim and enable regulators
From: Chen-Yu Tsai @ 2015-10-23 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445563918-1050-1-git-send-email-wens@csie.org>
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/video/fbdev/simplefb.c | 120 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..9de34ee15ac0 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
+#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/parser.h>
+#include <linux/regulator/consumer.h>
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(&pdev->dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void simplefb_regulators_destroy(struct simplefb_par *par) { }
+#endif
+
static int simplefb_probe(struct platform_device *pdev)
{
int ret;
@@ -340,6 +451,10 @@ static int simplefb_probe(struct platform_device *pdev)
if (ret < 0)
goto error_unmap;
+ ret = simplefb_regulators_init(par, pdev);
+ if (ret < 0)
+ goto error_clocks;
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
@@ -351,13 +466,15 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- goto error_clocks;
+ goto error_regulators;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
+error_regulators:
+ simplefb_regulators_destroy(par);
error_clocks:
simplefb_clocks_destroy(par);
error_unmap:
@@ -373,6 +490,7 @@ static int simplefb_remove(struct platform_device *pdev)
struct simplefb_par *par = info->par;
unregister_framebuffer(info);
+ simplefb_regulators_destroy(par);
simplefb_clocks_destroy(par);
framebuffer_release(info);
--
2.6.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] simplefb: Claim and enable regulators
From: Chen-Yu Tsai @ 2015-10-23 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445563918-1050-3-git-send-email-wens@csie.org>
On Fri, Oct 23, 2015 at 9:31 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> This claims and enables regulators listed in the simple framebuffer dt
> node. This is needed so that regulators powering the display pipeline
> and external hardware, described in the device node and known by the
> kernel code, will remain properly enabled.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Mark Brown <broonie@kernel.org>
> ---
> drivers/video/fbdev/simplefb.c | 120 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 119 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 52c5c7e63b52..9de34ee15ac0 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -28,7 +28,10 @@
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> #include <linux/clk-provider.h>
> +#include <linux/of.h>
> #include <linux/of_platform.h>
> +#include <linux/parser.h>
> +#include <linux/regulator/consumer.h>
>
> static struct fb_fix_screeninfo simplefb_fix = {
> .id = "simple",
> @@ -174,6 +177,10 @@ struct simplefb_par {
> int clk_count;
> struct clk **clks;
> #endif
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> + u32 regulator_count;
> + struct regulator **regulators;
> +#endif
> };
>
> #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> @@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
> static void simplefb_clocks_destroy(struct simplefb_par *par) { }
> #endif
>
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> +
> +#define SUPPLY_SUFFIX "-supply"
> +
> +/*
> + * Regulator handling code.
> + *
> + * Here we handle the num-supplies and vin*-supply properties of our
> + * "simple-framebuffer" dt node. This is necessary so that we can make sure
> + * that any regulators needed by the display hardware that the bootloader
> + * set up for us (and for which it provided a simplefb dt node), stay up,
> + * for the life of the simplefb driver.
> + *
> + * When the driver unloads, we cleanly disable, and then release the
> + * regulators.
> + *
> + * We only complain about errors here, no action is taken as the most likely
> + * error can only happen due to a mismatch between the bootloader which set
> + * up simplefb, and the regulator definitions in the device tree. Chances are
> + * that there are no adverse effects, and if there are, a clean teardown of
> + * the fb probe will not help us much either. So just complain and carry on,
> + * and hope that the user actually gets a working fb at the end of things.
> + */
> +static int simplefb_regulators_init(struct simplefb_par *par,
> + struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct property *prop;
> + struct regulator *regulator;
> + const char *p;
> + int count = 0, i = 0, ret;
> +
> + if (dev_get_platdata(&pdev->dev) || !np)
> + return 0;
> +
> + /* Count the number of regulator supplies */
> + for_each_property_of_node(np, prop) {
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
> + count++;
> + }
> +
> + if (!count)
> + return 0;
> +
> + par->regulators = devm_kcalloc(&pdev->dev, count,
> + sizeof(struct regulator *), GFP_KERNEL);
> + if (!par->regulators)
> + return -ENOMEM;
> +
> + /* Get all the regulators */
> + for_each_property_of_node(np, prop) {
> + char name[32]; /* 32 is max size of property name */
> +
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
Sorry, the test is completely reversed here.
> + continue;
> +
> + strlcpy(name, prop->name,
> + strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
And string length is off by 1 due to using sizeof here.
I'll send a new version. Sorry for the noise.
ChenYu
> + regulator = devm_regulator_get_optional(&pdev->dev, name);
> + if (IS_ERR(regulator)) {
> + if (PTR_ERR(regulator) = -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(&pdev->dev, "regulator %s not found: %ld\n",
> + name, PTR_ERR(regulator));
> + continue;
> + }
> + par->regulators[i++] = regulator;
> + }
> + par->regulator_count = i;
> +
> + /* Enable all the regulators */
> + for (i = 0; i < par->regulator_count; i++) {
> + ret = regulator_enable(par->regulators[i]);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to enable regulator %d: %d\n",
> + i, ret);
> + devm_regulator_put(par->regulators[i]);
> + par->regulators[i] = NULL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void simplefb_regulators_destroy(struct simplefb_par *par)
> +{
> + int i;
> +
> + if (!par->regulators)
> + return;
> +
> + for (i = 0; i < par->regulator_count; i++)
> + if (par->regulators[i])
> + regulator_disable(par->regulators[i]);
> +}
> +#else
> +static int simplefb_regulators_init(struct simplefb_par *par,
> + struct platform_device *pdev) { return 0; }
> +static void simplefb_regulators_destroy(struct simplefb_par *par) { }
> +#endif
> +
> static int simplefb_probe(struct platform_device *pdev)
> {
> int ret;
> @@ -340,6 +451,10 @@ static int simplefb_probe(struct platform_device *pdev)
> if (ret < 0)
> goto error_unmap;
>
> + ret = simplefb_regulators_init(par, pdev);
> + if (ret < 0)
> + goto error_clocks;
> +
> dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
> info->fix.smem_start, info->fix.smem_len,
> info->screen_base);
> @@ -351,13 +466,15 @@ static int simplefb_probe(struct platform_device *pdev)
> ret = register_framebuffer(info);
> if (ret < 0) {
> dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> - goto error_clocks;
> + goto error_regulators;
> }
>
> dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>
> return 0;
>
> +error_regulators:
> + simplefb_regulators_destroy(par);
> error_clocks:
> simplefb_clocks_destroy(par);
> error_unmap:
> @@ -373,6 +490,7 @@ static int simplefb_remove(struct platform_device *pdev)
> struct simplefb_par *par = info->par;
>
> unregister_framebuffer(info);
> + simplefb_regulators_destroy(par);
> simplefb_clocks_destroy(par);
> framebuffer_release(info);
>
> --
> 2.6.1
>
^ permalink raw reply
* [PATCH v4 0/4] simplefb: Add regulator handling support
From: Chen-Yu Tsai @ 2015-10-23 3:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This is v4 of the simplefb regulator support series. This series adds
regulator claiming and enabling support for simplefb.
Changes since v4:
- Fixed inverted logic when testing the property name.
- Fixed regulator supply name string copy length off by 1.
- Added real world user, MSI Primo 81 dts patches.
Changes since v3:
- Dropped extra "if" which is always true, leftover from v1.
- Updated commit message of patch 1
Sometimes the simplefb display output path consits of external conversion
chips and/or LCD drivers and backlights. These devices normally have
GPIOs to turn them on and/or bring them out of reset, and regulators
supplying power to them.
While the kernel does not touch unclaimed GPIOs, the regulator core
happily disables unused regulators. Thus we need simplefb to claim
and enable the regulators used throughout the display pipeline.
The binding supports any named regulator supplies under its device
node. The driver will look through its properties, and claim any
regulators by matching "*-supply", as Mark suggested.
I've not done a generic helper in the regulator core yet, instead doing
the regulator property handling in the simplefb code for now.
Patch 1 adds the regulator properties to the DT binding.
Patch 2 adds code to the simplefb driver to claim and enable regulators.
Hans, I dropped your Reviewed-by tag from this patch.
Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi
so we can reference them in the board dts files, like in the next
patch.
Patch 4 adds a dts file for MSI's Primo 81 tablet.
Regards
ChenYu
Chen-Yu Tsai (3):
dt-bindings: simplefb: Support regulator supply properties
simplefb: Claim and enable regulators
ARM: dts: sun6i: Add simplefb node labels to reference at board level
Karsten Merker (1):
ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
.../bindings/video/simple-framebuffer.txt | 13 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun6i-a31.dtsi | 4 +-
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++++++++++++++++++++
drivers/video/fbdev/simplefb.c | 120 +++++++++-
5 files changed, 386 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
--
2.6.1
^ permalink raw reply
* [PATCH v4 1/4] dt-bindings: simplefb: Support regulator supply properties
From: Chen-Yu Tsai @ 2015-10-23 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/video/simple-framebuffer.txt | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+ be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
--
2.6.1
^ permalink raw reply related
* [PATCH v4 2/4] simplefb: Claim and enable regulators
From: Chen-Yu Tsai @ 2015-10-23 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/video/fbdev/simplefb.c | 120 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
+#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/parser.h>
+#include <linux/regulator/consumer.h>
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(&pdev->dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p = prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(&pdev->dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) = -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void simplefb_regulators_destroy(struct simplefb_par *par) { }
+#endif
+
static int simplefb_probe(struct platform_device *pdev)
{
int ret;
@@ -340,6 +451,10 @@ static int simplefb_probe(struct platform_device *pdev)
if (ret < 0)
goto error_unmap;
+ ret = simplefb_regulators_init(par, pdev);
+ if (ret < 0)
+ goto error_clocks;
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
@@ -351,13 +466,15 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- goto error_clocks;
+ goto error_regulators;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
+error_regulators:
+ simplefb_regulators_destroy(par);
error_clocks:
simplefb_clocks_destroy(par);
error_unmap:
@@ -373,6 +490,7 @@ static int simplefb_remove(struct platform_device *pdev)
struct simplefb_par *par = info->par;
unregister_framebuffer(info);
+ simplefb_regulators_destroy(par);
simplefb_clocks_destroy(par);
framebuffer_release(info);
--
2.6.1
^ permalink raw reply related
* [PATCH v4 3/4] ARM: dts: sun6i: Add simplefb node labels to reference at board level
From: Chen-Yu Tsai @ 2015-10-23 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
Some boards, such as tablets, have regulators providing power to parts
of the display pipeline, like signal converters and LCD panels.
Add labels to the simplefb device nodes so that we can reference them
in the board dts files to add regulator supply properties.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 83c18798cae0..b6ad7850fac6 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -61,7 +61,7 @@
#size-cells = <1>;
ranges;
- framebuffer@0 {
+ simplefb_hdmi: framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
@@ -69,7 +69,7 @@
status = "disabled";
};
- framebuffer@1 {
+ simplefb_lcd: framebuffer@1 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
--
2.6.1
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Chen-Yu Tsai @ 2015-10-23 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
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
external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
OTG and 3.5mm headphone jack.
USB OTG is enabled in host only mode. AXP221 USB power supply and
GPIO support are required for full USB OTG support.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Karsten Merker <merker@debian.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Changes since last submission (was part of Sinlinx SinA31s series)
- Update axp22x.dtsi file name
- Sort regulators
- Drop URL in commit message
- Drop comment for capacitive touch panel
- Add simplefb regulators
- Drop regulator-always-on for regulators that aren't critical
- Fix CPU and GPU regulator supply mix-up
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++++++++++++++++++++++++++++++
2 files changed, 256 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c00b72e750ab..78ade1a5e886 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
sun6i-a31s-cs908.dtb \
+ sun6i-a31s-primo81.dtb \
sun6i-a31s-sina31s.dtb \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
new file mode 100644
index 000000000000..2d4250b1faf8
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2014 Siarhei Siamashka <siarhei.siamashka@gmail.com>
+ * Copyright 2015 Karsten Merker <merker@debian.org>
+ * Copyright 2015 Chen-Yu Tsai <wens@csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun6i-a31s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "MSI Primo81 tablet";
+ compatible = "msi,primo81", "allwinner,sun6i-a31s";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc3>;
+};
+
+&ehci0 {
+ /* rtl8188etv wifi is connected here */
+ status = "okay";
+};
+
+&i2c0 {
+ /* pull-ups and device VDDIO use AXP221 DLDO3 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "failed";
+};
+
+&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 */
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+
+ accelerometer@1c {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mma8452_int_primo81>;
+ compatible = "fsl,mma8452";
+ reg = <0x1c>;
+ interrupt-parent = <&pio>;
+ interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>; /* PA9 */
+ #io-channel-cells = <1>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_aldo3>;
+ status = "okay";
+
+ button@158 {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ channel = <0>;
+ voltage = <158730>;
+ };
+
+ button@349 {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ channel = <0>;
+ voltage = <349206>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_primo81>;
+ vmmc-supply = <®_dcdc1>;
+ bus-width = <4>;
+ cd-gpios = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */
+ cd-inverted;
+ status = "okay";
+};
+
+&pio {
+ gt911_int_primo81: gt911_int_pin@0 {
+ allwinner,pins = "PA3";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ mma8452_int_primo81: mma8452_int_pin@0 {
+ allwinner,pins = "PA9";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+ };
+
+ mmc0_cd_pin_primo81: mmc0_cd_pin@0 {
+ allwinner,pins = "PA8";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+ };
+};
+
+&p2wi {
+ status = "okay";
+
+ axp22x: pmic@68 {
+ compatible = "x-powers,axp221";
+ reg = <0x68>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avcc";
+};
+
+®_dc1sw {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc-lcd";
+};
+
+®_dc5ldo {
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-name = "vdd-cpus"; /* This is an educated guess */
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc-3v0";
+};
+
+®_dcdc2 {
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-name = "vdd-gpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc4 {
+ regulator-always-on;
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-name = "vdd-sys-dll";
+};
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vddio-csi";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-name = "vdd-mipi-bridge";
+};
+
+&simplefb_lcd {
+ vcc-lcd-supply = <®_dc1sw>;
+ vdd-mipi-bridge-supply = <®_eldo3>;
+};
+
+&usb_otg {
+ /* otg support requires support for AXP221 usb-power-supply and GPIO */
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbphy {
+ usb1_vbus-supply = <®_dldo1>;
+ status = "okay";
+};
--
2.6.1
^ permalink raw reply related
* Re: [PATCH v4 0/4] simplefb: Add regulator handling support
From: Maxime Ripard @ 2015-10-23 6:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
On Fri, Oct 23, 2015 at 11:50:37AM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v4 of the simplefb regulator support series. This series adds
> regulator claiming and enabling support for simplefb.
>
> Changes since v4:
> - Fixed inverted logic when testing the property name.
> - Fixed regulator supply name string copy length off by 1.
> - Added real world user, MSI Primo 81 dts patches.
>
> Changes since v3:
> - Dropped extra "if" which is always true, leftover from v1.
> - Updated commit message of patch 1
>
> Sometimes the simplefb display output path consits of external conversion
> chips and/or LCD drivers and backlights. These devices normally have
> GPIOs to turn them on and/or bring them out of reset, and regulators
> supplying power to them.
>
> While the kernel does not touch unclaimed GPIOs, the regulator core
> happily disables unused regulators. Thus we need simplefb to claim
> and enable the regulators used throughout the display pipeline.
>
> The binding supports any named regulator supplies under its device
> node. The driver will look through its properties, and claim any
> regulators by matching "*-supply", as Mark suggested.
>
> I've not done a generic helper in the regulator core yet, instead doing
> the regulator property handling in the simplefb code for now.
>
>
> Patch 1 adds the regulator properties to the DT binding.
>
> Patch 2 adds code to the simplefb driver to claim and enable regulators.
> Hans, I dropped your Reviewed-by tag from this patch.
>
> Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi
> so we can reference them in the board dts files, like in the next
> patch.
>
> Patch 4 adds a dts file for MSI's Primo 81 tablet.
Applied 3 and 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 v4 0/4] simplefb: Add regulator handling support
From: Hans de Goede @ 2015-10-23 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1445572241-13259-1-git-send-email-wens@csie.org>
Hi,
Patches 1/2 look good and are:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And the approach used for the regulators in them is also:
Acked-by: Mark Brown <broonie@kernel.org>
So patches 1/2 are ready for merging.
Jean-Christophe or Tomi, can you pick up patch 1 & 2 please ?
Regards,
Hans
On 10/23/2015 05:50 AM, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v4 of the simplefb regulator support series. This series adds
> regulator claiming and enabling support for simplefb.
>
> Changes since v4:
> - Fixed inverted logic when testing the property name.
> - Fixed regulator supply name string copy length off by 1.
> - Added real world user, MSI Primo 81 dts patches.
>
> Changes since v3:
> - Dropped extra "if" which is always true, leftover from v1.
> - Updated commit message of patch 1
>
> Sometimes the simplefb display output path consits of external conversion
> chips and/or LCD drivers and backlights. These devices normally have
> GPIOs to turn them on and/or bring them out of reset, and regulators
> supplying power to them.
>
> While the kernel does not touch unclaimed GPIOs, the regulator core
> happily disables unused regulators. Thus we need simplefb to claim
> and enable the regulators used throughout the display pipeline.
>
> The binding supports any named regulator supplies under its device
> node. The driver will look through its properties, and claim any
> regulators by matching "*-supply", as Mark suggested.
>
> I've not done a generic helper in the regulator core yet, instead doing
> the regulator property handling in the simplefb code for now.
>
>
> Patch 1 adds the regulator properties to the DT binding.
>
> Patch 2 adds code to the simplefb driver to claim and enable regulators.
> Hans, I dropped your Reviewed-by tag from this patch.
>
> Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi
> so we can reference them in the board dts files, like in the next
> patch.
>
> Patch 4 adds a dts file for MSI's Primo 81 tablet.
>
>
> Regards
> ChenYu
>
> Chen-Yu Tsai (3):
> dt-bindings: simplefb: Support regulator supply properties
> simplefb: Claim and enable regulators
> ARM: dts: sun6i: Add simplefb node labels to reference at board level
>
> Karsten Merker (1):
> ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
>
> .../bindings/video/simple-framebuffer.txt | 13 +-
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun6i-a31.dtsi | 4 +-
> arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++++++++++++++++++++
> drivers/video/fbdev/simplefb.c | 120 +++++++++-
> 5 files changed, 386 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
>
^ permalink raw reply
* Re: [GIT PULL] On-demand device probing
From: Tim Bird @ 2015-10-23 15:45 UTC (permalink / raw)
To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
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: <562930AB.1070203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
>
> 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 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.
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.)
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. :-)
-- Tim
^ permalink raw reply
* Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Chen-Yu Tsai @ 2015-10-23 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151023145309.GA1885@excalibur.cnev.de>
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.
>
>> external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
>> OTG and 3.5mm headphone jack.
>>
>> USB OTG is enabled in host only mode. AXP221 USB power supply and
>> GPIO support are required for full USB OTG support.
>>
>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
>> Signed-off-by: Karsten Merker <merker@debian.org>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>>
>> Changes since last submission (was part of Sinlinx SinA31s series)
>>
>> - Update axp22x.dtsi file name
>> - Sort regulators
>> - Drop URL in commit message
>> - Drop comment for capacitive touch panel
>> - Add simplefb regulators
>> - Drop regulator-always-on for regulators that aren't critical
>> - Fix CPU and GPU regulator supply mix-up
>>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++++++++++++++++++++++++++++++
>> 2 files changed, 256 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index c00b72e750ab..78ade1a5e886 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>> sun6i-a31-m9.dtb \
>> sun6i-a31-mele-a1000g-quad.dtb \
>> sun6i-a31s-cs908.dtb \
>> + sun6i-a31s-primo81.dtb \
>> sun6i-a31s-sina31s.dtb \
>> sun6i-a31s-sinovoip-bpi-m2.dtb \
>> sun6i-a31s-yones-toptech-bs1078-v2.dtb
>> diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>> new file mode 100644
>> index 000000000000..2d4250b1faf8
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>> @@ -0,0 +1,255 @@
>> +/*
>> + * Copyright 2014 Siarhei Siamashka <siarhei.siamashka@gmail.com>
>> + * Copyright 2015 Karsten Merker <merker@debian.org>
>> + * Copyright 2015 Chen-Yu Tsai <wens@csie.org>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun6i-a31s.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "MSI Primo81 tablet";
>> + compatible = "msi,primo81", "allwinner,sun6i-a31s";
>> +};
>> +
>> +&cpu0 {
>> + cpu-supply = <®_dcdc3>;
>> +};
>> +
>> +&ehci0 {
>> + /* rtl8188etv wifi is connected here */
>> + status = "okay";
>> +};
>> +
>> +&i2c0 {
>> + /* pull-ups and device VDDIO use AXP221 DLDO3 */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c0_pins_a>;
>> + status = "failed";
>> +};
>> +
>> +&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.
Regards
ChenYu
^ permalink raw reply
* Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Chen-Yu Tsai @ 2015-10-23 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67HO5isvUxG09traLUBrBp-0Bea9cXn_O0oqBCTYtfN=w@mail.gmail.com>
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:
>>
>>> 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.
>
>>
>>> external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
>>> OTG and 3.5mm headphone jack.
>>>
>>> USB OTG is enabled in host only mode. AXP221 USB power supply and
>>> GPIO support are required for full USB OTG support.
>>>
>>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
>>> Signed-off-by: Karsten Merker <merker@debian.org>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>
>>> Changes since last submission (was part of Sinlinx SinA31s series)
>>>
>>> - Update axp22x.dtsi file name
>>> - Sort regulators
>>> - Drop URL in commit message
>>> - Drop comment for capacitive touch panel
>>> - Add simplefb regulators
>>> - Drop regulator-always-on for regulators that aren't critical
>>> - Fix CPU and GPU regulator supply mix-up
>>>
>>> ---
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++++++++++++++++++++++++++++++
>>> 2 files changed, 256 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index c00b72e750ab..78ade1a5e886 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>>> sun6i-a31-m9.dtb \
>>> sun6i-a31-mele-a1000g-quad.dtb \
>>> sun6i-a31s-cs908.dtb \
>>> + sun6i-a31s-primo81.dtb \
>>> sun6i-a31s-sina31s.dtb \
>>> sun6i-a31s-sinovoip-bpi-m2.dtb \
>>> sun6i-a31s-yones-toptech-bs1078-v2.dtb
>>> diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>>> new file mode 100644
>>> index 000000000000..2d4250b1faf8
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>>> @@ -0,0 +1,255 @@
>>> +/*
>>> + * Copyright 2014 Siarhei Siamashka <siarhei.siamashka@gmail.com>
>>> + * Copyright 2015 Karsten Merker <merker@debian.org>
>>> + * Copyright 2015 Chen-Yu Tsai <wens@csie.org>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This file is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of the
>>> + * License, or (at your option) any later version.
>>> + *
>>> + * This file is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use,
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "sun6i-a31s.dtsi"
>>> +#include "sunxi-common-regulators.dtsi"
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/input/input.h>
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>> +
>>> +/ {
>>> + model = "MSI Primo81 tablet";
>>> + compatible = "msi,primo81", "allwinner,sun6i-a31s";
>>> +};
>>> +
>>> +&cpu0 {
>>> + cpu-supply = <®_dcdc3>;
>>> +};
>>> +
>>> +&ehci0 {
>>> + /* rtl8188etv wifi is connected here */
>>> + status = "okay";
>>> +};
>>> +
>>> +&i2c0 {
>>> + /* pull-ups and device VDDIO use AXP221 DLDO3 */
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&i2c0_pins_a>;
>>> + status = "failed";
>>> +};
>>> +
>>> +&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";
You don't need the '="true"' part. Boolean properties mean true
if they exist, and false if they aren't.
>>
>> 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?
My tablet is at my office. I won't be able to test it over the weekend.
Thanks
ChenYu
^ permalink raw reply
* 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
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