First of all there is no need to guard GPIO request by CONFIG_OF.
It works for everybody independently on resource provider. While here,
rename the function to reflect the above.
Moreover, since we have a global dependency to OF, the rest of
conditional compilation is no-op, i.e. it's always be tr
Current code assumes that all the irqs registers offsets can be
accessed in all the hw revisions; this is not the case for some
targets that should not access some of the irq registers.
This change adds the support to selectively remove the irqs that
are not supported in some of the hw revisions.
> -Original Message-
> From: Wei Hu
> Sent: 2019年11月21日 10:47
> To: Dexuan Cui ; KY Srinivasan ;
> Haiyang Zhang ; Stephen Hemminger
> ; sas...@kernel.org; b.zolnier...@samsung.com;
> linux-hyp...@vger.kernel.org; dri-devel@lists.freedesktop.org; linux-
> fb...@vger.kernel.org; linux-ker..
On 11/20/19 6:11 PM, Ville Syrjälä wrote:
> On Wed, Nov 20, 2019 at 05:43:40PM +0100, Daniel Vetter wrote:
>> On Wed, Nov 20, 2019 at 06:25:12PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> Now that we've constrained the clipped source rectangle such
>>> that it can't have negative
On Wed, Nov 20, 2019 at 04:04:17PM +0100, Noralf Trønnes wrote:
> Den 20.11.2019 15.43, skrev Noralf Trønnes:
> > Den 20.11.2019 10.57, skrev Andy Shevchenko:
> >> First of all there is no need to guard GPIO request by CONFIG_OF.
> >> It works for everybody independently on resource provider. Whil
Add an entry for Shenzhen Frida LCD Co., Ltd.
Signed-off-by: Paul Cercueil
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.
Now, since driver became OF independent, no need to keep OF dependency.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/Kconfig | 2 +-
drivers/staging/fbtft/fbtft.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/
New GCC warns about inappropriate use of strncpy():
drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_framebuffer_alloc’:
drivers/staging/fbtft/fbtft-core.c:665:2: warning: ‘strncpy’ specified bound 16
equals destination size [-Wstringop-truncation]
665 | strncpy(info->fix.id, dev->driver
fixed31_32.h declare various variables 'static const', it's very ugly and
waste of memory.
All files that including the header file will have a copy of those
variables of their own. And that's the reason why there will be numerous
gcc '-Wunused-but-set-variable' warnings related to the variables.
Add display hw catalog changes for SC7180 target.
Changes in v1:
- Configure register offsets and capabilities for the
display hw blocks.
Changes in v2:
- mdss_irq data type has changed in the dependent
patch, accomodate the necessary changes.
- Add co-developed-by tags in the commit msg
Hi Jani,
On Wed, Nov 20, 2019 at 7:11 AM Jani Nikula wrote:
>
> On Tue, 12 Nov 2019, Rajat Jain wrote:
> > On Mon, Nov 4, 2019 at 11:41 AM Rajat Jain wrote:
> >>
> >> Certain laptops now come with panels that have integrated privacy
> >> screens on them. This patch adds support for such panels
> -Original Message-
> From: Dexuan Cui
> Sent: Wednesday, November 20, 2019 3:14 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger ;
> sas...@kernel.org; b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linu
Add changes to setup display datapath on SC7180 target.
Changes in v1:
- Add changes to support ctl_active on SC7180 target.
- While selecting the number of mixers in the topology
consider the interface width.
Changes in v2:
- Spawn topology mixer selection into separate patch (Rob Clark).
Add changes to setup display datapath on SC7180 target.
Changes in v1:
- Add changes to support ctl_active on SC7180 target.
- While selecting the number of mixers in the topology
consider the interface width.
Changes in v2:
- Spawn topology mixer selection into seperate patch (Rob Clark).
The first patch remove two set but not used variable.
The second patch make the variables in fixed31_32.h 'global'
instead of 'static'.
yu kuai (2):
drm/amd/display: remove set but not used variable 'dc_fixpt_e' and
'dc_fixpt_pi'
drm/amd/display: make various variables in fixed31_32.h 'gl
Add display hw catalog changes for SC7180 target.
Changes in v1:
- Configure register offsets and capabilities for the
display hw blocks.
Changes in v2:
- mdss_irq data type has changed in the dependent
patch, accommodate the necessary changes.
- Add co-developed-by tags in the commit ms
Hi
Am 20.11.19 um 12:47 schrieb Daniel Vetter:
> Hi all,
>
> I've been looking at dma_buf_v(un)map, with a goal to standardize
> locking for at least dynamic dma-buf exporters/importers, most likely
> by requiring dma_resv_lock. And I got questions around how this is
> supposed to work, since a b
On Wed, Nov 20, 2019 at 10:14:26AM +0800, Jason Wang wrote:
> > > I don't quite get the question here.
> > In the driver model the bus_type and foo_device are closely
> > linked.
>
> I don't get the definition of "closely linked" here. Do you think the bus
> and device implement virtual bus serie
'dc_fixpt_e' and 'dc_fixpt_pi' are set in 'fixed31_32.h'. However, they
are never used and so can be removed.
Fixes: eb0e515464e4 ("drm/amd/display: get rid of 32.32 unsigned fixed point")
Signed-off-by: yu kuai
---
drivers/gpu/drm/amd/display/include/fixed31_32.h | 2 --
1 file changed, 2 delet
Hi,
> > update-object-after-move works fine.
> >
> > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > move, trying to force re-creating the ptes).
>
> Well if it's broken the zapping wouldn't work :-)
>
> > didn't try the memory pressure thing yet.
>
> I'm surprised
Hi,
> Aside: the amdgpu isn't great because it's racy, userspace could have
> guessed the fd and already started an mmap before we managed to update
> stuff.
Can't see that race. When I read the code correctly the fd is created
and installed (using dma_buf_fd) only after dmabuf setup is finish
D32 is simple version of D71, the difference is:
- Only has one pipeline
- Drop the periph block and merge it to GCU
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 3 +-
.../arm/display/komeda/d71/d71_component.c| 2 +-
Hi All:
This series enables new product "D32" support
v2: Rebase
james qian wang (Arm Technology China) (2):
drm/komeda: Update the chip identify
drm/komeda: Enable new product D32 support
.../drm/arm/display/include/malidp_product.h | 3 +-
.../arm/display/komeda/d71/d71_component.c
1. Drop komeda-CORE product id comparison and put it into the d71_identify
2. Update pipeline node DT-binding:
(a). Skip the needless pipeline DT node.
(b). Return fail if the essential pipeline DT node is missing.
With these changes, for one family chips no need to change the DT.
v2: Rebas
On 9.10.2019 18.50, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
>> From: Daniel Stone
>>
>> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
>> over addfb.
>>
>> Changes since v1:
>> - unused modifiers set to 0 instead of DRM_FORMAT_MO
On 11/21/19 12:06 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Looks fine, but why not fold this into the patch using the flags.
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the sam
On Thu, Nov 21, 2019 at 02:54:03PM +1100, Stephen Rothwell wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> index f940526c5889..63e734a125fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
> +++ b/drivers/gpu/drm/amd/amdgpu/am
On 11/21/19 12:08 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+
On Thu, Nov 21, 2019 at 8:59 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 20.11.19 um 12:47 schrieb Daniel Vetter:
> > Hi all,
> >
> > I've been looking at dma_buf_v(un)map, with a goal to standardize
> > locking for at least dynamic dma-buf exporters/importers, most likely
> > by requiring dma_resv_
On Thu, Nov 21, 2019 at 09:10:21AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Aside: the amdgpu isn't great because it's racy, userspace could have
> > guessed the fd and already started an mmap before we managed to update
> > stuff.
>
> Can't see that race. When I read the code correctly the fd
On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > update-object-after-move works fine.
> > >
> > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > move, trying to force re-creating the ptes).
> >
> > Well if it's broken the zapping wouldn
On 11/21/19 12:10 AM, Christoph Hellwig wrote:
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
OK, I'll split them up.
thanks,
--
John Hubbard
NVIDIA
___
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
Right, I'm running t
sure, this is a issue.
but it wiil build succesed on local drm-next branch.
and you can submit this patch to fix this issue.
thanks.
Reviewed-by: Kevin Wang
From: Stephen Rothwell
Sent: Thursday, November 21, 2019 11:54 AM
To: Thomas Gleixner; Ingo Molnar; H. Pete
On Thu, Nov 21, 2019 at 9:26 AM Timo Aaltonen wrote:
>
> On 9.10.2019 18.50, Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> >> From: Daniel Stone
> >>
> >> getfb2 allows us to pass multiple planes and modifiers, just like addfb2
> >> over addfb.
> >>
> >> Ch
On Wed 20-11-19 23:13:47, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may b
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> On 11/21/19 12:03 AM, Christoph Hellwig wrote:
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews!
On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
China) wrote:
> There are some restrictions if HW works on side_by_side, expose it via
> config_id to user.
>
> Signed-off-by: James Qian Wang (Arm Technology China)
>
> ---
> drivers/gpu/drm/arm/display/include/malidp_p
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> >
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews! Say, it sounds like your view here is that
On Wed, Nov 20, 2019 at 04:24:48PM -0800, Rob Clark wrote:
> On Wed, Nov 20, 2019 at 2:56 AM Daniel Vetter wrote:
> >
> > For locking semantics it really doesn't matter when we grab the
> > ticket. But for lockdep validation it does: the acquire ctx is a fake
> > lockdep. Since other drivers might
On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> with the branch and patch applied:
> https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt
Thanks for testing. Too bad it did not help :( I suppose t
On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > update-object-after-move works fine.
> > > >
> > > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > > move, trying to
On 20/11/2019 09:57, Andy Shevchenko wrote:
> New GCC warns about inappropriate use of strncpy():
>
> drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_framebuffer_alloc’:
> drivers/staging/fbtft/fbtft-core.c:665:2: warning: ‘strncpy’ specified bound
> 16 equals destination size [-Wstringop-
On Thu, Nov 21, 2019 at 10:49:26AM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
> China) wrote:
> > There are some restrictions if HW works on side_by_side, expose it via
> > config_id to user.
> >
> > Signed-off-by: James Qian Wang (Arm T
On Thu, Nov 21, 2019 at 11:18 AM Gerd Hoffmann wrote:
>
> On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > update-object-after-move works fine.
> > > > >
> > > > > try zap mappings with mad
Use the shared address space of the drm device (see drm_open() in
drm_file.c) for dma-bufs too. That removes a difference betweem drm
device mmap vmas and dma-buf mmap vmas and fixes corner cases like
unmaps not working properly.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_prime.c | 4
Tested on qemu, with bochs (vram helpers) and cirrus (shmem helpers).
Cc'ing intel-gfx for CI coverage.
Gerd Hoffmann (2):
drm: call drm_gem_object_funcs.mmap with fake offset
drm: share address space for dma bufs
include/drm/drm_gem.h | 4 +---
drivers/gpu/drm/drm_gem.c
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem.h | 4 +---
drivers/gpu/drm/drm_gem.c | 3 ---
drivers/gp
On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > with the branch and patch applied:
> > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile
On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa
On Thu, Nov 21, 2019 at 12:08 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 12:03 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and patch
On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > with the branch and patch applied:
> > > https://gist.githubusercontent.com/karolherbst/03c4c81
On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > last week or so I found systems where the GPU was under the "PCI
> > Express Root Port" (name from lspci) and on those systems all of that
> > seems to work. So I am wondering if it's indeed just the 0x1901 one,
> > which also e
On Thu, Nov 21, 2019 at 12:17 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:03:52PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 11:14 AM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote:
> > > > with the branch and patc
On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
wrote:
>
> On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > last week or so I found systems where the GPU was under the "PCI
> > > Express Root Port" (name from lspci) and on those systems all of that
> > > seems to work. So
On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > last week or so I found systems where the GPU was under the "PCI
> > > > Express Root Po
Hi Maxime,
On Sun, Nov 3, 2019 at 11:02 PM Maxime Ripard wrote:
>
> On Fri, Nov 01, 2019 at 07:42:55PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Tue, Oct 29, 2019 at 2:24 PM Maxime Ripard wrote:
> > >
> > > On Tue, Oct 29, 2019 at 04:03:56AM +0530, Jagan Teki wrote:
> > > > > > explicit
On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week or so I
On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > wrote:
> > >
> > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote:
> > > > > last week o
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 20
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/sun4i/Kconfig | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --g
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/vc4/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/driver
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/amd/acp/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a
https://bugzilla.kernel.org/show_bug.cgi?id=205589
--- Comment #4 from p...@spth.de ---
Today, I've also installed a 5.1.21 kernel from Ubuntu on my Debian GNU/Linux
testing system, and logged into XFCE thrice. I did not see the green screen
crash with that kernel, though one I got a crash (system
https://bugzilla.kernel.org/show_bug.cgi?id=205049
--- Comment #15 from Pierre-Eric Pelloux-Prayer
(pierre-eric.pelloux-pra...@amd.com) ---
I opened a Merge Request for Mesa to address this issue:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2836
Testing it and reporting the results
On Thu, Nov 21, 2019 at 11:38:06AM +0100, Gerd Hoffmann wrote:
> The fake offset is going to stay, so change the calling convention for
> drm_gem_object_funcs.mmap to include the fake offset. Update all users
> accordingly.
Please add to the commit message:
Note that this reverts 83b8a6f242ea ("
On Mon, Nov 18, 2019 at 12:42:25PM -0500, Alex Deucher wrote:
> On Mon, Nov 18, 2019 at 3:37 AM Frederick Lawler wrote:
> >
> > Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> > added accessors for the PCI Express Capability so that drivers didn't
> > need to be aware of di
On Thu, Nov 21, 2019 at 11:38:07AM +0100, Gerd Hoffmann wrote:
> Use the shared address space of the drm device (see drm_open() in
> drm_file.c) for dma-bufs too. That removes a difference betweem drm
> device mmap vmas and dma-buf mmap vmas and fixes corner cases like
> unmaps not working properl
On Thu, Nov 21, 2019 at 02:52:59PM +0100, Daniel Vetter wrote:
> On Thu, Nov 21, 2019 at 11:38:06AM +0100, Gerd Hoffmann wrote:
> > The fake offset is going to stay, so change the calling convention for
> > drm_gem_object_funcs.mmap to include the fake offset. Update all users
> > accordingly.
>
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Link: https://lore.kernel.org/r/20191112173503.176611-2-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
include/uapi/linux/pci_regs.h | 2
From: Frederick Lawler
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_
From: Bjorn Helgaas
Use pcie_capability_read_word() and similar instead of using
pci_read_config_word() directly. Add #defines to replace some magic
numbers. Fix typos in use of Transmit Margin field.
These are currently on my pci/misc branch for v5.5. Let me know if you see
any issues.
Bjo
From: Frederick Lawler
Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
added accessors for the PCI Express Capability so that drivers didn't
need to be aware of differences between v1 and v2 of the PCI
Express Capability.
Replace pci_read_config_word() and pci_write_config_
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/c
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Link: https://lore.kernel.org/r/20191112173503.176611-4-helg...@kernel.org
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdg
On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 20
On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Wed, Nov 20, 2019 at
On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
>
> On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> >
> > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 2019 at 12:2
Reviewed-by: Alex Deucher
From: Krzysztof Kozlowski
Sent: Thursday, November 21, 2019 8:29 AM
To: linux-ker...@vger.kernel.org
Cc: Krzysztof Kozlowski ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airlie ;
Daniel Vetter ; amd-...@lis
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Thursday, November 21, 2019 9:02 AM
> To: linux-...@vger.kernel.org
> Cc: Zhou, David(ChunMing) ; Frederick Lawler
> ; Dave Airlie ; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; Bjorn Helgaas
> ;
On Thu, Nov 21, 2019 at 5:06 PM Karol Herbst wrote:
>
> On Thu, Nov 21, 2019 at 4:47 PM Rafael J. Wysocki wrote:
> >
> > On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst wrote:
> > >
> > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 2019 at 12:34:22
>-Original Message-
>From: Intel-gfx On Behalf Of Gerd
>Hoffmann
>Sent: Thursday, November 21, 2019 5:38 AM
>To: dri-devel@lists.freedesktop.org
>Cc: David Airlie ; intel-...@lists.freedesktop.org; open list
>; Maxime Ripard ; Gerd
>Hoffmann
>Subject: [Intel-gfx] [PATCH 2/2] drm: share ad
Hi Dave and Daniel,
A special thanks to our CI and to Chris here.
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html
For finding and providing the quick fix for 5.4 on time to avoid
the bad corruption with fbdev mmap.
Plus other kernel oops and corruption fixes.
There was a conflict h
Hi,
cc'ing the drm/bridge maintainers which I think are missing (Andrzej
Hajda and Neil Armstrong)
Missatge de Matthias Brugger del dia dl., 7
d’oct. 2019 a les 13:04:
>
>
>
> On 07/10/2019 10:22, Ulrich Hecht wrote:
> > From: Jitao Shi
> >
> > This patch adds drm_bridge driver for parade DSI
From: Colin Ian King
The pointer write_frame is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgp
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
>
> On 11/21/19 12:05 AM, Christoph Hellwig wrote:
> > So while this looks correct and I still really don't see the major
> > benefit of the new code organization, especially as it bloats all
> > put_page callers.
> >
> > I'd love to see code si
v2..v3:
- addressed (some) comments from Daniel Stone, Liviu Dudau, Daniel Vetter
and Brian Starkey - thank you all
In this iteration some rework has been done. The checking logic is now moved
to framebuffer_check() so it is common to all drivers. But the common part
is not good for komeda, so th
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 29
drivers/gpu/drm/rockchip/rockc
There are afbc helpers available.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 121 +--
1 file changed, 20 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 37d92a0631
These are useful for other users of afbc, e.g. rockchip.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_afbc.c| 84 +++
drivers/gpu/drm/drm_fourcc.c | 11 +++-
drivers/gpu/drm/drm_framebuffer.c | 71
AFBC helpers are available. Use those which increase code readability.
Signed-off-by: Andrzej Pietrasiewicz
---
.../drm/arm/display/komeda/komeda_framebuffer.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebu
Applied. thanks!
Alex
On Thu, Nov 21, 2019 at 11:54 AM Colin King wrote:
>
> From: Colin Ian King
>
> The pointer write_frame is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Address
On Wed, Nov 20, 2019 at 10:54 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/trace/define_trace.h:102,
> from drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h:502,
On Thu, 21 Nov 2019 at 20:21, james qian wang (Arm Technology China)
wrote:
>
> On Thu, Nov 21, 2019 at 10:49:26AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 07:12:55AM +, james qian wang (Arm Technology
> > China) wrote:
> > > There are some restrictions if HW works on side_by_s
On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote:
> > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 20
On Fri, Nov 1, 2019 at 4:37 PM Rob Herring wrote:
>
> Add missing docbook comments to madvise fields in struct
> drm_gem_shmem_object which fixes these warnings:
>
> include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member
> 'madv' not described in 'drm_gem_shmem_object'
> inc
On Wed, 20 Nov 2019 23:13:39 -0800
John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote
1 - 100 of 123 matches
Mail list logo
