Hello,
Paul Cercueil wrote:
> It has been replaced with the newer Ingenic NAND driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> Acked-by: Miquel Raynal
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then pl
Hello,
Paul Cercueil wrote:
> The JZ4740 boards now use the iio-hwmon driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> Acked-by: Guenter Roeck
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please emai
Hello,
Paul Cercueil wrote:
> Remove all the source files that are not used anywhere anymore.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur.
Hello,
Paul Cercueil wrote:
> Move all the platform data to devicetree.
>
> The only bit dropped is the PWM beeper, which requires the PWM driver
> to be updated. I figured it's okay to remove it here since it's really
> a non-critical device, and it'll be re-introduced soon enough.
>
> The othe
Hello,
Paul Cercueil wrote:
> It has been replaced with the more mature ingenic-battery driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> Acked-by: Sebastian Reichel
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorr
Hello,
Paul Cercueil wrote:
> The board now uses the simple-audio-card driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> Acked-by: Mark Brown
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email
Am 29.07.19 um 11:51 schrieb kernel test robot:
> Greeting,
>
> FYI, we noticed a -18.8% regression of vm-scalability.median due to commit:>
>
> commit: 90f479ae51afa45efab97afdde9b94b9660dd3e4 ("drm/mgag200: Replace
> struct mga_fbdev with generic framebuffer emulation")
> https://kernel.google
On Tue, Jul 30, 2019 at 7:50 PM Thomas Zimmermann wrote:
> Am 29.07.19 um 11:51 schrieb kernel test robot:
> > Greeting,
> >
> > FYI, we noticed a -18.8% regression of vm-scalability.median due to commit:>
> >
> > commit: 90f479ae51afa45efab97afdde9b94b9660dd3e4 ("drm/mgag200: Replace
> > struct
On Mon, Jul 29, 2019 at 1:18 AM Steven Price wrote:
>
> On 25/07/2019 18:40, Alyssa Rosenzweig wrote:
> >> Sorry, I was being sloppy again![1] I meant CPU mmapped.
> >
> > No worries, just wanted to check :)
> >
> >> Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
> >> sin
Hi
Am 30.07.19 um 20:12 schrieb Daniel Vetter:
> On Tue, Jul 30, 2019 at 7:50 PM Thomas Zimmermann wrote:
>> Am 29.07.19 um 11:51 schrieb kernel test robot:
>>> Greeting,
>>>
>>> FYI, we noticed a -18.8% regression of vm-scalability.median due to commit:>
>>>
>>> commit: 90f479ae51afa45efab97afdd
On Tue, Jul 30, 2019 at 8:50 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.07.19 um 20:12 schrieb Daniel Vetter:
> > On Tue, Jul 30, 2019 at 7:50 PM Thomas Zimmermann
> > wrote:
> >> Am 29.07.19 um 11:51 schrieb kernel test robot:
> >>> Greeting,
> >>>
> >>> FYI, we noticed a -18.8% regression of
On Tue, Jul 30, 2019 at 12:55 PM Alyssa Rosenzweig
wrote:
>
> > In any case, per process AS is a prerequisite to all this.
>
> Oh, I hadn't realized that was still a todo. In the meantime, what's the
> implication of shipping without it? (I.e. in which threat model are
> users vulnerable without i
This is dead code since 3.15. If there is no plan to use it
further, this can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/aty/aty128fb.c | 18 --
drivers/video/fbdev/aty/atyfb_base.c | 29 -
2 files changed, 47 deletio
Quoting Christian König (2019-07-30 13:15:53)
> +/**
> + * dma_fence_chain_unwrap - unwrap chain node
> + * @fence: fence which could be a chain node
> + *
> + * If the paramter is a chain node return the cotained fence, otherwise
> return
> + * the parameter itself.
> + */
s/paramter/parameter/
This is dead code since 3.15. If there is no plan to use
it further, this can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/via/via-core.c | 43 --
1 file changed, 43 deletions(-)
diff --git a/drivers/video/fbdev/via/via-core.c
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a
These are two obscure ioctl commands, in a driver that only
has compatible commands, so just let the driver handle this
itself.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/aty/atyfb_base.c | 12 +++-
fs/compat_ioctl.c| 2
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
>
> On 25/07/2019 15:59, Steven Price wrote:
> [...]
> > It would appear that in the following call sgt==NULL:
> >> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
> >> NUM_FAULT_PAGES, 0, SZ_2M
On Tue, Jul 30, 2019 at 12:59 PM Arnd Bergmann wrote:
>
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, wh
On Wed, 31 Jul 2019 at 05:00, Daniel Vetter wrote:
>
> On Tue, Jul 30, 2019 at 8:50 PM Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 30.07.19 um 20:12 schrieb Daniel Vetter:
> > > On Tue, Jul 30, 2019 at 7:50 PM Thomas Zimmermann
> > > wrote:
> > >> Am 29.07.19 um 11:51 schrieb kernel test rob
The pull request you sent on Tue, 30 Jul 2019 11:58:37 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus-hmm
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/515f12b9eeed35250d793b7c874707c33f7f6e05
Thank you!
--
Deet-doot-dot, I am a
On Thu, 25 Jul 2019 at 23:27, Daniel Vetter wrote:
>
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object all the boilerplate is
> already there and we just have to wire it up correctly.
>
> Note that gem/prime doesn't care when we
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #11 from Marek Olšák ---
I plan to disable SDMA image copies by default in dGPUs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=110575
--- Comment #7 from Marek Olšák ---
I plan to disable SDMA image copies by default on dGPUs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=110575
--- Comment #8 from Sylvain BERTRAND ---
On Tue, Jul 30, 2019 at 08:54:44PM +, bugzilla-dae...@freedesktop.org
wrote:
> I plan to disable SDMA image copies by default on dGPUs.
Is there a plan to "standardize" tiling format of frame buffer?
On Tue, Jul 30, 2019 at 08:54:44PM +, bugzilla-dae...@freedesktop.org wrote:
> I plan to disable SDMA image copies by default on dGPUs.
Is there a plan to "standardize" tiling format of frame buffer?
(to dma the right format properly from one brand of gpus to another)
--
Sylvain
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #23 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #22)
> Thanks for the log!
>
> I can reproduce the issue now by emulating the sequence using IGT. It
> doesn't seem to show up in deskt
From: Rob Clark
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generation, we can have either set of dma ops (mdp4 and dpu have
iommu wired to mdss node, which maps to toplevel drm device, bu
From: Rob Clark
Signed-off-by: Rob Clark
---
Not sure about 32b arm, but at least for aarch64 this is relatively
easy. So lets at least enable for arm64.
drivers/gpu/drm/drm_cache.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_c
On Tue, Jul 30, 2019 at 4:01 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> Not sure about 32b arm, but at least for aarch64 this is relatively
> easy. So lets at least enable for arm64.
hmm, bleh, I thought this was too easy.. I hadn't noticed that (even
though d
On 7/30/2019 3:45 AM, Daniel Vetter wrote:
> On Tue, Jul 30, 2019 at 12:24 PM Koenig, Christian
> wrote:
>>
>> Am 30.07.19 um 11:38 schrieb Daniel Vetter:
>>> On Tue, Jul 30, 2019 at 08:45:57AM +, Koenig, Christian wrote:
Snipped the feedback on struct drm_mem_region.
Will be easier to have
On 7/29/19 10:51 PM, Christoph Hellwig wrote:
The pagewalk code already passes the value as the hmask parameter.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f26d6abc4ed2..88b77a4a6a1e 1006
On 7/30/2019 2:34 AM, Daniel Vetter wrote:
> On Tue, Jul 30, 2019 at 08:45:57AM +, Koenig, Christian wrote:
>> Yeah, that looks like a good start. Just a couple of random design
>> comments/requirements.
>>
>> First of all please restructure the changes so that you more or less
>> have the f
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will a
strncpy(dest, src, strlen(src)) leads to unterminated
dest, which is dangerous.
Fix it by using strscpy.
Signed-off-by: Chuhong Yuan
---
Changes in v2:
- Check whether mode_end + 1 exceeds
the size of mode->name.
drivers/gpu/drm/drm_modes.c | 4 +++-
1 file changed, 3 insertions(+), 1
On 7/31/19 1:49 AM, Emil Velikov wrote:
> On 2019/07/31, Jan Sebastian Götte wrote:
>> Hi Emil,
>>
>> thank you for your comments.
>>
>> On 7/30/19 11:08 PM, Emil Velikov wrote:
>>> On 2019/07/30, Jan Sebastian Götte wrote:
Signed-off-by: Jan Sebastian Götte
---
include/uapi/drm/gd
In drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c,
amdgpu_ih_process calls DRM_DEBUG which calls drm_dbg and
finally calls printk.
As amdgpu_ih_process is called from an interrupt handler,
and interrupt handler should be short as possible.
As printk may lead to bogging down the system or can even
create a
https://bugs.freedesktop.org/show_bug.cgi?id=109887
--- Comment #8 from Andrew Sheldon ---
I also can confirm the problem, and it seems to have gotten worse since
5.3.0-rcX.
In past kernels, you could kind of work around it by setting slightly less
conservative undervolts and it would work. If y
On Wed, 2019-07-31 at 10:45 +0800, Fuqian Huang wrote:
> In drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c,
> amdgpu_ih_process calls DRM_DEBUG which calls drm_dbg and
> finally calls printk.
> As amdgpu_ih_process is called from an interrupt handler,
> and interrupt handler should be short as possible.
>
In drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c,
amdgpu_ih_process calls DRM_DEBUG which calls drm_dbg and
finally calls printk.
As amdgpu_ih_process is called from an interrupt handler,
and interrupt handler should be short as possible.
As printk may lead to bogging down the system or can even
create a
On Wed, 2019-07-31 at 14:24 +0800, Fuqian Huang wrote:
> In drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c,
> amdgpu_ih_process calls DRM_DEBUG which calls drm_dbg and
> finally calls printk.
> As amdgpu_ih_process is called from an interrupt handler,
> and interrupt handler should be short as possible.
>
On Wed, Jul 31, 2019 at 4:01 AM Jan Sebastian Götte wrote:
>
> On 7/31/19 1:49 AM, Emil Velikov wrote:
> > On 2019/07/31, Jan Sebastian Götte wrote:
> >> Hi Emil,
> >>
> >> thank you for your comments.
> >>
> >> On 7/30/19 11:08 PM, Emil Velikov wrote:
> >>> On 2019/07/30, Jan Sebastian Götte wrot
Am 31.07.19 um 02:51 schrieb Brian Welty:
[SNIP]
>> +/*
>> + * Memory types for drm_mem_region
>> + */
> #define DRM_MEM_SWAP?
btw what did you have in mind for this? Since we use shmem we kinda don't
know whether the BO is actually swapped out or not, at least on the
101 - 143 of 143 matches
Mail list logo
