Hi Mauro,
On Sun, Jun 9, 2019 at 4:29 AM Mauro Carvalho Chehab
wrote:
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new i
This is an illegal scenario, to free the fence whilst there are pending
callbacks. Currently, we emit a WARN and then cast aside the callbacks
leaving them dangling. Alternatively, we could set an error on the fence
and then signal fence so that any dependency chains from the fence can
be tidied up
Hi Jitao
Always good to see more panels added.
On Sat, Jun 08, 2019 at 03:02:29PM +0800, Jitao Shi wrote:
> Add documentation for boe tv101wum-n16 panel.
The changelog says tv101wum-n16 but the compatible says tv101wum-nl6.
Please pick the right one and be consistent. (number one '1' versus
char
Hi Jitao.
Thanks for this new nice driver - a few comments follows.
Sam
On Sat, Jun 08, 2019 at 03:02:30PM +0800, Jitao Shi wrote:
> Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
Like in the binding there is some confusion between nl6 versus n16.
Here the subject say
Hi Jitao.
Binding doc for this panel looks good.
With added description for avdd + avee it is:
Reviewed-by: Sam Ravnborg
On Sat, Jun 08, 2019 at 07:23:41PM +0800, Jitao Shi wrote:
> Add documentation for auo kd101n80-45na panel.
>
> Signed-off-by: Jitao Shi
> ---
> .../display/panel/auo,kd1
This is an illegal scenario, to free the fence whilst there are pending
callbacks. Currently, we emit a WARN and then cast aside the callbacks
leaving them dangling. Alternatively, we could set an error on the fence
and then signal fence so that any dependency chains from the fence can
be tidied up
Hi Jitao.
> +
> +enum dsi_cmd_type {
> + INIT_GENENIC_CMD,
> + INIT_DCS_CMD,
> + DELAY_CMD,
> +};
> +
> +struct panel_init_cmd {
> + enum dsi_cmd_type type;
> + size_t len;
> + const char *data;
> +};
> +
> +#define _INIT_CMD(...) { \
> + .type = INIT_GENENIC_CMD,\
> +
Hi Jitao.
Thanks for another panel driver.
The comments for the panel-boe-tv101wum-nl6 diver to extent
applies to this driver too.
Please address these and I will do a proper review of the next version.
I notice that error handlign is a little bit less in this driver.
consier what approch to use
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() is not a fence and the mmu_notifier
system will continue to reference hmm->mn until the srcu grace period
expires.
Resulting in use after free races like this:
CPU0
On Fri, Jun 07, 2019 at 03:13:00PM -0700, Ralph Campbell wrote:
> > Do you see a reason why the find_vma() ever needs to be before the
> > 'again' in my above example? range.vma does not need to be set for
> > range_register.
>
> Yes, for the GPU case, there can be many faults in an event queue
>
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
and poison bytes to detect this condition.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: Ralph Campbell
---
v2
- Keep ran
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Range functions like hmm_range_snapshot() and hmm_range_fault() call
find_vma, which requires hodling the mmget() and the mmap_sem for the mm.
Make this simpler for the callers by holding the mmget() inside the range
for the lif
05.06.2019 11:46, Thierry Reding пишет:
> From: Thierry Reding
>
> Recent versions of the DMA API debug code have started to warn about
> violations of the maximum DMA segment size. This is because the segment
> size defaults to 64 KiB, which can easily be exceeded in large buffer
> allocations s
On 6/7/19 9:05 AM, Jason Gunthorpe wrote:
If the trylock on the hmm->mirrors_sem fails the function will return
without decrementing the notifiers that were previously incremented. Since
the caller will not call invalidate_range_end() on EAGAIN this will result
in notifiers becoming permanently
On 6/7/19 11:24 AM, Ralph Campbell wrote:
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Ralph observes that hmm_range_register() can only be called by a driver
while a mirror is registered. Make this clear in the API by passing in
the
mirror structure as a parameter.
Th
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code another version of this, all
that does is skip the might_sleep() debugging in common cases, which is
not helpful.
Further, based on prior patches, we can now simplify the required condi
If the trylock on the hmm->mirrors_sem fails the function will return
without decrementing the notifiers that were previously incremented. Since
the caller will not call invalidate_range_end() on EAGAIN this will result
in notifiers becoming permanently incremented and deadlock.
If the sync_cpu_de
On Fri, Jun 07, 2019 at 11:41:20AM -0700, Ralph Campbell wrote:
>
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > So long a a struct hmm pointer exists, so should the struct mm it is
>
> s/a a/as a/
Got it, thanks
Jason
__
On Fri, Jun 07, 2019 at 12:01:45PM -0700, Ralph Campbell wrote:
>
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The wait_event_timeout macro already tests the condition as its first
> > action, so there is no reason to open code another version of this, all
> > t
On Sat, Jun 08, 2019 at 01:49:48AM -0700, Christoph Hellwig wrote:
> I still think sruct hmm should die. We already have a structure used
> for additional information for drivers having crazly tight integration
> into the VM, and it is called struct mmu_notifier_mm. We really need
> to reuse that
Hi Jason,
On Tue, May 21, 2019 at 12:27 AM Souptick Joarder wrote:
>
> Convert to use hmm_range_fault().
>
> Signed-off-by: Souptick Joarder
Would you like to take it through your new hmm tree or do I
need to resend it ?
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
> 1 file changed,
On Fri, 2019-06-07 at 17:10 +0200, Daniel Vetter wrote:
> As discussed on irc, we need tested-by here from the reporters since
> there's way too many losing and frustrangingly few winning moves here.
I'm building it now, hopefully will be done today.
--
bye,
pabs
https://bonedaddy.net/pabs3/
On 6/7/19 5:34 AM, Jason Gunthorpe wrote:
> On Thu, Jun 06, 2019 at 07:29:08PM -0700, John Hubbard wrote:
>> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
>>> From: Jason Gunthorpe
>> ...
>>> @@ -153,10 +158,14 @@ void hmm_mm_destroy(struct mm_struct *mm)
>>>
>>> static void hmm_release(struct mmu
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
> HMM defines its own struct hmm_update which is passed to the
> sync_cpu_device_pagetables() callback function. This is
> sufficient when the only action is to invalidate. However,
> a device may want to know the reason for the invali
On Sat, 2019-06-08 at 13:10 +0800, Paul Wise wrote:
> I've tested these two patches on top of Linux v5.2-rc3 and the EDID
> override works correctly on an Intel Ironlake GPU with a monitor that
> lost its EDID a while ago.
While testing I noticed a couple of things:
While everything the GUI is t
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
So we can check locking at runtime.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: Ralph Campbell
---
v2
- Fix missing & in lockdeps (Jason)
---
mm/hmm.c | 4 ++--
1 file changed, 2 insertions(+
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code another version of this, all
that does is skip the might_sleep() debugging in common cases, which is
not helpful.
F
On 6/7/19 6:31 AM, Jason Gunthorpe wrote:
> The wait_event_timeout macro already tests the condition as its first
> action, so there is no reason to open code another version of this, all
> that does is skip the might_sleep() debugging in common cases, which is
> not helpful.
>
> Further, based on
On Sat, 2019-06-08 at 13:10 +0800, Paul Wise wrote:
> I'll test that it also works with an nVidia GPU & noveau drivers
> later today once that system is available.
Same results as with the Intel GPU:
Correct screen resolution but missing EDID override data.
--
bye,
pabs
https://bonedaddy.net/
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
As coded this function can false-fail in various racy situations. Make it
reliable by running only under the write side of the mmap_sem and avoiding
the false-failing compare/exchange pattern.
Also make the locking very easy to
On Fri, Jun 07, 2019 at 02:37:07PM -0700, Ralph Campbell wrote:
>
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any action that would recurse back onto
> > hmm->mirrors_s
On Fri, Jun 07, 2019 at 09:34:32AM -0300, Jason Gunthorpe wrote:
> CH also pointed out a more elegant solution, which is to get the write
> side of the mmap_sem during hmm_mirror_unregister - no notifier
> callback can be running in this case. Then we delete the kref, srcu
> and so forth.
Oops, i
HMM defines its own struct hmm_update which is passed to the
sync_cpu_device_pagetables() callback function. This is
sufficient when the only action is to invalidate. However,
a device may want to know the reason for the invalidation and
be able to see the new permissions on a range, update device
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
No other register/unregister kernel API attempts to provide this kind of
protection as it is inherently racy, so just drop it.
Callers should provide their own protection, it appears nouveau already
does, but just in case drop a
On Sat, Jun 08, 2019 at 02:10:08AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
> > HMM defines its own struct hmm_update which is passed to the
> > sync_cpu_device_pagetables() callback function. This is
> > sufficient when the only action is to
On Fri, Jun 07, 2019 at 01:46:30PM -0700, Ralph Campbell wrote:
>
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
> > and poison bytes to detect this condition.
> >
> > Signed-off-by: Jason
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
hmm_release() is called exactly once per hmm. ops->release() cannot
accidentally trigger any action that would recurse back onto
hmm->mirrors_sem.
This fixes a use after-free race of the form:
CPU0
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
So long a a struct hmm pointer exists, so should the struct mm it is
s/a a/as a/
linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
once the hmm refcount goes to zero.
Since mmdrop() (ie a 0 kref on s
On 6/7/19 5:34 AM, Jason Gunthorpe wrote:
> On Thu, Jun 06, 2019 at 07:29:08PM -0700, John Hubbard wrote:
>> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
>>> From: Jason Gunthorpe
>> ...
>>> diff --git a/mm/hmm.c b/mm/hmm.c
>>> index 8e7403f081f44a..547002f56a163d 100644
>>> +++ b/mm/hmm.c
>> ...
>>
On Fri, Jun 7, 2019 at 12:15 AM Jason Gunthorpe wrote:
>
> From: Jason Gunthorpe
>
> So we can check locking at runtime.
Little more descriptive change log would be helpful.
Acked-by: Souptick Joarder
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
> ---
> v2
> - Fix missing
On Thu, Jun 06, 2019 at 08:47:28PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any action that would recurse back onto
> > hmm->mirrors_sem.
>
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This list is always read and written while holding hmm->lock so there is
no need for the confusing _rcu annotations.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: Ralph Campbell
---
mm/hmm.c | 4
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Ralph observes that hmm_range_register() can only be called by a driver
while a mirror is registered. Make this clear in the API by passing in the
mirror structure as a parameter.
This also simplifies understanding the lifetime
On 6/7/19 1:44 PM, Jason Gunthorpe wrote:
On Fri, Jun 07, 2019 at 01:21:12PM -0700, Ralph Campbell wrote:
What I want to get to is a pattern like this:
pagefault():
hmm_range_register(&range);
again:
/* On the slow path, if we appear to be live locked then we get
the write
On 6/7/19 12:13 PM, Jason Gunthorpe wrote:
On Fri, Jun 07, 2019 at 12:01:45PM -0700, Ralph Campbell wrote:
On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code anothe
On Thu, Jun 06, 2019 at 07:29:08PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> ...
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 8e7403f081f44a..547002f56a163d 100644
> > +++ b/mm/hmm.c
> ...
> > @@ -125,7 +130,7 @@ static void hmm_free(stru
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Signed-off-by: Wolfram Sang
---
Please apply to your subsystem tree.
drivers/gpu/drm/bridge/sii9234.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/brid
On Fri, Jun 07, 2019 at 01:21:12PM -0700, Ralph Campbell wrote:
> > What I want to get to is a pattern like this:
> >
> > pagefault():
> >
> > hmm_range_register(&range);
> > again:
> > /* On the slow path, if we appear to be live locked then we get
> >the write side of mmap_sem
On Fri, Jun 7, 2019 at 12:15 AM Jason Gunthorpe wrote:
>
> From: Jason Gunthorpe
>
> This list is always read and written while holding hmm->lock so there is
> no need for the confusing _rcu annotations.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
Acked-by: Souptick Joarder
On Thu, Jun 06, 2019 at 07:44:58PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > So long a a struct hmm pointer exists, so should the struct mm it is
> > linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
> > once
On Thu, Jun 06, 2019 at 08:37:42PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
> > and poison bytes to detect this condition.
> >
> > Signed-off-by: Jason Gunt
On Fri, Jun 07, 2019 at 04:52:58PM -0700, Ralph Campbell wrote:
> > @@ -141,6 +142,23 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > hmm_put(hmm);
> > }
> > +static void notifiers_decrement(struct hmm *hmm)
> > +{
> > + lockdep_assert_held(&hmm->ranges_lo
On Fri, 2019-06-07 at 17:10 +0200, Daniel Vetter wrote:
> As discussed on irc, we need tested-by here from the reporters since
> there's way too many losing and frustrangingly few winning moves here.
Tested-by: Paul Wise
I've tested these two patches on top of Linux v5.2-rc3 and the EDID
overri
On Thu, Jun 06, 2019 at 08:29:10PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > No other register/unregister kernel API attempts to provide this kind of
> > protection as it is inherently racy, so just drop it.
> >
> > Callers should p
On Thu, Jun 06, 2019 at 08:06:52PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The wait_event_timeout macro already tests the condition as its first
> > action, so there is no reason to open code another version of this, all
> > that d
https://bugs.freedesktop.org/show_bug.cgi?id=110865
Bug ID: 110865
Summary: Rx480 consumes 20w more power in idle than under
Windows
Product: Mesa
Version: 19.1
Hardware: Other
OS: All
Status: NE
https://bugs.freedesktop.org/show_bug.cgi?id=110866
Bug ID: 110866
Summary: Revert 8059add0478e29cb641936011a8fcc9ce9fd80be for
stable 5.1.x
Product: DRI
Version: unspecified
Hardware: Other
URL: https://bugz
On 2019-06-08 12:55, Wolfram Sang wrote:
> While preparing a refactoring series, I noticed that some drivers use a
> complicated way of determining the adapter of a client. The easy way is
> to use the intended pointer: client->adapter
>
> These drivers do:
> to_i2c_adapter(client->dev.paren
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #29 from Sam ---
I have been trying myself for the moment to get some info with just debug
parameters:
amdgpu.dc=1
amdgpu.vm_fault_stop=2
amdgpu.vm_debug=1
amdgpu.gpu_recovery=0
Incidentally I couldn't get any freeze to happen
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
> HMM defines its own struct hmm_update which is passed to the
> sync_cpu_device_pagetables() callback function. This is
> sufficient when the only action is to invalidate. However,
> a device may want to know the reason for the invali
drm_print.h requires to fix build when macros are used.
Pull in the header file in drm_print.h so users do not have to do it.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/drm_print.h | 2 ++
1 file chan
Delete the unused drmP.h from amdgpu.h.
Fix fallout in various files.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 ++--
drivers/gpu/drm/
Fix so no files in drm/amd/ depends on the
deprecated drm_os_linux.h header file.
It was done manually:
- remove drm_os_linux.h from drmP.h
- fix all build errros
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
Drop use of the deprecated drmP.h from display/dc/os_types.h
Fix all fallout after this change.
Most of the fixes was adding a missing include of vmalloc.h.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
This patcset drop all uses of drm_os_linux.h and
drmP.h in drm/amd/.
The patchset depends on the earlier series removing drmP.h
from drm/radeon.
https://lists.freedesktop.org/archives/dri-devel/2019-June/220969.html
The only dependency os the patch to drm_debugfs.h:
https://lists.freedesktop.org/a
Delete the only include of drmP.h in powerplay/.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
Drop use of the deprecated drmP.h header file from
all amd header files.
This makes it a more smooth process to get rid of drmP.h
in the .c files.
Added include files and forwards as appropriate.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc
Drop all uses of drmP.h in drm/amd/display/.
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/amd/display/am
Drop use of the deprecated drmP.h header from atom.h
Fix fallout in various files.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 1 +
drivers/gpu/drm/
Drop use of drmP.h in all files named amdgpu*
in drm/amd/amdgpu/
Fix fallout.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +-
drivers/gpu/drm/amd
With this commit drm/amd/ has no longer any uses of
the deprecated drmP.h header file.
Signed-off-by: Sam Ravnborg
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 2 +-
drivers/gpu/drm
This include is only used for some gpio drivers and consumers
that look up GPIO numbers directly from the device tree.
This driver does not use it and only needs .
Delete the unused include.
Cc: Enric Balletbo i Serra
Cc: Jose Abreu
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/bridge/analo
This converts the Analogix display port to use GPIO descriptors
instead of DT-extracted numbers.
Cc: Douglas Anderson
Cc: Sean Paul
Cc: Marek Szyprowski
Cc: Enric Balletbo i Serra
Signed-off-by: Linus Walleij
---
.../drm/bridge/analogix/analogix_dp_core.c| 28 +--
.../drm
Looks good for me:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Thu, Jun 6, 2019 at 6:59 PM Emil Velikov wrote:
>
> On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From th
https://bugs.freedesktop.org/show_bug.cgi?id=110865
Timothy Arceri changed:
What|Removed |Added
Version|19.1|DRI git
Product|Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=110313
Lakshmi changed:
What|Removed |Added
Priority|high|low
--- Comment #6 from Lakshmi ---
(In repl
Hi Liviu,
On Fri, Jun 07, 2019 at 05:05:59PM +0800, Liviu Dudau wrote:
> Hi Lowry,
>
> On Thu, Jun 06, 2019 at 10:53:05AM +0100, Lowry Li (Arm Technology China)
> wrote:
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds iommu_connect and disconnect for SMMU support, and configures
> > TB
On 6/5/19 8:48 PM, Ezequiel Garcia wrote:
Panfrost depends on the simple_ondemand governor, and therefore
it's a required configuration. Select it.
Fixes: f3617b449d ("drm/panfrost: Select devfreq")
Signed-off-by: Ezequiel Garcia
Good one, had totally forgotten about it.
Reviewed-by: Tomeu V
78 matches
Mail list logo
