On Fri, Nov 06, 2020 at 12:20:16AM +0530, Deepak R Varma wrote:
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The idr_alloc for this driver uses 1 as start value for ID range. The
> new function idr_init_base allows IDR to set the ID lookup from base 1.
> This avoids al
On Fri, Oct 30, 2020 at 02:48:08PM +0300, Dan Carpenter wrote:
> This is freed both here and in the caller (virtio_gpu_vram_map()) so
> it's a double free. The correct place is only in the caller.
>
> Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram
> object")
> Signed-
Am 05.11.20 um 17:37 schrieb Daniel Vetter:
[SNIP]
NAK, we use this to determine if a pages belongs to the driver or not in
amdgpu for example.
Mostly used for debugging, but I would really like to keep that.
Can you pls point me at that code? A quick grep hasn't really found much at all.
See
05.11.2020 19:07, Alan Stern пишет:
> Do you really want to use the same error unwinding for opp_table values
> obtained from dev_pm_opp_set_regulators() as from
> dev_pm_opp_get_opp_table()?
They both are pointing at the same opp_table, which is refcounted.
The dev_pm_opp_set_regulators() is d
05.11.2020 05:25, Chanwoo Choi пишет:
> Hi Dmitry,
>
> You need to update the MAINTAINERS file about tegra20-devfreq.c
>
> 11343 MEMORY FREQUENCY SCALING DRIVERS FOR NVIDIA TEGRA
>
> 11344 M: Dmitry Osipenko
>
> 11345 L:
On Thu, Nov 05, 2020 at 08:17:46PM +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote:
> > commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set
> > pgprot_decrypted()") moves the pgprot_decrypted() into
> > io_remap_pfn_range(). Delete any, now c
On Thu, Nov 05, 2020 at 10:42:15AM +0100, Daniel Vetter wrote:
> On Wed, Nov 04, 2020 at 04:53:38PM +0530, Deepak R Varma wrote:
> > idr_init() uses base 0 which is an invalid identifier. The new function
> > idr_init_base allows IDR to set the ID lookup from base 1. This avoids
> > all lookups tha
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 global state, and will make us wait for its vblank
as well, even though that might never occur.
Instead of creating the list of the free ch
On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote:
>
> On 05-11-20, 11:34, Ulf Hansson wrote:
> > I am not objecting about scaling the voltage through a regulator,
> > that's fine to me. However, encoding a power domain as a regulator
> > (even if it may seem like a regulator) isn't. Well, unless Ma
We've had a number of muxing corner-cases with specific ways to reproduce
them, so let's document them to make sure they aren't lost and introduce
regressions later on.
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 22 +++
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in hdmi_runtime_get, so we should fix it.
Fixes: ac7674567c620 ("drm: omapdrm: hdmi4: Allocate the omap_hdmi data
structure dynamically")
Signed-off-by: Zhang Qilo
On 11/5/20 10:39 AM, Daniel Vetter wrote:
On Wed, Nov 04, 2020 at 01:52:00PM +0100, Marek Vasut wrote:
Enable runtime PM before registering the fbdev emulation and disable it
afterward, otherwise register access to the LTDC IP during the fbdev
emulation registration might hang the system.
The p
idr_init() uses base 0 which is an invalid identifier for this driver.
The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
ID range and it is #defined to 1. The new function idr_init_base allows
IDR to set the ID lookup from base 1. This avoids all lookups that
otherwise starts
05.11.2020 12:45, Ulf Hansson пишет:
...
> I need some more time to review this, but just a quick check found a
> few potential issues...
Thank you for starting the review! I'm pretty sure it will take a couple
revisions until all the questions will be resolved :)
> The "core-supply", that you sp
Hi Tomi,
> Am 05.11.2020 um 13:02 schrieb Tomi Valkeinen :
>
> Hi,
>
> This is third version of the series sent by Sebastian in February:
>
> https://www.spinics.net/lists/linux-omap/msg153465.html
>
> I took the patches from his git tree, and rebased on 5.10-rc2. There
> were some conflicts a
On 05-11-20, 17:18, Dmitry Osipenko wrote:
> 05.11.2020 12:58, Viresh Kumar пишет:
> >> +static void sdhci_tegra_deinit_opp_table(void *data)
> >> +{
> >> + struct device *dev = data;
> >> + struct opp_table *opp_table;
> >> +
> >> + opp_table = dev_pm_opp_get_opp_table(dev);
> >
Even though it was pointed in the review by Daniel, and I thought to have
fixed it while applying the patches, but it turns out I forgot to commit
the fixes in the process. Properly fix it this time.
Fixes: dcda7c28bff2 ("drm/vc4: kms: Add functions to create the state objects")
Signed-off-by: Max
commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set
pgprot_decrypted()") moves the pgprot_decrypted() into
io_remap_pfn_range(). Delete any, now confusing, open coded calls that
directly precede io_remap_pfn_range():
- drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_rang
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to pm_runtime_put_noidle will result in reference leak.
This two patches try to fix them in hdmi_runtime_get.
Zhang Qilong (2):
drm/omap: hdmi4: fix reference leak in hdmi_runtime_get
drm/omap: hdmi5: fix reference
On Thu, 5 Nov 2020 at 11:06, Viresh Kumar wrote:
>
> On 05-11-20, 10:45, Ulf Hansson wrote:
> > + Viresh
>
> Thanks Ulf. I found a bug in OPP core because you cc'd me here :)
Happy to help. :-)
>
> > On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote:
> > I need some more time to review this, b
idr_init() uses base 0 which is an invalid identifier for this driver.
The idr_alloc for this driver uses 1 as start value for ID range. The
new function idr_init_base allows IDR to set the ID lookup from base 1.
This avoids all lookups that otherwise starts from 0 since 0 is always
unused / availa
On Thu, Nov 5, 2020 at 5:15 AM Dmitry Osipenko wrote:
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> +static void sdhci_tegra_deinit_opp_table(void *data)
> +{
> + struct device *dev = data;
> + struct opp_table *opp_table;
> +
> + opp_table =
+ Viresh
On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote:
>
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core
05.11.2020 12:58, Viresh Kumar пишет:
>> +static void sdhci_tegra_deinit_opp_table(void *data)
>> +{
>> + struct device *dev = data;
>> + struct opp_table *opp_table;
>> +
>> + opp_table = dev_pm_opp_get_opp_table(dev);
> So you need to get an OPP table to put one :)
> You need to
On 05-11-20, 11:34, Ulf Hansson wrote:
> I am not objecting about scaling the voltage through a regulator,
> that's fine to me. However, encoding a power domain as a regulator
> (even if it may seem like a regulator) isn't. Well, unless Mark Brown
> has changed his mind about this.
>
> In this case
On Thu, Nov 05, 2020 at 12:36:25AM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, November 04, 2020 4:07 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian K
On Thu, Nov 05, 2020 at 12:16:34PM +0100, Daniel Vetter wrote:
> On Thu, Nov 5, 2020 at 11:31 AM Deepak R Varma wrote:
> >
> > On Thu, Nov 05, 2020 at 10:42:15AM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 04, 2020 at 04:53:38PM +0530, Deepak R Varma wrote:
> > > > idr_init() uses base 0 which i
On 05-11-20, 10:45, Ulf Hansson wrote:
> + Viresh
Thanks Ulf. I found a bug in OPP core because you cc'd me here :)
> On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote:
> I need some more time to review this, but just a quick check found a
> few potential issues...
>
> The "core-supply", that
On 05-11-20, 11:24, Rob Clark wrote:
> On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
> >
> > On 03-11-20, 08:50, Rob Clark wrote:
> > > sorry, it didn't apply cleanly (which I guess is due to some other
> > > dependencies that need to be picked back to v5.4 product kernel), and
> > > due to s
idr_init() uses base 0 which is an invalid identifier. The new function
idr_init_base allows IDR to set the ID lookup from base 1. This avoids
all lookups that otherwise starts from 0 since 0 is always unused.
References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
Signed-off-by
Hi!
On Mon, Nov 02, 2020 at 05:47:04PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
>
> Thanks for V2 patch.
>
>
> On 10/28/20 9:41 PM, Maxime Ripard wrote:
> > 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 muxe
Hello,
This patchset updates the dev_pm_opp_put_*() helpers to accept a NULL
pointer for the OPP table, in order to allow the callers to drop the
unnecessary checks they had to carry.
All these must get merged upstream through the OPP tree as there is a
hard dependency on the first patch here. Th
> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen :
>
> Hi,
>
> On 05/11/2020 19:15, H. Nikolaus Schaller wrote:
>
>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for
>> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And
>> I followed the latest ex
dev_pm_opp_find_freq_exact never return null but ERR_PTR(),so we
should use IS_ERR() to clarify and avoid compilation warnings.
Signed-off-by: Wang Qing
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6
pm_runtime_get_sync will increment pm usage counter even it
failed. Forgetting to pm_runtime_put_noidle will result in
reference leak in hdmi_runtime_get, so we should fix it.
Fixes: c44991ce21bef ("drm: omapdrm: hdmi5: Allocate the omap_hdmi data
structure dynamically")
Signed-off-by: Zhang Qilo
On Thu, Nov 05, 2020 at 02:48:05PM -0800, Jianxin Xiong wrote:
> + /* modify the sgl in-place to match umem address and length */
> +
> + start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
> + end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
> + P
On Tue, Nov 03, 2020 at 09:43:17PM +0100, Daniel Vetter wrote:
> > > Yeah definitely don't call dma_buf_map_attachment and expect a page back.
> > > In practice you'll get a page back fairly often, but I don't think
> > > we want to bake that in, maybe we eventually get to non-hacky dma_addr_t
>
The code that assigns HVS channels during atomic_check is starting to grow
a bit big, let's move it into a separate function.
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
1 file changed, 15 insertions(
Many drivers reference the crtc->pointer in order to get the current CRTC
state in their atomic_begin or atomic_flush hooks, which would be the new
CRTC state in the global atomic state since _swap_state happened when those
hooks are run.
Use the drm_atomic_get_new_crtc_state helper to get that st
On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> > /*
> > * If we can't determine whether or not a pte is special, then fail
> > immediately
> > * for ptes. Note, we can still pin HugeTLB and THP as these are guaranteed
> > not
> > * to be special.
> > *
> > * For a futex to
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 only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new stat
On 05-11-20, 11:56, Ulf Hansson wrote:
> On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote:
> > Btw, how do we identify if it is a power domain or a regulator ?
To be honest, I was a bit afraid and embarrassed to ask this question,
and was hoping people to make fun of me in return :)
> Good questi
05.11.2020 19:07, Alan Stern пишет:
>> +err = devm_tegra_ehci_init_opp_table(&pdev->dev);
>> +if (err)
>> +return dev_err_probe(&pdev->dev, err,
>> + "Failed to initialize OPP\n");
> Why log a second error message? Just return err.
Indeed, thank
Hello Lee,
On 11/5/20 3:45 PM, Lee Jones wrote:
> In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> as a container for state->crtcs[i].new_state, but is not utilised in
> this use-case. We cannot simply delete the variable, so here we tell
> the compiler that we're intention
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 needed.
Now that the CRTCs have been converted, let's move forward with the
idr_init() uses base 0 which is an invalid identifier for this driver.
The new function idr_init_base allows IDR to set the ID lookup from
base 1. This avoids all lookups that otherwise starts from 0 since
0 is always unused.
References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient"
On Wed, Nov 04, 2020 at 03:01:17PM -0500, Felix Kuehling wrote:
> On 2020-11-04 10:13 a.m., Deepak R Varma wrote:
> > idr_init() uses base 0 which is an invalid identifier. The new function
> > idr_init_base allows IDR to set the ID lookup from base 1. This avoids
> > all lookups that otherwise sta
05.11.2020 05:30, Chanwoo Choi пишет:
> On 11/5/20 1:49 AM, Dmitry Osipenko wrote:
>> Add devfreq support to the Tegra20 EMC driver. Memory utilization
>> statistics will be periodically polled from the memory controller and
>> appropriate minimum clock rate will be selected by the devfreq governor
On Thu, 5 Nov 2020 at 12:13, Viresh Kumar wrote:
>
> On 05-11-20, 11:56, Ulf Hansson wrote:
> > On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote:
> > > Btw, how do we identify if it is a power domain or a regulator ?
>
> To be honest, I was a bit afraid and embarrassed to ask this question,
> and
The NUM_CHANNELS define has a pretty generic name and was right before the
function using it. Let's move to something that makes the hardware-specific
nature more obvious, and to a more appropriate place.
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
driver
05.11.2020 04:45, Michał Mirosław пишет:
> On Thu, Nov 05, 2020 at 02:43:57AM +0300, Dmitry Osipenko wrote:
>> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
>> power consumption and heating of the Tegra chips. Tegra SoC has multiple
>> hardware units which belong to a cor
NUM_OUTPUTS isn't used anymore, let's remove it.
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 44db31e16e91.
On Thu, Nov 05, 2020 at 02:48:08PM -0800, Jianxin Xiong wrote:
> @@ -966,7 +969,10 @@ static struct mlx5_ib_mr *alloc_mr_from_cache(struct
> ib_pd *pd,
> struct mlx5_ib_mr *mr;
> unsigned int page_size;
>
> - page_size = mlx5_umem_find_best_pgsz(umem, mkc, log_page_size, 0, iova)
Hi,
Here's a second attempt at fixing the current issues we have with the
muxing code that results in a PV muxing its HVS muxing when only another
CRTC is modified by a state, or vblank timeouts when trying to wait for a
vblank on a single CRTC while another one is inactive but enabled.
Let me kn
> Am 05.11.2020 um 19:28 schrieb Tomi Valkeinen :
>
> On 05/11/2020 20:14, H. Nikolaus Schaller wrote:
>>
>>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen :
>>>
>>> Hi,
>>>
>>> On 05/11/2020 19:15, H. Nikolaus Schaller wrote:
>>>
Next, I migrated my long waiting mipi_dsi/drm_panel driv
idr_init() uses base 0 which is an invalid identifier for this driver.
The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
ID range and it is #defined to 1. The new function idr_init_base allows
IDR to set the ID lookup from base 1. This avoids all lookups that
otherwise starts
On Tue, Nov 03, 2020 at 06:28:24PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 03, 2020 at 05:15:51PM +0100, Maxime Ripard wrote:
> > Hi Ville,
> >
> > On Mon, Nov 02, 2020 at 06:04:06PM +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 02, 2020 at 02:38:33PM +0100, Maxime Ripard wrote:
> > > > Many dri
On Thu, Nov 05, 2020 at 11:25:11AM -0800, Eric Anholt wrote:
> On Thu, Nov 5, 2020 at 10:25 AM Deepak R Varma wrote:
> >
> > idr_init() uses base 0 which is an invalid identifier for this driver.
> > The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> > ID range and it is #de
a6xx_gmu_get_mmio() never return null in case of error, but ERR_PTR(),
so we should use IS_ERR() instead of null pointer check
Signed-off-by: Wang Qing
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gm
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/lima/lima_devfreq.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/d
idr_init() uses base 0 which is an invalid identifier for this driver.
The idr_alloc for this driver uses 1 as start value for ID range. The
new function idr_init_base allows IDR to set the ID lookup from base 1.
This avoids all lookups that otherwise starts from 0 since 0 is always
unused / availa
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
Hi Dave, Daniel,
Here's this week round of fixes for drm-misc
Thanks!
Maxime
drm-misc-fixes-2020-11-05:
Some patches for vc4 to fix some resources cleanup issues, two fixes for
panfrost for madvise and the shrinker and a constification of fonts
structure
The following changes since commit 3cea11
On Thu, Nov 05, 2020 at 02:48:07PM -0800, Jianxin Xiong wrote:
> + ret = ib_check_mr_access(access_flags);
> + if (ret)
> + return ret;
This should also reject unsupportable flags like ACCESS_ON_DEMAND and
HUGETLB
> +
> + mr = pd->device->ops.reg_user_mr_dmabuf(pd, offset
Hi
Am 05.11.20 um 18:30 schrieb Maxime Ripard:
> 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 needed.
>
> Now t
On Fri, 06 Nov 2020, Ahmad Fatoum wrote:
> On 11/6/20 8:41 AM, Lee Jones wrote:
> > On Thu, 05 Nov 2020, Ahmad Fatoum wrote:
> >
> >> Hello Lee,
> >>
> >> On 11/5/20 3:45 PM, Lee Jones wrote:
> >>> In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> >>> as a container for stat
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
Changes since V2:
- Removed duplicate errno print
Changes since V1:
- This time,
On Wed, Nov 04, 2020 at 07:35:13PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Many of these now applied, please update the series against my
tty-testing branch a
On Sun, Nov 01, 2020 at 12:32:44PM +0200, Hassan Shahbazi wrote:
> On Sun, Nov 01, 2020 at 07:39:48AM +0100, Greg KH wrote:
> > On Sun, Nov 01, 2020 at 02:20:10AM +0200, Hassan Shahbazi wrote:
> > > Fix the checkpath.pl issue on fb_watterott.c. write_vmem and
> > > write_vmem_8bit functions are wit
On Fri, Nov 6, 2020 at 5:08 AM John Hubbard wrote:
>
> On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> >>> /*
> >>> * If we can't determine whether or not a pte is special, then fail
> >>> immediately
> >>> * for ptes. Note, we c
On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter wrote:
>
> On Fri, Nov 6, 2020 at 5:08 AM John Hubbard wrote:
> >
> > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> > >>> /*
> > >>> * If we can't determine whether or not a pte is
On Sat, Oct 31, 2020 at 03:24:41AM -0400, Peilin Ye wrote:
> `struct console_font` is a UAPI structure, thus ideally should not be
> used for kernel internal abstraction. Remove some dummy .con_font_set,
> .con_font_default and .con_font_copy `struct consw` callback
> implementations, to make it cl
On 2020-11-06 at 12:05:14 +0530, Anshuman Gupta wrote:
> On 2020-11-05 at 22:04:15 +0530, Ramalingam C wrote:
> > On 2020-10-27 at 22:12:04 +0530, Anshuman Gupta wrote:
> > > Add support for multiple mst stream in hdcp port data
> > > which will be used by RepeaterAuthStreamManage msg and
> > > HDC
On 2020-10-27 at 22:12:01 +0530, Anshuman Gupta wrote:
> hdcp_port_data is specific to a port on which HDCP
> encryption is getting enabled, so encapsulate it to
> intel_digital_port.
> This will be required to enable HDCP 2.2 stream encryption.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
>
Hi Andrew,
can I get you Acked-by to merge this cleanup through the drm-misc-next branch?
The affected drivers are mostly from the DRM subsystem.
The fix for the other problem you pointed out in mmap_region() has already
shown up in that branch.
Thanks in advance,
Christian.
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states ->mmap() callback can change
vma->vm_file and so we might call fput() on the wrong file.
Revert the workaround and proper fix this in mmap_region.
v2: drop the extra if in dm
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is
On 2020-10-27 at 22:12:08 +0530, Anshuman Gupta wrote:
> Enable HDCP 2.2 over DP MST.
> Authenticate and enable port encryption only once for
> an active HDCP 2.2 session, once port is authenticated
> and encrypted enable encryption for each stream that
> requires encryption on this port.
>
> Simi
On 2020-10-27 at 22:11:55 +0530, Anshuman Gupta wrote:
> Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
> It requires to call intel_hdcp_handle_cp_irq() in case
> of CP_IRQ is triggered by a sink in DP-MST topology.
>
> Cc: "Ville Syrjälä"
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
Reviewed
Apparently, the function was never used at all.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/gem.c | 6 --
drivers/gpu/drm/gma500/psb_drv.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 8f07de83b6fb.
As GEM object functions are now mandatory, DRM drivers based on CMA
helpers either set them in their implementation of gem_create_object,
or use the default via drm_gem_cma_create_object_default_funcs().
Simplify this by setting the default CMA object functions for all
objects that don't have any
On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
>
> Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> nouveau_drm structure to the drm_device. This is important because a
> reference to nouveau_drm is accessible from drm_device, which is
> provided to a number of DRM layer call
On Sun, Nov 1, 2020 at 10:36 AM Sam Ravnborg wrote:
> On Fri, Oct 30, 2020 at 01:28:50AM +0100, Linus Walleij wrote:
> > The driver includes but doesn't use any symbols
> > from this file.
> >
> > Cc: Magnus Damm
> > Cc: Geert Uytterhoeven
> > Cc: linux-renesas-...@vger.kernel.org
> > Signed-of
The pool parameter can be NULL if we free through the shrinker.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 44ec41aa78d6..1b96780b4989 1
On Fri, 06 Nov 2020, Tomi Valkeinen wrote:
> On 05/11/2020 20:07, Lee Jones wrote:
> > On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
> >
> >> On 05/11/2020 16:45, Lee Jones wrote:
> >>> Fixes the following W=1 kernel build warning(s):
> >>>
> >>> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi
On Fri, Nov 06, 2020 at 02:31:44PM +0100, Karol Herbst wrote:
> On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
> >
> > Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> > nouveau_drm structure to the drm_device. This is important because a
> > reference to nouveau_drm is acces
Shmem-allocated memory uses the system's default caching flags,
usually involving cached mappings.
By default, SHMEM GEM helpers map pages using writecombine. Only a few
drivers require this setting. Others revert it to default mappings
flags. Some could benefit from caching, but don't care.
Unif
Cached page mappings are now the default for SHMEM GEM objects. Remove
the obsolete create function for cached mappings.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 26 --
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
drivers/gpu/drm/udl
SHMEM-buffer backing storage is allocated from system memory; which is
typically cachable. The default mode for SHMEM objects is writecombine
though.
Unify SHMEM semantics by defaulting to cached mappings. The exception
is pages imported via dma-buf. DMA memory is usually not cached.
DRM drivers
Hi,
On Fri, Nov 6, 2020 at 11:15 PM Maxime Ripard wrote:
>
> Hi,
>
> Here's an attempt to removing the dma_direct_set_offset calls we have in
> numerous drivers and move all those quirks into a global notifier as suggested
> by Robin.
>
> Let me know what you think,
> Maxime
>
> Maxime Ripard (7)
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, November 06, 2020 4:49 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
Hi Lee,
> >
> > Applied to drm-misc-next.
>
> Thanks for all these Sam.
>
> Any idea what happens to the other patches?
>
> Do they go in via a different Maintainer?
I expect the respective drm maintaines to take them.
Give them a few days to take action.
I look forward for the next set that
On Fri, Nov 06, 2020 at 01:42:24PM +0100, Thomas Zimmermann wrote:
> Apparently, the function was never used at all.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Indeed unused.
I expect you or Patrik to apply the patch.
Sam
> ---
> drivers/gpu/drm/gma500/gem.c
Hi Thomas.
On Fri, Nov 06, 2020 at 02:16:32PM +0100, Thomas Zimmermann wrote:
> As GEM object functions are now mandatory, DRM drivers based on CMA
> helpers either set them in their implementation of gem_create_object,
> or use the default via drm_gem_cma_create_object_default_funcs().
>
> Simpl
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, November 05, 2020 4:13 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, November 05, 2020 4:09 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
On Fri, 06 Nov 2020, Sam Ravnborg wrote:
> Hi Lee,
> > >
> > > Applied to drm-misc-next.
> >
> > Thanks for all these Sam.
> >
> > Any idea what happens to the other patches?
> >
> > Do they go in via a different Maintainer?
>
> I expect the respective drm maintaines to take them.
> Give them
Hi Marek,
On 11/5/20 10:45 AM, Marek Vasut wrote:
> On 11/5/20 10:39 AM, Daniel Vetter wrote:
>> On Wed, Nov 04, 2020 at 01:52:00PM +0100, Marek Vasut wrote:
>>> Enable runtime PM before registering the fbdev emulation and disable it
>>> afterward, otherwise register access to the LTDC IP during t
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, November 06, 2020 8:40 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
On 05/11/2020 20:07, Lee Jones wrote:
> On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
>
>> On 05/11/2020 16:45, Lee Jones wrote:
>>> Fixes the following W=1 kernel build warning(s):
>>>
>>> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_status’:
>>> drivers/gpu/drm/omapdrm/dss/dsi
1 - 100 of 165 matches
Mail list logo
