Let's support Gamma LUT configuration on RK3288 SoCs.
In order to do so, this series adds a new and optional
address resource.
A separate address resource is required because on this RK3288,
the LUT address is after the MMU address, which is requested
by the iommu driver. This prevents the
On 30/09/2019 18:10, Adam Ford wrote:
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #7 from Doug Ty ---
(In reply to Marko Popovic from comment #6)
> (In reply to Doug Ty from comment #5)
> > I've been getting this too with Minecraft:
> > https://bugs.freedesktop.org/show_bug.cgi?id=111669
> >
> > For my
On Sat, Sep 28, 2019 at 10:23 PM james qian wang (Arm Technology
China) wrote:
>
> On Wed, Sep 25, 2019 at 03:58:31PM -0700, Derek Basehore wrote:
> > Devicetree systems can set panel orientation via a panel binding, but
> > there's no way, as is, to propagate this setting to the connector,
> >
On 30/09/2019 19:13, Matt Roper wrote:
> CRTC background color kernel patches were written about 2.5 years ago
> and floated on the upstream mailing list, but since no opensource
> userspace materialized, we never actually merged them. However the
> corresponding IGT test did get merged and has
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with the
divider clock implementation, I am re-working it as of now. Basically
what is wrong is that with a divider max value of say 16, the driver
attempts to craft the max value into a
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with a divider max value of say 16,
the
Hello, Greg
Sorry, I am newcomer, and I don't know why couldn't use #ifdefs? I only refer
some kernel code(V4.19) in drivers/hwtracing/intel_th/msu.c.
Could you tell me why? And I tell my workmate to avoid the same case.
If I define a config in Kconfig, and static inline function in .h file,
The previous version of this series was posted in February here:
https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html
Right before we merged this in February Maarten noticed that we should
be setting up the initial property state in a CRTC reset function (which
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
This reverts commit c87fb38df19da3362a0e20df1aad852100995ead,
which conflicts with adding driver-specific behavior in
atomic_commit_tail().
No functional changes expected on this commit, but just preparation
for the upcoming gamma LUT support.
Cc: Sean Paul
Signed-off-by: Ezequiel Garcia
---
Some platforms are not able to maintain the color transformation
state after a system suspend/resume cycle.
Set the colog_mgmt_changed flag so that CMM on the CRTCs in
the suspend state are reapplied after system resume.
Signed-off-by: Ezequiel Garcia
---
This is an RFC, and it's mostly based
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #8 from Marko Popovic ---
(In reply to Doug Ty from comment #7)
> (In reply to Marko Popovic from comment #6)
> > (In reply to Doug Ty from comment #5)
> > > I've been getting this too with Minecraft:
> > >
We should support readout and verification of crtc background color as
we do with other pipe state. Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.
At boot time
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Hi Linus,
On Mon, Sep 16, 2019 at 05:22:07PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
> > On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
> > wrote:
> >
> > > If we agree in principle, I would like to have the very first 3 patches
> > > in
On Fri, 27 Sep 2019 16:25:13 +
Parav Pandit wrote:
> Hi Alex,
>
>
> > -Original Message-
> > From: Alex Williamson
> > Sent: Tuesday, September 24, 2019 6:07 PM
> > To: Jason Wang
> > Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> > ker...@vger.kernel.org;
From: Daniel Kurtz
When setting a new display mode, dw_hdmi_setup() calls
dw_hdmi_enable_video_path(), which disables all hdmi clocks, including
the audio clock.
We should only (re-)enable the audio clock if audio was already enabled
when setting the new mode.
Without this patch, on RK3288,
Neil Armstrong writes:
> Hi Kevin,
>
> On 25/09/2019 21:31, Kevin Hilman wrote:
>> From: Kevin Hilman
>>
>> On some SoCs, the VPU is in a power-domain and needs runtime PM
>> enabled and used in order to keep the power domain on.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>>
Bring dmabuf sharing through implementing prime_import_sg_table callback.
This will help to validate userspace conformance in prime configurations
without using any actual hardware (e.g. in the cloud).
This enables kms_prime IGT testcase on vkms.
V2:
- Rodrigo: styleguide + return code check
Hi,
On Tue, Sep 24, 2019 at 02:40:54PM +0200, megous hlavni wrote:
> > > On first run of the X server, only the black screen and the layer
> > > containing the cursor is visible. Switching to console and back
> > > corrects the situation.
> > >
> > > I have dumped registers, and found out
On 30/09/2019 16:24, Robin Murphy wrote:
> Although going full "dma-coherent" ends badly due to GEM objects still
> being forcibly mapped non-cacheable, we can at least take advantage of
> Juno's ACE-lite integration to skip cache maintenance for pagetables.
>
> CC: Rob Herring
> CC: Tomeu
On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
wrote:
>
> On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > still happens with your patch applied. The machine simply gets shut down.
> >
> > dmesg can be found here:
> >
On Mon, Sep 30, 2019 at 7:48 AM Tero Kristo wrote:
>
> On 30/09/2019 15:41, Adam Ford wrote:
> > On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
> >>
> >> On 30/09/2019 09:45, Tomi Valkeinen wrote:
> >>> Hi,
> >>>
> >>> On 27/09/2019 18:47, Tomi Valkeinen wrote:
> On 27/09/2019 18:37,
From: Arnd Bergmann
This was apparently dropped by accident in a recent
cleanup, causing a build failure in some configurations now:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
function 'devm_pinctrl_get_select_default'
On Mon, Sep 30, 2019 at 9:27 AM Tomi Valkeinen wrote:
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
> > Let's see what Tero says, but yeah, something is odd here. I expected
> > the max divider to be 16 with Tero's patch, but I don't see it having
> > that effect. I can get the div to 31.
> >
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #6 from Marko Popovic ---
(In reply to Doug Ty from comment #5)
> I've been getting this too with Minecraft:
> https://bugs.freedesktop.org/show_bug.cgi?id=111669
>
> For my particular case at least, AMD_DEBUG=nodma seems to fix
On Mon, Sep 30, 2019 at 05:15:53PM +0300, Jyri Sarha wrote:
> From: Arnd Bergmann
>
> This was apparently dropped by accident in a recent
> cleanup, causing a build failure in some configurations now:
>
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
> function
Since we now have bindings for Mali Midgard GPUs, let's use them to
describe Juno's GPU subsystem, if only because we can. Juno sports a
Mali-T624 integrated behind an MMU-400 (as a gesture towards
virtualisation), in their own dedicated power domain with DVFS
controlled by the SCP.
CC: Liviu
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
CC: Rob Herring
CC: Tomeu Vizoso
Signed-off-by: Robin Murphy
---
This isn't
> Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
> >> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
> >>> As far as I can see by your second patch QXL is just using exported
> >>> (that
still happens with your patch applied. The machine simply gets shut down.
dmesg can be found here:
https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt
If there are no other things to try out, I will post the
On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> still happens with your patch applied. The machine simply gets shut down.
>
> dmesg can be found here:
>
From: Christian König
This feature is only used by vmwgfx and superflous for everybody else.
v2: use vmw_buffer_object instead of vmw_user_bo.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 --
drivers/gpu/drm/ttm/ttm_bo_util.c
Hi Steven,
On 27/09/2019 17:00, Steven Price wrote:
> On 27/09/2019 12:48, Neil Armstrong wrote:
>> Hi,
>>
>> On 27/09/2019 13:27, Neil Armstrong wrote:
>>> Hi Steven,
>>>
>>> Thanks for your prompt reaction !
>>>
>>> On 27/09/2019 12:48, Steven Price wrote:
On 27/09/2019 10:55, Steven Price
Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
>> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
>>> As far as I can see by your second patch QXL is just using exported
>>> (that is not
On 9/6/19 2:47 PM, John Stultz wrote:
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a
On 30/09/2019 17:12, Adam Ford wrote:
I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.
Sorry for all the spam, but I moved both of them to 31 from 32, and it
>
> On 05.09.19 15:34, Jaak Ristioja wrote:
> > On 05.09.19 10:14, Gerd Hoffmann wrote:
> >> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
> >>> Hello!
> >>>
> >>> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> >>> I originally filed the issue on
From: Ville Syrjälä
Add a helper to translate a rectangle to an absolute position.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6195820aa5c5..fc7c14627ee2
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> +static int system_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> +
On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
>
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> +
> Am 30.09.2019 um 16:27 schrieb Tomi Valkeinen :
>
> On 30/09/2019 17:20, Tomi Valkeinen wrote:
>
>> Let's see what Tero says, but yeah, something is odd here. I expected the
>> max divider to be 16 with Tero's patch, but I don't see it having that
>> effect. I can get the div to 31.
>> You
That is not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++
include/drm/ttm/ttm_bo_api.h | 5 --
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch should be functional
> Am 30.09.2019 um 10:53 schrieb Tero Kristo :
>
> The best action here is probably to drop the max-div value for this clock to
> 16. Can someone check this with their display setup and see what happens?
> Attached patch should do the trick.
I have checked on GTA04 and OpenPandora (DM3730
From: Ville Syrjälä
Use the new drm_rect_init() helper where appropriate.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git
From: Ville Syrjälä
Add a helper to initialize a rectangle from x/y/w/h information.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fc7c14627ee2..cd0106135b6a
From: Ville Syrjälä
Use the newly introduced drm_rect_translate_to() instead
of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller wrote:
>
>
> > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> >
> > The best action here is probably to drop the max-div value for this clock
> > to 16. Can someone check this with their display setup and see what
> > happens? Attached patch
On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > >
> > > The best action here is probably to drop the max-div value for this clock
> > > to 16. Can someone check
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I can get the div to 31.
You can see this from the clock register 0x48004e40 (CM_CLKSEL_DSS).
On 30/09/2019 15:41, Adam Ford wrote:
On Mon, Sep 30, 2019 at 3:53 AM Tero Kristo wrote:
On 30/09/2019 09:45, Tomi Valkeinen wrote:
Hi,
On 27/09/2019 18:47, Tomi Valkeinen wrote:
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > > On Tue, Sep 17, 2019
On Fri, Sep 27, 2019 at 09:39:48AM -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov
> wrote:
> >
> > > Call it "walk_page_mapping()". And talk extensively about how the
> > > locking differs a lot from the usual "walk_page_vma()" things.
> >
> > Walking mappings
On 26/09/2019 23:08, Kevin Hilman wrote:
> Neil Armstrong writes:
>
>> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
>> use the correct max fractional PLL value for G12A VPU.
>>
>> With this fix, we can finally setup the 1024x768-60 mode.
>>
>> Fixes: 202b9808f8ed
On Fri, Sep 20, 2019 at 10:15:41AM +0800, Qiang Yu wrote:
> Hi guys,
>
> I'd like to know the status of this patch? I expect a v2 adding some
> comments/macros about the high bit plan would be enough?
>
> @Raymond & @Brian do you still need another long process to send out a
> v2 patch? If so, I
On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch:
On Mon, Sep 30, 2019 at 9:04 AM Adam Ford wrote:
>
> On Mon, Sep 30, 2019 at 8:54 AM Adam Ford wrote:
> >
> > On Mon, Sep 30, 2019 at 8:39 AM H. Nikolaus Schaller
> > wrote:
> > >
> > >
> > > > Am 30.09.2019 um 10:53 schrieb Tero Kristo :
> > > >
> > > > The best action here is probably to
Hi Ayan,
Could we preserve Ray's authorship on this patch?
On Mon, Sep 30, 2019 at 04:44:38PM +, Ayan Halder wrote:
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Changes from v1:-
>
Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
states.
v2: convert to pci_dev quirk
put a proper technical explenation of the issue as a in-code comment
RFC comment (copied from last sent):
We are quite sure that there is a higher amount of bridges affected by
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
>
> Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
> to cover cases when a THP is mapped with PTEs. To me it's not a big
> stretch to make it cover multiple pages too.
I agree that is closer, but it does make
On 9/30/19 7:12 PM, Linus Torvalds wrote:
On Mon, Sep 30, 2019 at 6:04 AM Kirill A. Shutemov wrote:
Have you seen page_vma_mapped_walk()? I made it specifically for rmap code
to cover cases when a THP is mapped with PTEs. To me it's not a big
stretch to make it cover multiple pages too.
I
On 30/09/2019 17:26, Steven Price wrote:
On 30/09/2019 16:24, Robin Murphy wrote:
Although going full "dma-coherent" ends badly due to GEM objects still
being forcibly mapped non-cacheable, we can at least take advantage of
Juno's ACE-lite integration to skip cache maintenance for pagetables.
On Mon, Sep 30, 2019 at 04:24:58PM +0100, Robin Murphy wrote:
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own
On Mon, Sep 30, 2019 at 11:26 AM Steven Price wrote:
>
> On 30/09/2019 16:24, Robin Murphy wrote:
> > Although going full "dma-coherent" ends badly due to GEM objects still
> > being forcibly mapped non-cacheable, we can at least take advantage of
> > Juno's ACE-lite integration to skip cache
Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
denote the 16x16 block u-interleaved format used in Arm Utgard and
Midgard GPUs.
Changes from v1:-
1. Reserved the upper four bits (out of the 56 bits assigned to each vendor)
to denote the category of Arm specific modifiers.
On Mon, Sep 30, 2019 at 10:25 AM Robin Murphy wrote:
>
> Since we now have bindings for Mali Midgard GPUs, let's use them to
> describe Juno's GPU subsystem, if only because we can. Juno sports a
> Mali-T624 integrated behind an MMU-400 (as a gesture towards
> virtualisation), in their own
On Fri, Sep 27, 2019 at 9:59 AM Krzysztof Kozlowski wrote:
>
> On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski
> wrote:
> >
> > From: Maciej Falkowski
> >
> > Convert Samsung Image Scaler to newer dt-schema format.
> >
> > Signed-off-by: Maciej Falkowski
> > Signed-off-by: Marek Szyprowski
>
Could anyone please review the patch below & let me know if any other ideas
please?
https://patchwork.freedesktop.org/patch/332806/?series=66837=3
Thanks,
> -Original Message-
> From: S, Srinivasan
> Sent: Wednesday, September 25, 2019 8:33 PM
> To: 'Ville Syrjälä'
> Cc: Navare,
The 'debug_data' variable gets printed in debug statements without a
prior initialization in the function
hubbub1_verify_allow_pstate_change_high, as reported when building with
gcc 9.1.0:
warning: ‘debug_data’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
290 |
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #152 from ReddestDream ---
Kernel 5.4-rc1, the first kernel version that includes the Vega 20 patches
noted by Alex Deucher, is now out and in linux-mainline on Arch Linux AUR. :)
I plan to do some testing of this version over the
+Doug, Heiko:
On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> When resuming from system suspend, the DU driver is
On Fri, Sep 27, 2019 at 03:24:57PM +0200, Christian König wrote:
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
> Instead call the qxl_ttm_io_mem_reserve() function directly.
Reviewed-by: Gerd Hoffmann
The auto string detection algorithm checks if the current WLED
sink configuration is valid. It tries enabling every sink and
checks if the OVP fault is observed. Based on this information
it detects and enables the valid sink configuration.
Auto calibration will be triggered when the OVP fault
https://bugs.freedesktop.org/show_bug.cgi?id=111803
Zheng Luo changed:
What|Removed |Added
CC||viclu...@gmail.com
--- Comment #24 from
Handle the short circuit interrupt and check if the short circuit
interrupt is valid. Re-enable the module to check if it goes
away. Disable the module altogether if the short circuit event
persists.
Change-Id: Ia3f5272e1a50927467611bef4a0d2218dbeb95e6
Signed-off-by: Kiran Gunda
Reviewed-by:
On Sun, 29 Sep 2019 20:30:44 +
Simon Ser wrote:
> Hi,
>
> > On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote:
> > > Currently the property docs don't specify whether it's okay for two
> > > planes to
> > > have the same zpos value and what user-space should expect in this case.
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
Right; I never did this cleanup for not
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #25 from Zheng Luo ---
Created attachment 145589
--> https://bugs.freedesktop.org/attachment.cgi?id=145589=edit
dmesg of AMD 2500U w/ Vega 8
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111858
--- Comment #1 from HeYue ---
Created attachment 145586
--> https://bugs.freedesktop.org/attachment.cgi?id=145586=edit
kms_ccs
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111858
HeYue changed:
What|Removed |Added
i915 platform||ICL
CC|
On Fri, 6 Sep 2019 18:47:08 + John Stultz wrote:
> +/**
> + * dma_heap_get_data() - get per-heap driver data
> + * @heap: DMA-Heap to retrieve private data for
> + *
> + * Returns:
> + * The per-heap data for the heap.
> + */
> +void *dma_heap_get_data(struct dma_heap *heap);
> +
It will
25.09.2019 14:26, Thierry Reding пишет:
> From: Thierry Reding
>
> Commit Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after
> initialization") changed the initialization order of the IOMMU related
> bits but didn't update the cleanup path accordingly. This asymmetry can
> cause
On Fri, Sep 27, 2019 at 03:24:58PM +0200, Christian König wrote:
> Those are not supposed to be used by drivers.
>
> Signed-off-by: Christian König
Acked-by: Gerd Hoffmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Restructure the driver to add the support for new WLED
peripherals.
Signed-off-by: Kiran Gunda
Acked-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 395 ++--
1 file changed, 245 insertions(+), 150 deletions(-)
diff --git
WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
---
drivers/video/backlight/qcom-wled.c | 263
Rename the PM8941* references as WLED3 to make the driver
generic and have WLED support for other PMICs. Also rename
"i_boost_limit" and "i_limit" variables to "boost_i_limit"
and "string_i_limit" respectively to resemble the corresponding
register names.
Signed-off-by: Kiran Gunda
Reviewed-by:
Update the bindings with the new properties used for
PMI8998.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Rob Herring
Acked-by: Daniel Thompson
---
.../bindings/leds/backlight/qcom-wled.txt | 76 ++
1 file changed, 62 insertions(+), 14
Restructure the qcom-wled bindings for the better readability.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Rob Herring
Acked-by: Daniel Thompson
Acked-by: Pavel Machek
---
.../bindings/leds/backlight/qcom-wled.txt | 110 -
1 file
pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Acked-by: Rob Herring
Acked-by: Daniel Thompson
Acked-by: Pavel Machek
---
This patch series renames the pm8941-wled.c driver to qcom-wled.c to add
the support for multiple PMICs supported by qualcomm. This patch series
supports both PM8941 and PMI8998 WLED. The PMI8998 WLED has the support
to handle the OVP (over voltage protection) and the SC (short circuit
protection)
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #23 from mikhail.v.gavri...@gmail.com ---
Created attachment 145588
--> https://bugs.freedesktop.org/attachment.cgi?id=145588=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111858
--- Comment #2 from HeYue ---
Created attachment 145587
--> https://bugs.freedesktop.org/attachment.cgi?id=145587=edit
gem_basic
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111858
--- Comment #3 from HeYue ---
ICL D0 is Gen 11.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugzilla.kernel.org/show_bug.cgi?id=205043
Bug ID: 205043
Summary: Plugging in AC adapter after boot causes ´*ERROR*
suspend of IP block failed -22´ error
Product: Drivers
Version: 2.5
Kernel Version:
1 - 100 of 148 matches
Mail list logo
