Hello,
I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.
While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the …
[View More]same by registering devices as they are referenced by other
devices.
This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.
Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.
For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.
I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.
With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s.
Regards,
Tomeu
[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
[1] https://lkml.org/lkml/2014/5/12/452
Tomeu Vizoso (21):
regulator: core: Reduce critical area in _regulator_get
ARM: tegra: Add gpio-ranges property
ARM: tegra: Register drivers before devices
ARM: EXYNOS: Register drivers before devices
ARM i.MX6q: Register drivers before devices
of/platform: Add of_platform_device_ensure()
of/platform: Ensure device registration on lookup
gpio: Probe GPIO drivers on demand
gpio: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c master devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
arch/arm/boot/dts/tegra124.dtsi | 1 +
arch/arm/mach-exynos/exynos.c | 4 +--
arch/arm/mach-imx/mach-imx6q.c | 12 ++++-----
arch/arm/mach-tegra/tegra.c | 21 ++++++---------
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 ++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 3 +++
drivers/of/platform.c | 53 +++++++++++++++++++++++++++++++++++++
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 2 ++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 45 +++++++++++++++----------------
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/of_platform.h | 2 ++
19 files changed, 130 insertions(+), 45 deletions(-)
--
2.4.1
[View Less]
Hi All,
On some of the BYT devices, for DSI panels, the panel enable/disable signals
and backlight control are done using the Crystalcove PMIC. This series provides
support for the same and has been reviewed earlier on -
http://lists.freedesktop.org/archives/intel-gfx/2015-March/061908.html
This series addresses the review comments with two of the patches already merged
in linux-next as -
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=…http://git.kernel.org/…
[View More]cgit/linux/kernel/git/next/linux-next.git/commit/?id=…
Basically following are implemented -
1. GPIO control for panel enable/disable with GFX device as consumer
2. New PWM chip driver added for CRC PMIC based backlight control
3. i915 is modified to use the CRC gpio chip and the CRC PWM chip to do
backlight control. This is now added in the generic panel backlight
control infrastructure
All these patches have been tested on AsusT100 and working fine using
/sys/class/backlight/intel_backlight interface.
Patches are also verified on android-x86 tree for AsusT100.
Regards
Shobhit
Shobhit Kumar (8):
drivers/gpio/gpiolib: Add support for removing registered consumer
lookup table
drivers/pwm/core: Add support to remove registered consumer lookup
tables
drivers/mfd: Add lookup table for Panel Control as GPIO signal
drivers/mfd: Add PWM cell device for Crystalcove PMIC
drivers/mfd: ADD PWM lookup table for CRC PMIC based PWM
drivers/pwm: Add Crystalcove (CRC) PWM driver
drm/i915: Use the CRC gpio for panel enable/disable
drm/i915: Backlight control using CRC PMIC based PWM driver
drivers/gpio/gpiolib.c | 13 +++
drivers/gpu/drm/i915/intel_drv.h | 5 ++
drivers/gpu/drm/i915/intel_dsi.c | 38 ++++++++-
drivers/gpu/drm/i915/intel_dsi.h | 6 ++
drivers/gpu/drm/i915/intel_panel.c | 92 ++++++++++++++++++--
drivers/mfd/intel_soc_pmic_core.c | 29 +++++++
drivers/mfd/intel_soc_pmic_crc.c | 3 +
drivers/pwm/Kconfig | 7 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/core.c | 17 ++++
drivers/pwm/pwm-crc.c | 171 +++++++++++++++++++++++++++++++++++++
include/linux/gpio/machine.h | 1 +
include/linux/pwm.h | 5 ++
13 files changed, 381 insertions(+), 7 deletions(-)
create mode 100644 drivers/pwm/pwm-crc.c
--
2.1.0
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=82428
Priority: medium
Bug ID: 82428
Assignee: dri-devel(a)lists.freedesktop.org
Summary: [radeonsi,R9 270X] System lockup when using
mplayer/mpv with VDPAU
Severity: normal
Classification: Unclassified
OS: All
Reporter: custos.mentis(a)gmail.com
Hardware: Other
Status: NEW
Version: git
Component: Drivers/…
[View More]Gallium/radeonsi
Product: Mesa
With mesa from today's git repository I am getting hard system lockups while
trying to play a movie with mplayer/mpv configured to use hardware acceleration
(vdpau).
I was able to bisect the commit causing those lockups. The responsible commit
is 1c03a690bfc3265c7fefa7f87e69782a6672a9b2 "radeonsi: use gpu_address from
r600_resource".
There is no related message in the logs, since the lockup is immediate and hard
reset is required.
I use libdrm, glamour, mesa, and xf86-video-ati from today's git with
xorg-server-1.15.0; mpv-0.3.11 with libav-9.14 and libvdpau-0.7.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the
last swap buffer count that the back buffer was defined for. For
simplicity, we can reuse an existing field in the DRI2GetBuffers reply
that is not used by current drivers, the flags. Since we change the
interpretation of this flag, we also declare the semantic change with a
DRI2 parameter and depend upon the DDX to enable the change
responsibility (which is just a matter of reviewing whether the flags
field has ever been …
[View More]used for a non-zero value).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=701801
This series add the core support to X, mesa and -ati/-nouveau.
[dri2proto] Declare DRI2ParamXHasBufferAge
[xorg 1/3] dri2: Allow GetBuffers to match any format
[xorg 2/3] dri2: Pass swap-interval=0 ScheduleSwap requests to the
[xorg 3/3] dri2: Reuse unused flags in GetBuffers protocol to pass
[xf86-video-ati] dri2: Enable BufferAge support
[xf86-video-nouveau] dri2: Enable BufferAge support
[mesa 7/9] glx/dri2: Add DRI2GetParam()
[mesa 8/9] glx/dri2: Move the wait after SwapBuffers into the next
[mesa 9/9] glx/dri2: Implement getBufferAge
[View Less]
Hello,
This patch set fixes a crash in the R-Car DU driver (1/3) and adds two other
small cleanups (2/3 and 3/3). Please see individual patches for details.
Laurent Pinchart (3):
drm: rcar-du: Fix crash with groups that have less than 9 planes
drm: rcar-du: Clarify error message when encoder initialization fails
drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 ++--
drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 ++
…
[View More]drivers/gpu/drm/rcar-du/rcar_du_kms.c | 22 ++++++++++++++--------
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 5 ++---
4 files changed, 20 insertions(+), 13 deletions(-)
--
Regards,
Laurent Pinchart
[View Less]
https://bugzilla.kernel.org/show_bug.cgi?id=98751
Bug ID: 98751
Summary: radeon: multihead "no signal" on one of the monitors -
regression
Product: Drivers
Version: 2.5
Kernel Version: 4.0.3+
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)…
[View More]kernel-bugs.osdl.org
Reporter: mikkeloscar(a)gmail.com
Regression: No
Since this commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit…
one of my two monitors doesn't get a signal (it just says "no signal").
The monitors are connected to a Radeon HD 6990 card. One is connected through
HDMI and one through DVI. I'm using the radeon driver.
Most of the time it is the monitor connected through HDMI which doesn't get a
signal, but I was able to switch it around somehow by messing around with
screen orientation in X (not quite sure how to replicate or if it's even
relevant).
I tried to revert the commit in kernel 4.0.4 (latest I tried) and that solves
the problem for me.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]