commmit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
the type of variables used to store the display port data rate and
number of lanes to u8. However u8 is not sufficient to store the link
data rate of the display port.
This commit reverts the type of data rate to unsigned int.
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changed
the datatype used for storing the display port data rate to u8.
A u8 is not sufficient to store the data rate, resulting in a crash due
to incorrect calculations.
This series resolves the issue by restoring the data type chang
The Sony ACX424AKP is a command/videomode DSI panel for
mobile devices. It is used on the ST-Ericsson HREF520
reference design. We support video mode by default, but
it is possible to switch the panel into command mode
by using the bool property "dsi-command-mode".
Cc: Stephan Gerhold
Signed-off-
Am 09.01.20 um 01:15 schrieb Heiko Stübner:
> Am Mittwoch, 8. Januar 2020, 23:39:49 CET schrieb Tobias Schramm:
>> commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
>> the type of variables used to store the display port data rate and
>> number of lanes to u8. However u8 is no
On Wed, Jan 08, 2020 at 09:30:00PM -0300, Paul Cercueil wrote:
> Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD
> panel, and remove the old sharp,ls020b1dd01d.txt documentation which is
> now obsolete.
>
> Signed-off-by: Paul Cercueil
Applied to drm-misc-next, thanks
On Wed, Jan 08, 2020 at 09:29:59PM -0300, Paul Cercueil wrote:
> Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD
> panel, and remove the old giantplus,gpm740b0.txt documentation which is
> now obsolete.
>
> Signed-off-by: Paul Cercueil
Thanks,
applied to drm-misc-next.
Hi
Am 08.01.20 um 21:05 schrieb Krzysztof Kozlowski:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be conver
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: efcd1418868bc7be0eb22a57497ac20eeb831ff1 [2081/2680] drm/amdkcl: Test
whether memalloc_nofs_save() and memalloc_nofs_restore()
the parameter is the mst manager, not the port.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7e9b9b7e50cf..a4be2f82589
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 97b7d54cb4471d27e35913a98c914956be65cc2c
commit: 730758bf5a57ae27c65ba2bcdadc1c9a811502b9 [234/239] drm/dp_mst: Add
helper to trigger modeset on affected DSC MST CRTCs
reproduce: make htmldocs
If you fix the issue, kindly add
Hi Evan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: b35c23a557bb753b64082a4aa4057374bcbcca74 [2080/2680] drm/amdkcl: Test
whether kref_read() function is available
config: i386-all
Hi, Matthias:
On Wed, 2020-01-08 at 13:05 +0100, Matthias Brugger wrote:
> On 08/01/2020 12:14, Matthias Brugger wrote:
> > Hi CK,
> >
> > On 07/01/2020 03:56, CK Hu wrote:
> >> Hi, Dave, Daniel, Matthias:
> >>
> >> In mediatek-drm-next-5.6 [1], I've cherry-pick 3 patches from
> >> v5.5-next/soc
Thanks, applied to drm-misc-next.
Regards,
Qiang
On Tue, Jan 7, 2020 at 4:16 PM Andreas Baierl wrote:
>
> Am 03.01.2020 um 06:46 schrieb Vasily Khoruzhick:
> > On Wed, Jan 1, 2020 at 2:39 AM Qiang Yu wrote:
> >> drm_sched_job_timedout works with drm_sched_stop as a pair,
> >> so we'd better use
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 97b7d54cb4471d27e35913a98c914956be65cc2c
commit: ccc3c70e60b54ed29137323b6e48d2895faec88b [218/239] drm/dp_mst: Parse
FEC capability on MST ports
reproduce: make htmldocs
If you fix the issue, kindly add following tag
Reported
Hi Prike,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 034972ea50d821bd2596276c956b39f0ed9ca2dd [2071/2680] drm/amdkcl: Test
whether list_bulk_move_tail() is available
config: i386-a
Hi Rob.
On Wed, Jan 08, 2020 at 03:53:55PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/pan
Am Mittwoch, 8. Januar 2020, 23:39:49 CET schrieb Tobias Schramm:
> commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
> the type of variables used to store the display port data rate and
> number of lanes to u8. However u8 is not sufficient to store the link
> data rate of the
On Wed, 8 Jan 2020 at 15:46, Dan Carpenter wrote:
>
> We accidentally set "psb" which is a no-op instead of "*psb" so it
> generates a static checker warning. We should probably set it before
> the first error return so that it's always initialized.
You actually don't need to do either, *psb will
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ba3f85f36c2f..0c3444c62014 100644
--- a/drivers/
From: Rob Clark
Signed-off-by: Rob Clark
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documentation/devicetree/bindings/display/panel/panel-simple.ya
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changed
the datatype used for storing the display port data rate to u8.
A u8 is not sufficient to store the data rate, resulting in a crash due
to incorrect calculations.
This series resolves the issue by restoring the data types chan
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
the type of variables used to store the display port data rate and
number of lanes to u8. However u8 is not sufficient to store the link
data rate of the display port.
This commit reverts the type of both the number of lanes an
On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
>
> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
>
> > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> > regulator for their SRAM, let's add support for that.
>
> > + pfdev->regulator_sram = devm_regulator_
Hi Prike,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 8d660d16d64cb75fab00f3e78409a93394cb7d29 [2055/2680] drm/amdkcl: Test
whether drm_dev_put is available
config: i386-allyesconfi
On Thu, Jan 9, 2020 at 4:09 AM Rob Herring wrote:
> [snip]
> > void panfrost_devfreq_resume(struct panfrost_device *pfdev)
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> > b/drivers/gpu/drm/panfrost/panfrost_device.h
> > index 92d471676fc7823..581da3fe5df8b17 100644
> > --- a/driv
Hi Dave, Daniel,
A few minor fixes for 5.5. This also enables DRIVER_SYNCOBJ_TIMELINE which
has been implemented for ages, but was awaiting Khronos which has since
happened. The relevant amdvlk code is in:
https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/os/amdgpu/amdgpuDevice.cpp
The f
From: Laura Abbott
Consolodate everything under an @kernel.org address.
Signed-off-by: Laura Abbott
---
Sumit, would you be willing to take this through your tree/drm-misc?
---
.mailmap| 3 +++
MAINTAINERS | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.ma
Hi changzhu,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: f12f9b802b6dd80fdee0b7c601b8b9d59a967556 [2031/2680] drm/amdkcl: Test
if linux/overflow.h and struct_size exists
config: i38
From: Algea Cao
Adding the following freq cfg in 8-bit and 10-bit color depth:
{
4000, 6500, 7100, 8350, 8575,
8875, 10800, 11900, 16200
}
New freq has been validated by quantumdata 980.
For some freq which can't be got by only using integer freq div,
Add the hdmiphy clock as the vpll in hdmi node.
Signed-off-by: Jonas Karlman
---
arch/arm/boot/dts/rk322x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 340ed6ccb08f..16ad240d5f7f 100644
--- a/arch/
Add the hdmiphy clock as the vpll in hdmi node.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index fee896338cc1..5d8807aca62e 10
RK3228/RK3328 does not provide a stable hdmi signal at TMDS rates
above 371.25MHz (340MHz pixel clock).
Limit the pixel clock rate to 340MHz to provide a stable signal.
Also limit the pixel clock to the display reported max tmds clock.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/d
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi
The VOP on RK3328 needs to run at higher rate in order to
produce a proper 3840x2160 signal.
Signed-off-by: Jonas Karlman
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/bo
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3228.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
index d17cfb7a3ff4..25f79af22cb8 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drive
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consist
mpll_cfg/cur_ctr/phy_config is not used when phy_force_vendor is true,
lets remove them.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/d
RK3228/RK3328 can only support clock rates defined in the pre pll table.
Lets validate the mode clock rate against the pre pll config and filter
out any mode with a clock rate returning error from clk_round_rate().
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17
Prepare support for High TMDS Bit Rates used by HDMI2.0 display modes.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
ind
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
From: Huicong Xu
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-b
From: Zheng Yang
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a r
Hi Jyri, Rob, Paul, Miquel.
Following patch is now applied to drm-misc-next.
Please add your simple panels to this file so
we avoid independent bindings files for ecah panel.
I will handle the inevitable conflicts when I apply.
Sam
On Thu, Jan 02, 2020 at 11:17:11AM +0100, Sam Ravnbor
/linux-rockchip/commits/next-20200108-inno-hdmi-phy
[2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-bus-format
Regards,
Jonas
Algea Cao (1):
phy/rockchip: inno-hdmi: Support more pre-pll configuration
Huicong Xu (1):
phy/rockchip: inno-hdmi: force set_rate on power_on
Jonas
Hi Miquel.
On Mon, Jan 06, 2020 at 04:18:25PM +0100, Miquel Raynal wrote:
> Satoz is a Chinese TFT manufacturer.
> Website: http://www.sat-sz.com/English/index.html
>
> Signed-off-by: Miquel Raynal
> Acked-by: Rob Herring
I have applied this.
Can you please re-do patch 2/3 so the compatible is
On Tue, Jan 07, 2020 at 04:59:56PM +0530, Harigovindan P wrote:
> Add a compatible string to support sc7180 panel version.
>
> Changes in v1:
> -Added a compatible string to support sc7180 panel version.
> Changes in v2:
> -Removed unwanted properties from description.
> -Creatin
Hi Dave and Daniel,
Either our code is nearly perfect, or things are still slow due to holidays.
I'll choose to believe the former.
Please pull!
drm-misc-fixes-2020-01-08:
-mst: Fix NO_STOP_BIT bit offset (Wayne)
-sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu)
-fb_helper: Fix bi
Hi Benjamin.
> > +
> > +required:
> > + - compatible
> > + - power-supply
>
> Hi Sam,
>
> power-supply property should be optional like it was in
> ampire,am-480272h3tmqw-t01h.yaml
> else it looks good for me.
power-supply was discussed in PATRCH 2/2 and the conclusion was that
power-supply i
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the addre
On Wed, 2020-01-08 at 21:04 +0100, Sam Ravnborg wrote:
> Hi Daniel.
> > > > I'd replace the entire block with a "This stuff is deprecated" warning.
> > > > We
> > > > have at least a corresponding todo.rst entry.
> > >
> > > We have many situations where no drm_device is available.
> > > At least
On 1/8/20 1:05 PM, Krzysztof Kozlowski wrote:
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "con
On Wed, Jan 8, 2020 at 5:46 PM Sam Ravnborg wrote:
>
> Hi Arnd.
>
> > > > All of this is just another hack until the backlight config usage is
> > > > fixed for good. Do we really want to make this the example to copy paste
> > > > wherever we hit the issue next?
> > > >
> > > > I'm not naking, bu
On Tue, Jan 7, 2020 at 11:24 PM Nicolas Boichat wrote:
>
> The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
> devfreq, and provides OPP table with 2 sets of voltages.
>
> TODO: This is incomplete as we'll need add support for setting
> a pair of voltages as well.
>
> Signed-off-by:
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
Hi,
Changes since v1
https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add Geert's review,
4. Re-order patches so all optional
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
Hi Daniel.
> > >
> > > I'd replace the entire block with a "This stuff is deprecated" warning. We
> > > have at least a corresponding todo.rst entry.
> >
> > We have many situations where no drm_device is available.
> > At least when you a buried in drm_panel patches.
> >
> > So it is either DRM
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c53ae0e01db63d1b142681add947781668e3319c [2027/2680] drm/amdkcl: drop
kcl_dma_fence_set_error
config: i386-allyesconfig (attach
On Tue, Jan 07, 2020 at 07:17:52PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > > + * Logging when a &device * is available, but no &drm_device *
> > > + *
> > > ~
> > > + *
> > > + * DRM/Drivers can use the following fu
On Wed, Jan 08, 2020 at 05:32:26PM +0200, Jani Nikula wrote:
> On Wed, 08 Jan 2020, Arnd Bergmann wrote:
> > The i915 driver can use the backlight subsystem as an option, and usually
> > selects it when CONFIG_ACPI is set. However it is possible to configure
> > a kernel with modular backlight cla
On Wed, Jan 08, 2020 at 08:43:12AM +0300, Dan Carpenter wrote:
> We moved this code to a different file and accidentally deleted a
> newline.
>
> Signed-off-by: Dan Carpenter
Oops, thanks for catching, patch applied!
-Daniel
> ---
> drivers/gpu/drm/drm_lock.c | 3 ++-
> 1 file changed, 2 inser
On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Since zap firmware can be device specific, allow for a firmware-name
> property in the zap node to specify which firmware to load, similarly to
> the scheme used for dsp/wifi/etc.
>
> Signed-off-by: Rob Clark
> ---
Ville, could you take a look at this patch?
I have tested this on the VRR monitor here and it does parse
the detailed monitor range correctly to expose the min and max vfreq.
Also I got rid of storing the pixel clock in the info->adaptive_sync_limits
struct
since thats just themax dotclock and not
On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote:
>
> On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote:
> > Am 07.01.20 um 20:25 schrieb Tianlin Li:
> > > Right now several architectures allow their set_memory_*() family of
> > > functions to fail, but callers may not be checking the
On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote:
> On 12/6/19 12:26 PM, Hans Verkuil wrote:
> > Add a missing 'depends on DRM' for the DRM_DP_CEC config
> > option. Without that enabling DRM_DP_CEC will force CEC_CORE
> > to =y instead of =m if DRM=m as well.
> >
> > Signed-off-by: Ha
On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote:
> Am 07.01.20 um 20:25 schrieb Tianlin Li:
> > Right now several architectures allow their set_memory_*() family of
> > functions to fail, but callers may not be checking the return values.
> > If set_memory_*() returns with an error,
On Thu, Jan 02, 2020 at 12:55:15PM +0300, Wambui Karuga wrote:
> Since the if statement only checks for the value of the `id` variable,
> it can be replaced by the more concise BUG_ON() macro for error
> reporting.
> Issue found using coccinelle.
>
> Signed-off-by: Wambui Karuga
Tomi said he's o
Hi Arnd.
> > > All of this is just another hack until the backlight config usage is
> > > fixed for good. Do we really want to make this the example to copy paste
> > > wherever we hit the issue next?
> > >
> > > I'm not naking, but I'm not acking either.
> >
> > I will try to take a look at your
On 19/12/2019 12:44, Laurent Pinchart wrote:
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
con
On Wed, 2020-01-08 at 12:24 +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Julian Stecklina
> wrote:
[...]
> > + /* Hypervisor-specific device state. */
> > + void *vdev;
>
> I have no clue about the relative merits of the patch, but you can use
> the actual type for the pointer with a forw
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c3612b68d1358e8325c377ba5e1f690b39a6cea8 [1967/2680] drm/amdkcl: Test
whether drm_gem_object_put_unlocked() is available
config: i386-allyesconfig (attached as .config)
compiler
On Wed, 08 Jan 2020, Arnd Bergmann wrote:
> The i915 driver can use the backlight subsystem as an option, and usually
> selects it when CONFIG_ACPI is set. However it is possible to configure
> a kernel with modular backlight classdev support and a built-in i915
> driver, which leads to a linker e
https://bugzilla.kernel.org/show_bug.cgi?id=206017
udo (udo...@xs4all.nl) changed:
What|Removed |Added
Severity|high|blocking
--- Comment #11 from ud
Hi Lubomir,
Thank you for the patch.
On Fri, Dec 20, 2019 at 08:49:14AM +0100, Lubomir Rintel wrote:
> This is a driver for video encoder with VGA and DVI/HDMI outputs.
>
> There is no documentation for the chip -- the operation was guessed from
> what was sniffed on a Dell Wyse 3020 ThinOS term
Quoting Jani Nikula (2020-01-08 14:44:38)
> On Wed, 08 Jan 2020, Chris Wilson wrote:
> > Quoting Jani Nikula (2020-01-08 09:40:40)
> >> On Wed, 08 Jan 2020, Joonas Lahtinen
> >> wrote:
> >> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> >> Convert the use of the DRM_DEBUG_KMS() logging macro
Hi Yifan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 757a363a37449c5b612b3c7c3f62be125b1282e3 [1966/2680] drm/amdkcl: Test
whether drm_get_format_name() is available
config: i386-a
On Wed, 08 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-08 09:40:40)
>> On Wed, 08 Jan 2020, Joonas Lahtinen wrote:
>> > Quoting Wambui Karuga (2020-01-07 17:13:29)
>> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
>> >> drm_device based drm_dbg_kms() lo
On Fri, Dec 20, 2019 at 08:49:13AM +0100, Lubomir Rintel wrote:
> Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
>
> Signed-off-by: Lubomir Rintel
> ---
> .../display/bridge/chrontel,ch7033.yaml | 86 +++
> 1 file changed, 86 insertions(+)
> create mode
[ +Sudeep ]
On 08/01/2020 12:38 pm, Martin Blumenstingl wrote:
Hi Robin,
On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote:
On 07/01/2020 11:06 pm, Martin Blumenstingl wrote:
Decouple the check to see whether we want to enable devfreq for the GPU
from dev_pm_opp_set_regulators(). This is p
On Fri, 20 Dec 2019 08:49:12 +0100, Lubomir Rintel wrote:
>
> Chrontel makes encoders for video displays and perhaps other stuff.
> Their web site is http://www.chrontel.com/.
>
> Signed-off-by: Lubomir Rintel
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file chang
The i915 driver can use the backlight subsystem as an option, and usually
selects it when CONFIG_ACPI is set. However it is possible to configure
a kernel with modular backlight classdev support and a built-in i915
driver, which leads to a linker error:
drivers/gpu/drm/i915/display/intel_panel.o:
With gcc -O3 in combination with the structleak plug, the compiler can
inline very aggressively, leading to rather large stack usage:
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 'td028ttec1_prepare':
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of
2768 b
On Wed, 08 Jan 2020, Chen Zhou wrote:
> Fix build error:
> lib/crypto/chacha.c: In function chacha_permute:
> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger
> than 2048 bytes [-Wframe-larger-than=]
> }
> ^
IMO this needs a better explanation of why not having the in
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
> + if (IS_ERR(pfdev->re
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c450088041e3378cd3b78d99169e9bca8fd20a5b [1965/2680] drm/amdkcl: Test
whether drm_gem_object_lookup() wants 2 args
config: i386-allyesconfig (attached as .config)
compiler: gcc-
Am 07.01.20 um 20:25 schrieb Tianlin Li:
Right now several architectures allow their set_memory_*() family of
functions to fail, but callers may not be checking the return values.
If set_memory_*() returns with an error, call-site assumptions may be
infact wrong to assume that it would either suc
On Wed, 08 Jan 2020, Andy Shevchenko wrote:
> I forwarding this to a (sub)set of correct MLs/maintainers. Please,
> follow the instructions they give.
Thanks, already fixed by commit 9278bbb6e43c ("drm/i915/perf: Reverse a
ternary to make sparse happy") in our -next.
BR,
Jani.
>
> -- Fo
I forwarding this to a (sub)set of correct MLs/maintainers. Please,
follow the instructions they give.
-- Forwarded message -
From: Ebrahim Byagowi
Date: Mon, Dec 23, 2019 at 12:17 PM
Subject: [PATCH] drm/i915: Fix enable OA report logic
To:
Clang raises
drivers/gpu/drm/i91
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: aa5f7e64d5afdf1b60cb7594bc78632997b6eb38 [1964/2680] drm/amdkcl: Test
whether drm_universal_plane_init() wants 9 args or 8 args
On 08/01/2020 12:14, Matthias Brugger wrote:
> Hi CK,
>
> On 07/01/2020 03:56, CK Hu wrote:
>> Hi, Dave, Daniel, Matthias:
>>
>> In mediatek-drm-next-5.6 [1], I've cherry-pick 3 patches from
>> v5.5-next/soc [2] because some drm patches depend on these cmdq patches.
>> So these cmdq patches exist
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote:
> > The __force-cast that removes the __iomem here also means that
> > the 'volatile' keyword could be dropped from the argument list,
> > as it has no real effect any more, but then there are a few drivers
> > that mark their iomem point
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: f2e0d469732d27bc612df52b42094309ba5877d9 [1963/2680] drm/amdkcl: Test
whether drm_crtc_init_with_planes() wants name
config: i3
On 07/01/2020 11:06 pm, Martin Blumenstingl wrote:
Decouple the check to see whether we want to enable devfreq for the GPU
from dev_pm_opp_set_regulators(). This is preparation work for adding
back support for regulator control (which means we need to call
dev_pm_opp_set_regulators() before dev_p
1 - 100 of 165 matches
Mail list logo
