Regards
Shashank
On 10/31/2018 5:35 PM, Uma Shankar wrote:
This patch adds a colorspace property enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the
Hello Uma,
My comments inline.
On 10/31/2018 5:35 PM, Uma Shankar wrote:
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type
https://bugzilla.kernel.org/show_bug.cgi?id=201605
Bug ID: 201605
Summary: amdgpu: RX 570 reboots the PC when stressed
Product: Drivers
Version: 2.5
Kernel Version: 4.19.0
Hardware: x86-64
OS: Linux
Tree:
On Fri, Nov 02, 2018 at 02:31:38PM -0700, Manasi Navare wrote:
> DSC can be supported per DP connector. This patch adds a per connector
> debugfs node to expose DSC support capability by the kernel.
> The same node can be used from userspace to force DSC enable.
>
> force_dsc_en written through
On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
> DSC params like the enable, compressed bpp, slice count and
> dsc_split are added to the intel_crtc_state. These parameters
> are set based on the requested mode and available link parameters
> during the pipe configuration in atomic
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #23 from Duncan Roe ---
Created attachment 142351
--> https://bugs.freedesktop.org/attachment.cgi?id=142351=edit
possible fix 2/2 updated for Linux 19.0
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #22 from Duncan Roe ---
Created attachment 142350
--> https://bugs.freedesktop.org/attachment.cgi?id=142350=edit
possible fix 1/2 updated for Linux 19.0
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #21 from Duncan Roe ---
Yes they fix Black X. I tested at Linux 4.19 (commit
84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d) with updated patches that apply
cleanly (to be attached).
I wonder if an approach like yours (checking
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having
This series contains a fix for a problem which is very difficult to
reproduce under normal circumstances without specialized testing
hardware, along with a fix that seems to be required for some especially
rebellious GM45 laptops.
Lyude Paul (5):
drm/i915: Fix possible race in
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750]
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.
Cc:
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the
On 2018-11-01 12:18, Sean Paul wrote:
On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the display worker thread. We can avoid these
redundant list and its protection
https://bugzilla.kernel.org/show_bug.cgi?id=201139
--- Comment #6 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
On both monitors there are no "Auto" input option. DisplayPort is selected on
both of them.
Also, I've never seen similar problem on RX 580 with the same monitors, either
on
On 2018-11-01 12:09, Sean Paul wrote:
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
DPU was using one thread per display to dispatch async
commits and vblank requests. Since clean up already happened
in msm to use the common thread for all the display commits,
display
On 2018-11-01 7:03 a.m., Dmitry V. Levin wrote:
> Consistently use types provided by via
> to fix struct kfd_ioctl_get_queue_wave_state_args userspace compilation
> errors.
>
> Fixes: 5df099e8bc83f ("drm/amdkfd: Add wavefront context save state retrieval
> ioctl")
> Signed-off-by: Dmitry V.
Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
sdm845 MTP board dtsi.
Changes in v4:
- patch introduced in the series
- move around added nodes to preserve alphabetical order (Doug Anderson)
Signed-off-by: Jeykumar Sankaran
---
Add dsi active/suspend pinctrl nodes to sdm845 SoC dts.
Changes in v4:
- patch introduced in the series
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
Reviving the patch posted by Sean initially.
This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The
patches are tested on SDM845 MTP platform using the kernel based on [1].
Part of the dependent drivers are already posted on list. Rest of the
dependencies are met using
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
It's lockless, and userspace might chance it underneath us. That's not
really a problem, all userspace gets is a slightly dysfunctional
lease with the current code. But this might change, and gcc might
decide to reload a few too many times, and then boom. So better safe
than sorry.
v2: Remove the
Allow the 10nm PHY driver to get the ref clock from the DT.
Signed-off-by: Matthias Kaehlcke
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
Get the PHY ref clock from the device tree instead of hardcoding
its name and rate.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
A separate power well 2 (PG2) is required for VDSC on eDP transcoder
whereas all other transcoders use the power wells associated with the
transcoders for VDSC.
This patch adds a helper to obtain correct power domain depending on
transcoder being used and enables/disables the power wells during
From: Gaurav K Singh
This computation of RC params happens in the atomic commit phase
during compute_config() to validate if display stream compression
can be enabled for the requested mode.
v7 (From Manasi):
* Use DRM_DEBUG instead of DRM_ERROR (Ville)
* Use Error numberinstead of -1 (Ville)
1. Disable Left/right VDSC branch in DSS Ctrl reg
depending on the number of VDSC engines being used
2. Disable joiner in DSS Ctrl reg
v4:
* Remove encoder, make crtc_state const (Ville)
v3 (From Manasi):
* Add Disable PG2 for VDSC on eDP
v2 (From Manasi):
* Use old_crtc_state to find dsc
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
Display Stream Splitter registers need to be programmed to enable
the joiner if two DSC engines are used and also to enable
the left and the right DSC engines. This happens as part of
the DSC enabling routine in the source in atomic commit.
v4:
* Remove redundant comment (Ville)
v3:
* Use
DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the
From: Gaurav K Singh
This patches does the following:
1. This patch defines all the DSC parameters as per the VESA
DSC specification. These are stored in the encoder and used
to compute the PPS parameters to be sent to the Sink.
2. Compute all the DSC parameters which are derived from DSC
state
DSC PPS secondary data packet infoframes are filled with
DSC picure parameter set metadata according to the DSC standard.
These infoframes are sent to the sink device and used during DSC
decoding.
v3:
* Rename to intel_dp_write_pps_sdp (Ville)
* Use const intel_crtc_state (Ville)
v2:
* Rebase ond
DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.
force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.
v3:
*
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the
Infoframes are used to send secondary data packets. This patch
adds support for DSC Picture parameter set secondary data packets
in the existing write_infoframe helpers.
v3:
* Unused variables cleanup (Ville)
v2:
* Rebase on drm-tip (Manasi)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha
If a eDP panel supports both PSR2 and VDSC, our HW cannot
support both at a time. Give priority to PSR2 if a requested
resolution can be supported without compression else enable
VDSC and keep PSR2 disabled.
v4:
Fix the unrealted stuff removed during rebase (Ville)
v3:
* Rebase
v2:
* Add warning
From: Gaurav K Singh
This patch enables decompression support in sink device
before link training and disables the same during the
DDI disabling.
v3 (From manasi):
* Pass bool state to enable/disable (Ville)
v2:(From Manasi)
* Change the enable/disable function to take crtc_state
instead of
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the DSC_MUX_WORD_SIZE constants
On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.
v3:
* Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville)
* Move it around TRANSCODER power domain defs (Ville)
v2:
* Fix the power well mismatch CI
Basic DSC parameters and DSC configuration data needs to be computed
for each of the requested mode during atomic check. This is
required since for certain modes, valid DSC parameters and config
data might not be computed in which case compression cannot be
enabled for that mode.
For that reason
From: "Srivatsa, Anusha"
DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.
v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Manasi
DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec
v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
This patch series addresses following comments from the previous
series: https://patchwork.freedesktop.org/series/51916/
- no FEC so should reject DSC on external DP
-> Added this to intel_dp_source_supports_dsc
- get_power_domains() thing wasn't right
-> Fixed the logic
-The potentially user
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP
On Fri, Nov 02, 2018 at 07:52:53PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 01, 2018 at 11:46:53PM -0700, Manasi Navare wrote:
> > After encoder->pre_enable() hook, after link training sequence is
> > completed, PPS registers for DSC encoder are configured using the
> > DSC state parameters in
On Fri, Nov 02, 2018 at 08:05:07AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Leases are entirely implemented within drm.ko, no need to even tempt
> > drivers into doing nasty things. And if there's really a need, we can
> > always re-export these again.
> >
> > Cc: Keith Packard
On Fri, Oct 26, 2018 at 06:49:08PM -0400, Lyude Paul wrote:
> Turns out that if you trigger an HPD storm on a system that has an MST
> topology connected to it, you'll end up causing the kernel to eventually
> hit a NULL deref:
>
> [ 332.339041] BUG: unable to handle kernel NULL pointer
Hi,
On Fri, Nov 2, 2018 at 12:42 PM Jeykumar Sankaran wrote:
>
> Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
> sdm845 MTP board dtsi.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124
>
> 1
On Fri, Nov 02, 2018 at 07:51:18PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 01, 2018 at 11:46:47PM -0700, Manasi Navare wrote:
> > If a eDP panel supports both PSR2 and VDSC, our HW cannot
> > support both at a time. Give priority to PSR2 if a requested
> > resolution can be supported without
Thanks Ville for this detailed review. I will spin this now
with the required fixes and send it over.
Manasi
On Fri, Nov 02, 2018 at 08:06:04PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 01, 2018 at 11:46:40PM -0700, Manasi Navare wrote:
> > This patch series addresses review comments on previous
Add dsi active/suspend pinctrl nodes to sdm845 SoC dts.
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index
Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
sdm845 MTP board dtsi.
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124
1 file changed, 124 insertions(+)
diff --git
On Fri, Nov 2, 2018 at 3:36 PM Andrey Grodzovsky
wrote:
>
> Since only for those ASICs gpu reset is enabled by deafult.
> Also update disable message and fix identation .
>
> Signed-off-by: Andrey Grodzovsky
> ---
> tests/amdgpu/deadlock_tests.c | 12 +++-
> 1 file changed, 7
Since only for those ASICs gpu reset is enabled by deafult.
Also update disable message and fix identation .
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c
Hi,
On Thu, Nov 1, 2018 at 7:25 PM Jeykumar Sankaran wrote:
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -978,6 +978,197 @@
> #thermal-sensor-cells = <1>;
> };
Note that your patch doesn't cleanly apply to
On Fri, Oct 26, 2018 at 06:49:09PM -0400, Lyude Paul wrote:
> Unfortunately, it seems that the HPD IRQ storm problem from the early
> days of Intel GPUs was never entirely solved, only mostly. Within the
> last couple of days, I got a bug report from one of our customers who
> had been having
There is a pplib messaging related failure currently during GPU reset. I will
put this issue on my TODO
list for later time after handling more prioritized stuff and will disable the
deadlock test suite for all non dGPU gfx8/9 ASICs until then.
Andrey
On 11/02/2018 02:14 PM, Grodzovsky,
On Fri, Nov 02, 2018 at 10:57:46AM -0700, Jeykumar Sankaran wrote:
> On 2018-11-02 07:30, Jordan Crouse wrote:
> >Devices that are bound as components should not use devm since
> >device managed memory is not freed when the component is
> >unbound.
> >
> >In particular this is an issue if the
On Thu, Nov 1, 2018 at 3:15 PM, Liam Mark wrote:
> Based on the suggestions from Laura I created a first draft for a change
> which will attempt to ensure that uncached mappings are only applied to
> ION memory who's cache lines have been cleaned.
> It does this by providing cached mappings (for
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> Add core facilities for defining unit tests; this provides a common way
> to define test cases, functions that execute code which is under test
> and determine whether the code under test behaves as expected; this also
> provides a way to group
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #7 from Alex Deucher ---
Or try a newer or older version of mesa.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #6 from Alex Deucher ---
It looks like something submitted by mesa caused a GPU hang. You might try
starting a bare X server and trying some simple OGL apps to start with.
--
You are receiving this mail because:
You are the
https://bugzilla.kernel.org/show_bug.cgi?id=201599
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Devices that are bound as components should not use devm since
device managed memory is not freed when the component is
unbound.
In particular this is an issue if the compoent bind fails
due to an -EPROBE_DEFER. In this case the bind would try again
later and any devm managed meory allocated
Hi Brendan,
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test
On 11/02/2018 02:12 PM, Alex Deucher wrote:
> On Fri, Nov 2, 2018 at 11:59 AM Grodzovsky, Andrey
> wrote:
>>
>>
>> On 11/02/2018 10:24 AM, Michel Dänzer wrote:
>>> On 2018-10-31 7:33 p.m., Andrey Grodzovsky wrote:
Illegal access will cause CP hang followed by job timeout and
recovery
On Fri, Nov 2, 2018 at 11:59 AM Grodzovsky, Andrey
wrote:
>
>
>
> On 11/02/2018 10:24 AM, Michel Dänzer wrote:
> > On 2018-10-31 7:33 p.m., Andrey Grodzovsky wrote:
> >> Illegal access will cause CP hang followed by job timeout and
> >> recovery kicking in.
> >> Also, disable the suite for all
On Thu, Nov 01, 2018 at 11:46:40PM -0700, Manasi Navare wrote:
> This patch series addresses review comments on previous DSC series:
>
> https://patchwork.freedesktop.org/series/47514/
>
> Gaurav K Singh (3):
> drm/i915/dsc: Define & Compute VESA DSC params
> drm/i915/dsc: Compute Rate
On Thu, Nov 1, 2018 at 10:32 PM Dave Airlie wrote:
>
> Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915
> link training regression fix, and a couple of minor panel/bridge fixes
> and a panel quirk.
Pulled,
Linus
On 2018-11-02 07:30, Jordan Crouse wrote:
Devices that are bound as components should not use devm since
device managed memory is not freed when the component is
unbound.
In particular this is an issue if the component bind fails
due to an -EPROBE_DEFER. In this case the bind would try again
On Thu, Nov 01, 2018 at 11:46:58PM -0700, Manasi Navare wrote:
> A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> whereas all other transcoders use the power wells associated with the
> transcoders for VDSC.
> This patch adds a helper to obtain correct power domain depending
On Thu, Nov 01, 2018 at 11:46:53PM -0700, Manasi Navare wrote:
> After encoder->pre_enable() hook, after link training sequence is
> completed, PPS registers for DSC encoder are configured using the
> DSC state parameters in intel_crtc_state as part of DSC enabling
> routine in the source. DSC
On Thu, Nov 01, 2018 at 11:46:50PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This computation of RC params happens in the atomic commit phase
> during compute_config() to validate if display stream compression
> can be enabled for the requested mode.
>
> v6 (From Manasi):
> * Use 9
On Thu, Nov 01, 2018 at 11:46:49PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This patches does the following:
>
> 1. This patch defines all the DSC parameters as per the VESA
> DSC specification. These are stored in the encoder and used
> to compute the PPS parameters to be sent to
On Thu, Nov 01, 2018 at 11:46:47PM -0700, Manasi Navare wrote:
> If a eDP panel supports both PSR2 and VDSC, our HW cannot
> support both at a time. Give priority to PSR2 if a requested
> resolution can be supported without compression else enable
> VDSC and keep PSR2 disabled.
>
> v3:
> * Rebase
On Thu, Nov 01, 2018 at 11:46:46PM -0700, Manasi Navare wrote:
> DSC params like the enable, compressed bpp, slice count and
> dsc_split are added to the intel_crtc_state. These parameters
> are set based on the requested mode and available link parameters
> during the pipe configuration in atomic
Quoting Daniel Vetter (2018-11-02 13:25:42)
> This essentially undoes
>
> commit 39868bd7668bd47308b1dfd97c212757caee764f
> Author: Chris Wilson
> Date: Tue Oct 29 08:55:58 2013 +
>
> drm: Compact booleans within struct drm_file
>
> We do lockless access to these flags everywhere,
https://bugs.freedesktop.org/show_bug.cgi?id=108507
--- Comment #6 from Vladimir Usikov ---
Hello?
Is there anybody in there?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Adam
On Thu, Nov 01, 2018 at 07:51:38AM -0500, Adam Ford wrote:
> This adds support for the Ampire am800480b3tmqw display,
> a 7" 24-bit RGB panel wtih 800x480 resolution.
>
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>
Hi Linus
On Thu, Nov 01, 2018 at 10:32:56PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik
Hello Peter,
Thank you for your feedback!
> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback
snip
> >
> > To further detail the problem, the system is vulnerable from before the
> > last write
> > performed by sii902x_i2c_bypass_select to after we confirm we need the
> > switch
> >
On 2018-11-02 13:13, Fabrizio Castro wrote:
> While adding SiI9022A support to the iwg23s board, it came
> up that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf, due to a delay the HDMI
>
Hi,
* Laurent Pinchart [181101 12:13]:
> On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote:
> > We do dispc_runtime_get/put in the HDMI driver's suspend/resume too, so
> > don't we need similar hack (as you add in dsi.c) there also?
>
> We would if we had to access HDMI registers
On 2018-11-01 18:32, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
>> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback
>
> snip
>
>>>
>>> To further detail the problem, the system is vulnerable from before the
>>> last write
>>> performed by
On 2018-11-01 17:04, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
>>> The "mux-locked" implementation was the one I first tried and I discovered
>>> it doesn't work for me, as other traffic on the parent adapter can get in
>>> the
>>> way. What we need for this
Hello Peter,
Thank you for your feedback!
snip
> > Yeah, there is some issue with locking here, and that's coming down
> > from the fact that when we call into drm_get_edid, we implicitly call
> > i2c_transfer which ultimately locks the i2c adapter, and then calls
> > into our
This adds support for the Ampire am800480b3tmqw display,
a 7" 24-bit RGB panel wtih 800x480 resolution.
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..71e878f63c5b 100644
---
In case of msm drm bind failure, dpu_mdss_destroy is triggered.
In this function, resources are freed and pm runtime disable is
called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable,
driver tries to access a memory which is already freed. This
results in kernel panic. Fix this by
The vendor-prefixes.txt file properly refers to ArcticSand
as "arctic" while the actual backlight driver and the
device tree bindings for it improperly use "arc". The
bindings are also modified to support newer backlight chips
in the arcxcnn family
Signed-off-by: Brian Dodge
---
Consistently use types provided by via
to fix struct kfd_ioctl_get_queue_wave_state_args userspace compilation errors.
Fixes: 5df099e8bc83f ("drm/amdkfd: Add wavefront context save state retrieval
ioctl")
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/kfd_ioctl.h | 10 +-
1
Support for ArcticSand arc1 and arc3 ships is added. Some ranges
and control paths are modified based on the chip id probed via
i2c. Also updates vendor prefix to arctic from arc which was a
mistake in the original driver submission
Signed-off-by: Brian Dodge
---
Hello Peter,
Again, thank you very much for your precious comments.
I'll send a patch out shortly addressing all of the comments I have received so
far,
including yours.
Cheers,
Fab
> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback
>
> On 2018-11-01 18:32, Fabrizio Castro wrote:
> >
Hello Peter,
Thank you for your feedback!
> > +static int sii902x_i2c_bypass_select(struct i2c_mux_core *mux, u32 chan_id)
> > +{
> > +struct sii902x *sii902x = i2c_mux_priv(mux);
> > +struct device *dev = >i2c->dev;
> > +unsigned long timeout;
> > +u8 status;
> > +int ret;
> > +
> > +ret =
The GOP sometimes initializes the DSI pclk at a (slightly) different freq
then the pclk which we pick. intel_pipe_config_compare() allows for this
by doing a fuzzy compare on the port_clock.
But the pclk difference not only results in the port_clock and
base.adjusted_mode.crtc_clock clocks being
While adding SiI9022A support to the iwg23s board, it came
up that when the HDMI transmitter is in pass through mode the
device is not compliant with the I2C specification anymore,
as it requires a far bigger tbuf, due to a delay the HDMI
transmitter is adding when relaying the STOP condition on
On 7/16/18 6:08 PM, Rob Herring wrote:
On Thu, Jul 12, 2018 at 11:21:53AM +0300, Stefan Mavrodiev wrote:
This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The
panel is used with different LCDs (currently from 480x272 to 1280x800).
Small EEPROM chip is used for identification, which
In case of msm drm bind failure, dpu_mdss_destroy is triggered.
In this function, resources are freed and pm runtime disable is
called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable,
driver tries to access a memory which is already freed. This
results in kernel panic. Fix this by
On 2018-11-01 12:04, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
> snip
>
>>> Yeah, there is some issue with locking here, and that's coming down
>>> from the fact that when we call into drm_get_edid, we implicitly call
>>> i2c_transfer which ultimately locks the
Hello Peter,
Thank you for your feedback!
> > The "mux-locked" implementation was the one I first tried and I discovered
> > it doesn't work for me, as other traffic on the parent adapter can get in
> > the
> > way. What we need for this device is no other traffic on the bus during the
> >
1 - 100 of 208 matches
Mail list logo
