https://bugzilla.kernel.org/show_bug.cgi?id=205915
--- Comment #4 from onil (o...@pm.me) ---
Please disregard comment #3, flickering still occurs when performance level is
"auto", after manually switching it to "low" or "high" flickering stops.
--
You are receiving this mail because:
You are wat
On Fri, Dec 20, 2019 at 03:54:55PM -0800, John Hubbard wrote:
> On 12/20/19 10:29 AM, Leon Romanovsky wrote:
> ...
> >> $ ./build.sh
> >> $ build/bin/run_tests.py
> >>
> >> If you get things that far I think Leon can get a reproduction for you
> >
> > I'm not so optimistic about that.
> >
>
> OK, I
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
to have separate compatible for A64 on the same driver.
DSI_SCLK uses mod clock-names on dt-bindings, so the same
is not required for A64.
On that note
- A64 require minimu
This is v14 version for Allwinner A64 MIPI-DSI support
and here is the previous version set[1]
Changes for v14:
- drop explicit regmap_exit, clk_put
Changes for v13:
- update dt-bindings for A64
- drop has_mod_clk variant
- use regmap bus clock properly
Changes for v12:
- use enum insted of oneOf+
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So, add compatible check for A31 and get mod clock accordingly.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
Changes f
regmap has special API to enable the controller bus clock while
initializing register space, and current driver is using
devm_regmap_init_mmio_clk which require to specify bus
clk_id argument as "bus"
But, the usage of clocks are varies between different Allwinner
DSI controllers. Clocking in A33
The MIPI DSI PHY controller on Allwinner A64 is similar
on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Reviewed-by: Rob Herring
Signed-off-by: Jagan Teki
---
Changes for v14:
- none
.../bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 6 +-
1 file ch
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
Changes for v14:
- none
drivers/gpu/drm/sun4i/sun6i_mi
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DCDC1 as VDD supply
- PD7 gpio for lcd enable pin
- PD6 gpio for lcd reset pin
- PD5 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by: Jagan
Hi,
On Fri, Dec 20, 2019 at 9:03 PM Artur Świgoń wrote:
>
> In the exynos-bus devfreq driver every bus is probed separately and is
IMHO, the patch description should specify the more general cause
why have to be changed. Actually, almost people might not know
the 'exynos-bus'. So, firstly, you h
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: 7ddd09fc4b745fb1d8942f95389583e08412e0cd
commit: a8109f5bc4bd6dc037bd15651c6c7f1ac00ed235 [2859/5337] drm/udl: Move
udl_handle_damage() into udl_modeset.c
reproduce:
# apt-get install sparse
Fixes: a8109f5bc4bd ("drm/udl: Move udl_handle_damage() into udl_modeset.c")
Signed-off-by: kbuild test robot
---
udl_modeset.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 22af179590536..
On Fri, Dec 20, 2019 at 01:45:33PM +, Jason Gunthorpe wrote:
On Wed, Dec 18, 2019 at 02:41:47PM -0800, Niranjana Vishwanathapura wrote:
> > +static u32 i915_svm_build_sg(struct i915_address_space *vm,
> > + struct hmm_range *range,
> > + stru
Hardware:
X399 Taichi
AMD Threadripper 1920X
Asus Radeon 5700XT
16GB of RAM
Software:
Gentoo
libdrm 2.4.100
mesa 19.2.7
amdgpudrmfb in use
I'm getting a lot of these OOPS in the log as below. Is there anything
I can do to help fix this?
Thanks,
Alex
Dec 15 10:16:53 titanium kernel: --
without the obj[0] set, we can see the following panic:
[ 29.236764] pstate: 2049 (nzCv daif +PAN -UAO)
[ 29.241532] pc : drm_gem_vram_offset+0x10/0x28 [drm_vram_helper]
[ 29.247511] lr : hibmc_plane_atomic_update+0x30/0xe0 [hibmc_drm]
[ 29.253490] sp : 003fab713a50
[ 29.256789]
This patch changes Exynos specific 'disable' and 'enable'
callback names to 'atomic_disable/enable' for the consistency.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
drivers/gpu/drm/exyno
On 12/3/19 5:42 PM, Lyude Paul wrote:
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there
On 11/22/19 6:16 PM, Lyude Paul wrote:
For eDP panels, it appears it's expected that so long as the panel is in
DPCD control mode that the brightness value is never set to 0. Instead,
if the desired effect is to set the panel's backlight to 0 we're
expected to simply turn off the backlight throug
On 11/22/19 6:16 PM, Lyude Paul wrote:
Turns out we actually already have some companies, such as Lenovo,
shipping machines with AMOLED screens that don't allow controlling the
backlight through the usual PWM interface and only allow controlling it
through the standard EDP DPCD interface. One exa
add gamma_set function, and we can also use it to adjust the brightness of the
display.
Signed-off-by: Zhihui Chen
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 37 +++
.../gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 5 +++
2 files changed, 42 insertions(+)
diff --git a/d
21 matches
Mail list logo
