On Thu, Nov 19, 2020 at 08:30:59PM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter
> wrote:
> >
> > On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 10/27/20 2:51 PM, Hans de Goede wrote:
> > > > Add missing pci_iounmap() calls to
Hi Daniel,
On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote:
>
> On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote:
> > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote:
> > > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> > > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vette
On Thu, 2020-11-19 at 09:46 -0600, Rob Herring wrote:
> On Thu, 19 Nov 2020 17:22:18 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
> >
> > Signed-off-by: Liu Ying
> > ---
> > .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 358
> >
Hi Laurentiu,
On Thu, 2020-11-19 at 19:30 +0200, Laurentiu Palcu wrote:
> Hi Liu Ying,
>
> On Thu, Nov 19, 2020 at 05:22:17PM +0800, Liu Ying wrote:
> > Hi,
> >
> >
> > This patch set introduces i.MX8qxp Display Processing Unit(DPU) DRM support.
>
> Glad to see this series out. However, someth
Hi Sebastian,
On Fri, 2020-11-20 at 00:20 +0100, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Nov 17, 2020 at 09:47:25AM +0800, Liu Ying wrote:
> > To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> > panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> >
Hi Linus,
Weekly fixes pull. This contains some fixes for sun4i/dw-hdmi probing,
then amdgpu enables arcturus hw without experimental flag and two
other fixes and a group of i915 fixes.
It also has a backported from next fix for the warn on reported in
ast/drm_gem_vram_helper code in the rc1 pull
Hi Dan,
> -Original Message-
> From: Dan Carpenter
> Sent: Monday, November 16, 2020 11:21 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; Sam Ravnborg ; dri-
> de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> Subject: [PATCH] drm/kmb: Fi
Looks good to me.
Anitha
> -Original Message-
> From: Dan Carpenter
> Sent: Monday, November 16, 2020 11:22 PM
> To: Chrisanthus, Anitha
> Cc: Dea, Edmund J ; David Airlie ;
> Daniel Vetter ; dri-devel@lists.freedesktop.org; kernel-
> janit...@vger.kernel.org
> Subject: [PATCH] drm/kmb:
Hi, Matthias:
I've provided the example for why of this patch. How do you think
about this patch?
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2020年11月2日 週一 上午8:04寫道：
>
> For each client driver, its timeout handler need to dump hardware register
> or its state machine information, and their way to dete
Hi, Chunfeng:
Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
>
> Convert HDMI PHY binding to YAML schema mediatek,hdmi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Signed-off-by: Chunfeng Yun
> Reviewed-by: Rob Herring
> ---
> v3: add Reviewed-by Rob
> v2: fix binding check warning of reg in example
> ---
> ...
Hi, Chunfeng:
Chunfeng Yun 於 2020年11月18日 週三 下午4:21寫道：
>
> Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Signed-off-by: Chunfeng Yun
> ---
> v3: new patch
> ---
> .../display/mediatek/mediatek,dsi.txt | 18 +---
> .../bindings/phy/mediatek,dsi
From: CK Hu
In the patch to be fixed, horizontal_backporch_byte become to large
for some panel, so roll back that patch. For small hfp or hbp panel,
using vm->hfront_porch + vm->hback_porch to calculate
horizontal_backporch_byte would make it negtive, so
use horizontal_backporch_byte itself to ma
Hi,
On Tue, Nov 17, 2020 at 09:47:25AM +0800, Liu Ying wrote:
> To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> have dual LVDS ports and require only a single power-supply.
> The first port receives
Applied. Thanks!
Alex
On Wed, Nov 18, 2020 at 3:18 AM Christian König
wrote:
>
> Am 18.11.20 um 03:55 schrieb Bernard Zhao:
> > Fix check_patch.pl warning:
> > WARNING: Prefer kmalloc_array over kmalloc with multiply
> > +bps = kmalloc(align_space * sizeof((*data)->bps), GFP_KERNEL);
> > WARNIN
Applied. Thanks!
Alex
On Wed, Nov 18, 2020 at 3:17 AM Christian König
wrote:
>
> Am 18.11.20 um 03:42 schrieb Bernard Zhao:
> > Fix check_patch.pl warning:
> > kmalloc_array uses number as first arg, sizeof is generally wrong.
> > +fences = kmalloc_array(sizeof(void *), id_mgr->num_ids,
> > GFP
On 2020-11-18 12:03, abhin...@codeaurora.org wrote:
Hi Stephen
On 2020-11-18 07:49, Rob Clark wrote:
On Tue, Nov 17, 2020 at 2:53 PM Stephen Boyd
wrote:
Quoting abhin...@codeaurora.org (2020-11-17 12:34:56)
> On 2020-11-17 09:26, Stephen Boyd wrote:
> > I don't know what this debug print is
Update the qos remap only if the client type changes for the plane.
This will avoid unnecessary register programming and also avoid log
spam from the dpu_vbif_set_qos_remap() function.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 17 +
drivers/gp
On 11/19/20 10:29 AM, Daniel Vetter wrote:
On Thu, Nov 19, 2020 at 10:02:28AM -0500, Andrey Grodzovsky wrote:
On 11/19/20 2:55 AM, Christian König wrote:
Am 18.11.20 um 17:20 schrieb Andrey Grodzovsky:
On 11/18/20 7:01 AM, Christian König wrote:
Am 18.11.20 um 08:39 schrieb Daniel Vetter:
O
Hi Dave and Daniel,
Here goes another round for 5.10
drm-intel-fixes-2020-11-19:
- Fix tgl power gating issue (Rodrigo)
- Memory leak fixes (Tvrtko, Chris)
- Selftest fixes (Zhang)
- Display bpc fix (Ville)
- Fix TGL MOCS for PTE tracking (Chris)
GVT Fixes: It temporarily disables VFIO edid
feat
The adjusted_mode->crtc_* fields contain the values adjusted for the
hardware, and are the ones that should be written to the registers.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git
16.11.2020 16:33, Mark Brown пишет:
> On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 20:28, Mark Brown пишет:
>
What should we do?
>
>>> As I keep saying the consumer driver should be enumerating the voltages
>>> it can set, if it can't find any and wants to c
On Thu, Nov 19, 2020 at 11:14:50AM +, Dave Stevenson wrote:
> Hi Maxime
>
> Thanks for the rewording :-)
>
> On Thu, 29 Oct 2020 at 12:25, Maxime Ripard wrote:
> >
> > The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> > per clock cycle, and cannot deal with odd timin
Hi Christoph,
On Thu, Nov 19, 2020 at 08:59:59AM +0100, Christoph Hellwig wrote:
> On Mon, Nov 09, 2020 at 10:43:03AM +0100, Maxime Ripard wrote:
> > Hi Christoph, Chen-Yu, Hans,
> >
> > On Fri, Nov 06, 2020 at 05:07:37PM +0100, Christoph Hellwig wrote:
> > > Thanks,
> > >
> > > this looks good
18.11.2020 18:30, Georgi Djakov пишет:
> On 18.11.20 0:02, Dmitry Osipenko wrote:
>> 17.11.2020 23:24, Georgi Djakov пишет:
>>> Hi Dmitry,
>>>
>>> Thank you working on this!
>>>
>>> On 15.11.20 23:29, Dmitry Osipenko wrote:
Now Internal and External memory controllers are memory interconnectio
Hi Dave, Daniel,
Here's this week round of fixes for drm-misc
Maxime
drm-misc-fixes-2020-11-19:
two patches to fix dw-hdmi bind and detection code, and one fix for
sun4i shared with arm-soc
The following changes since commit a6c40b8032b845f132abfcbcbed6bddebbcc3b4a:
drm/mcde: Fix unbalanced r
The LCD controller expects timing values in dot-clock ticks, which is 3x
the timing values in pixels when using a 3x8-bit display; but it will
count the display area size in pixels either way. Go figure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 15
On Thu, Nov 19, 2020 at 10:12:43AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 14:56 schrieb Maxime Ripard:
> > The current HVS muxing code will consider the CRTCs in a given state to
> > setup their muxing in the HVS, and disable the other CRTCs muxes.
> >
> > However, it's valid to
On Thu, Nov 19, 2020 at 10:20:25AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 29.10.20 um 14:40 schrieb Maxime Ripard:
> > There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
> > chip and some resolutions, most notably 1440p at 60Hz.
> >
> > In such a case, we can either
Hi Thomas,
On Thu, Nov 19, 2020 at 09:59:15AM +0100, Thomas Zimmermann wrote:
> Am 05.11.20 um 14:56 schrieb Maxime Ripard:
> > If a CRTC is enabled but not active, and that we're then doing a page
> > flip on another CRTC, drm_atomic_get_crtc_state will bring the first
> > CRTC state into the glo
From: Dave Airlie
> Sent: 19 November 2020 01:16
>
> On Thu, 19 Nov 2020 at 08:25, Dave Airlie wrote:
> >
> > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote:
> > >
> > > On Wed, Nov 18, 2020 at 11:01 PM David Laight
> > > wrote:
> > > >
> > > > From: Thomas Zimmermann
> > > > > Sent: 18 Nov
Hi
On Wed, Nov 18, 2020 at 10:04:55AM +0100, Maxime Ripard wrote:
> Hi,
>
> Here's a fix shared with the DMA work for sun4i that will be merged
> through arm-soc.
>
> This conflicts with the subsequent work done for sun4i and
> dma_direct_set_offset, so it would be better to merge that fix throu
Hi Thomas,
Thanks again for your review
On Thu, Nov 19, 2020 at 09:11:58AM +0100, Thomas Zimmermann wrote:
> Hi,
>
> A few suggestions below. But I'm not a native speaker.
>
> Am 05.11.20 um 14:56 schrieb Maxime Ripard:
> > We've had a number of muxing corner-cases with specific ways to reprodu
Add support for 24-bit panels that are connected through a 8-bit bus and
use delta-RGB, which means a RGB pixel ordering on odd lines, and a GBR
pixel ordering on even lines.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 7 ++-
drivers/gpu/drm/ingenic/ingenic-
The infoframes are sent at a regular interval as a data island packet,
so we don't need to wait for them to be sent when we're setting them up.
However, we do need to poll when we're disabling since the we can't
update the packet RAM until it has been sent.
Let's add a boolean flag to tell whethe
Hi,
This patchset adds support for delta-RGB panels to the ingenic-drm
driver. Delta-RGB panels have diamond-pattern subpixel layout, and
expect odd lines to have RGB subpixel ordering, and even lines to have
GBR subpixel ordering.
Such panel is used in the YLM (aka. Anbernic) RG-99, RG-300, RG-2
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5cc595a..40e3351 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19283,6 +19283,14 @@ T: git https://github.com/Xilinx/linux-xlnx.git
> F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
> F: drivers/phy/xilinx/phy-zyn
To be able to support connector operations across multiple
bridges, it is recommended that the connector should be
created by the SoC driver instead of the bridges.
Modify the tidss modesetting initialization sequence to
create the connector and attach bridges with flag
DRM_BRIDGE_ATTACH_NO_CONNEC
bus_flags can be specified by a bridge in the timings.
If the bridge provides it, Override the bus_flags when propagating
from next bridge.
Signed-off-by: Nikhil Devshatwar
Reviewed-by: Tomi Valkeinen
---
Notes:
changes from v2:
* update comment
changes from v1:
* Check for timi
Remove the old code to iterate over the bridge chain, as this is
already done by the framework.
The bridge state should have the negotiated bus format and flags.
Use these from the bridge's state.
If the bridge does not support format negotiation, error out
and fail.
Signed-off-by: Nikhil Devshatw
When removing the tidss driver, there is a warning reported by
kernel about an unhandled interrupt for mhdp driver.
[ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
... [snipped backtrace]
[ 43.330735] handlers:
[ 43.333020] [<5367c4f9>] irq_default_primary_h
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Output format is expected to be MEDIA_BUS_FMT_FIXED
Inpu
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support minimal format negotiations hooks in the drm_bridge_funcs.
Complete format negotiation can be added based on EDID data.
This patch adds the minima
This series moves the tidss to using new connectoe model, where the
SoC driver (tidss) creates the connector and all the bridges are
attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
Since the bridges do not create the connector, the bus format and
bus_flag is set after the format negotiatio
On Thu, Nov 19, 2020 at 6:51 PM Dan Carpenter wrote:
>
> On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 10/27/20 2:51 PM, Hans de Goede wrote:
> > > Add missing pci_iounmap() calls to properly unmap the memory on
> > > probe-failure and remove.
> > >
> > > Report
present in next-20201119. Details for this regression:
https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
The first error is:
[ 14.757489] Internal error: synchronous external abort:
96000210
[#1] PREEMPT SMP
Looks like yet another clock ordering setup. I guess different
Amlogic
kernelci.org, however this one
>>>>> looks valid.
>>>>>
>>>>> The bisection started with next-20201118 but the errors are still
>>>>> present in next-20201119. Details for this regression:
>>>>>
>>>>> https://ke
>>>> errors on meson-gxbb-p200.
>>>>
>>>> Reports aren't automatically sent to the public while we're
>>>> trialing new bisection features on kernelci.org, however this one
>>>> looks valid.
>>>>
>>>> T
On Thu, Nov 19, 2020 at 12:35:56PM +0100, Hans de Goede wrote:
> Hi,
>
> On 10/27/20 2:51 PM, Hans de Goede wrote:
> > Add missing pci_iounmap() calls to properly unmap the memory on
> > probe-failure and remove.
> >
> > Reported-by: kernel test robot
> > Reported-by: Dan Carpenter
> > Signed-o
Hi Liu Ying,
On Thu, Nov 19, 2020 at 05:22:17PM +0800, Liu Ying wrote:
> Hi,
>
>
> This patch set introduces i.MX8qxp Display Processing Unit(DPU) DRM support.
Glad to see this series out. However, something went wrong with it as
patch 5/8 didn't make it to dri-devel mailing list... :/
https:/
https://bugzilla.kernel.org/show_bug.cgi?id=210201
--- Comment #1 from Artur Bac (arturbac...@gmail.com) ---
What is interesting people report similar case ~1h on windows, does amdgpu is
sharing code with windows driver ?
https://www.reddit.com/r/AMDHelp/comments/jx4660/crash_rx5700xt
--
You ar
Hi
Am 19.11.20 um 15:32 schrieb Maxime Ripard:
On Thu, Nov 19, 2020 at 10:12:43AM +0100, Thomas Zimmermann wrote:
Hi
Am 05.11.20 um 14:56 schrieb Maxime Ripard:
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs m
On Thu, 19 Nov 2020 17:22:20 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
>
> Signed-off-by: Liu Ying
> ---
> .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87
> ++
> 1 file changed, 87 insertions(+)
> create mod
On Thu, 19 Nov 2020 17:22:19 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
>
> Signed-off-by: Liu Ying
> ---
> .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode
On Thu, 19 Nov 2020 17:22:18 +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
>
> Signed-off-by: Liu Ying
> ---
> .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 358
> +
> 1 file changed, 358 insertions(+)
> create mode 100644
On Thu, Nov 19, 2020 at 10:03:20AM +, Simon Ser wrote:
> - Remove duplicate doc-comments for struct members
> - Add missing @member markers for in-line member comments
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
Acked-by: Daniel Vetter
> ---
> include/uapi/drm/drm_mode.h | 66 ++
On Thu, Nov 19, 2020 at 04:27:00PM +0100, Christian König wrote:
> Am 18.11.20 um 22:15 schrieb Daniel Vetter:
> > On Wed, Nov 18, 2020 at 02:35:24PM +0100, Christian König wrote:
> > > Am 17.11.20 um 18:19 schrieb Daniel Vetter:
> > > > On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wro
On Fri, Nov 13, 2020 at 04:29:50PM +0100, Maxime Ripard wrote:
> The private objects have a gotcha that could result in a use-after-free,
> make sure it's properly documented.
>
> Signed-off-by: Maxime Ripard
> ---
> include/drm/drm_atomic.h | 18 ++
> 1 file changed, 18 insertio
On Thu, Nov 19, 2020 at 10:59:42AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 13.11.20 um 16:29 schrieb Maxime Ripard:
> > Private objects storing a state shared across all CRTCs need to be
> > carefully handled to avoid a use-after-free issue.
> >
> > The proper way to do this to track all the
On Thu, Nov 19, 2020 at 10:02:28AM -0500, Andrey Grodzovsky wrote:
>
> On 11/19/20 2:55 AM, Christian König wrote:
> > Am 18.11.20 um 17:20 schrieb Andrey Grodzovsky:
> > >
> > > On 11/18/20 7:01 AM, Christian König wrote:
> > > > Am 18.11.20 um 08:39 schrieb Daniel Vetter:
> > > > > On Tue, Nov
On Thu, Nov 19, 2020 at 09:39:48AM +0800, James Qian Wang wrote:
> From: "James Qian Wang (Arm Technology China)"
>
> Komeda HW has no special, program the update to HW is done first,
> then flip happens. So correct the sequence to hw_done() first then
> flip_done().
>
> Reported-by: Daniel Vett
Am 18.11.20 um 22:15 schrieb Daniel Vetter:
On Wed, Nov 18, 2020 at 02:35:24PM +0100, Christian König wrote:
Am 17.11.20 um 18:19 schrieb Daniel Vetter:
On Tue, Nov 17, 2020 at 03:06:15PM +0100, Christian König wrote:
Increase the ammount of system memory drivers can use to about 90% of
the to
On Wed, Nov 18, 2020 at 10:47:58AM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
> latter for new hooks or when it was nee
On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
> 16.11.2020 16:33, Mark Brown пишет:
> > No, you are failing to understand the purpose of this code. To
> > reiterate unless the device supports operating with the supply
> > physically absent then the driver should not be attempti
On Thu, Nov 19, 2020 at 9:33 AM Peilin Ye wrote:
>
> On Sat, Nov 14, 2020 at 01:22:22PM +0100, Greg Kroah-Hartman wrote:
> > Ah, here's a hint:
> > https://wiki.archlinux.org/index.php/Linux_console#Fonts
> >
> > The setfont tool should help you out here.
>
> setfont seems to work fine, I tr
On Thu, Nov 19, 2020 at 2:52 PM Simon Ser wrote:
>
> Document how to perform a GETCONNECTOR ioctl. Document the various
> struct fields. Also document how to perform a forced probe, and when
> should user-space do it.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> ---
>
On 11/19/20 2:55 AM, Christian König wrote:
Am 18.11.20 um 17:20 schrieb Andrey Grodzovsky:
On 11/18/20 7:01 AM, Christian König wrote:
Am 18.11.20 um 08:39 schrieb Daniel Vetter:
On Tue, Nov 17, 2020 at 9:07 PM Andrey Grodzovsky
wrote:
On 11/17/20 2:49 PM, Daniel Vetter wrote:
On Tue, N
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, sinc
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/
Both Christoph Hellwig and Jason Gunthorpe suggested that usage of
follow_pfn by modules should be locked down more. To do so callers
need to be able to pass the mmu_notifier subscription corresponding
to the mm_struct to follow_pfn().
This patch does the rote work of doing that in the kvm subsyst
The only safe way for non core/arch code to use follow_pfn() is
together with an mmu_notifier subscription. follow_pfn() is already
marked as _GPL and the kerneldoc explains this restriction.
This patch here enforces all this by adding a mmu_notifier argument
and verifying that it is registered fo
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is lo
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings,
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedic
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire u
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from ded
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Acked-by: Tomasz Figa
Signed-off-b
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical se
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: And
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
Hi all
Another update of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.35090
https://bugzilla.kernel.org/show_bug.cgi?id=201763
--- Comment #13 from Vadim Yanitskiy (vyanits...@sysmocom.de) ---
Here we go:
[ 582.721066] amdgpu: iceland_populate_all_memory_levels(): mclk_table has 3
entries
[ 582.721081] amdgpu: iceland_populate_all_memory_levels(): dpm_levels[0] is
3000
"val" isn't initialized on the default: errorpath.
Just return from the function if this happens.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
On 19/11/2020 13:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-19 13:42:07)
On 18/11/2020 17:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-18 16:36:01)
From: Tvrtko Ursulin
There is this long standing nit of igt/tools/intel_error_decode asserting
when you feed it an er
Document how to perform a GETCONNECTOR ioctl. Document the various
struct fields. Also document how to perform a forced probe, and when
should user-space do it.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm_mode.h | 76 ++
Quoting Tvrtko Ursulin (2020-11-19 13:42:07)
>
> On 18/11/2020 17:04, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-11-18 16:36:01)
> >> From: Tvrtko Ursulin
> >>
> >> There is this long standing nit of igt/tools/intel_error_decode asserting
> >> when you feed it an error state from a GPU
On 18/11/2020 17:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-11-18 16:36:01)
From: Tvrtko Ursulin
There is this long standing nit of igt/tools/intel_error_decode asserting
when you feed it an error state from a GPU the local libdrm does not know
of.
To fix this I need a tweak in dr
> -Original Message-
> From: Dexuan Cui
> Sent: Tuesday, November 17, 2020 7:03 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; wei@kernel.org;
> b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; linux-fb...@vger.kernel.org;
Hi Maxime
On Thu, 19 Nov 2020 at 09:20, Maxime Ripard wrote:
>
> The infoframes are sent at a regular interval as a data island packet,
> so we don't need to wait for them to be sent when we're setting them up.
>
> However, we do need to poll when we're disabling since the we can't
> update the p
e
trialing new bisection features on kernelci.org, however this one
looks valid.
The bisection started with next-20201118 but the errors are still
present in next-20201119. Details for this regression:
https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
The first error is:
[
On Thu, Nov 12, 2020 at 7:27 PM Veera Sundaram Sankaran
wrote:
>
> Some drivers have hardware capability to get the precise timestamp of
> certain events based on which the fences are triggered. This allows it
> to set accurate timestamp factoring out any software and IRQ latencies.
> Move the tim
On Thu, Nov 19, 2020 at 2:26 AM wrote:
>
> On 2020-11-13 12:45, Daniel Vetter wrote:
> > On Thu, Nov 12, 2020 at 10:27:23AM -0800, Veera Sundaram Sankaran
> > wrote:
> >> The explicit out-fences in crtc are signaled as part of vblank event,
> >> indicating all framebuffers present on the Atomic Co
Hi,
On 10/27/20 2:51 PM, Hans de Goede wrote:
> Add missing pci_iounmap() calls to properly unmap the memory on
> probe-failure and remove.
>
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Hans de Goede
For some reason the spam-filter used by Red Hat's email sy
e
trialing new bisection features on kernelci.org, however this one
looks valid.
The bisection started with next-20201118 but the errors are still
present in next-20201119. Details for this regression:
https://kernelci.org/test/case/id/5fb6196bfd0127fd68d8d902/
The first error is:
[
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [PATCH v2 11/13] drm/i915
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Sunday, November 1, 2020 3:37 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
> Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
> Sharma, Swati2
> Subject: [PATCH v2 10/13] drm/i915:
Hi Maxime
On Thu, 29 Oct 2020 at 12:25, Maxime Ripard wrote:
>
> The HDMI controller cannot go above a certain pixel rate limit depending on
> the generations, but that limit is only enforced in mode_valid at the
> moment, which means that we won't advertise modes that exceed that limit,
> but th
1 - 100 of 203 matches
Mail list logo
