On 23/10/2024 09:44, Jon Hunter wrote:
On 23/10/2024 07:43, Thomas Zimmermann wrote:
Hi
Am 22.10.24 um 17:36 schrieb Jon Hunter:
We'd turn a linker/modpost error into a compiler error. Likely makes
no difference. And AFAICT every driver that selects TTM also selects
TTM_HELPER. Dr
On 23/10/2024 07:43, Thomas Zimmermann wrote:
Hi
Am 22.10.24 um 17:36 schrieb Jon Hunter:
We'd turn a linker/modpost error into a compiler error. Likely makes
no difference. And AFAICT every driver that selects TTM also selects
TTM_HELPER. Drivers without TTM should not use this h
On 22/10/2024 15:55, Thomas Zimmermann wrote:
Hi
Am 22.10.24 um 15:31 schrieb Jon Hunter:
Hi Thomas,
On 12/03/2024 15:45, Thomas Zimmermann wrote:
Only TTM-based drivers use fbdev-generic. Rename it to fbdev-ttm and
change the symbol infix from _generic_ to _ttm_. Link the source file
into
Hi Thomas,
On 12/03/2024 15:45, Thomas Zimmermann wrote:
Only TTM-based drivers use fbdev-generic. Rename it to fbdev-ttm and
change the symbol infix from _generic_ to _ttm_. Link the source file
into TTM helpers, so that it is only build if TTM-based drivers have
been selected. Select DRM_TTM_H
point IRQs only during probe")
Signed-off-by: Jon Hunter
---
drivers/gpu/host1x/dev.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index b62e4f0e8130..e98528777faa 100644
--- a/drivers/gpu/host1x/dev
On 25/09/2024 13:58, Thierry Reding wrote:
On Tue, Sep 24, 2024 at 07:33:05PM GMT, Jon Hunter wrote:
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during
On 24/09/2024 19:33, Jon Hunter wrote:
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
On 06/09/2024 09:38, Jon Hunter wrote:
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended
e for this in struct host1x_memory_context and point to
it.
Reported-by: Jonathan Hunter
Signed-off-by: Thierry Reding
Looks good:
Reviewed-by: Christoph Hellwig
I guess this another thing caught by the WARN_ON in the dma_set*
functions?
Yes indeed! This works for me.
Tested-by: Jon H
Hi Mikko,
On 31/05/2024 08:07, Mikko Perttunen wrote:
From: Mikko Perttunen
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to onl
Abhinav,
On 08/05/2024 21:52, Jon Hunter wrote:
On 08/05/2024 17:46, Abhinav Kumar wrote:
On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails
with ...
Traceback (most recent call last):
File "drivers/gpu/drm/msm/regi
On 24/05/2024 20:57, Abhinav Kumar wrote:
Hello
On 5/24/2024 12:55 PM, Paul E. McKenney wrote:
Hello!
I get the following allmodconfig build error on x86 in next-20240523:
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main()
request by Jon
Hunter, the script is required to be compatible with Python 3.5.
Python is documented as an optional dependency, as it is required only
in a limited set of kernel configurations (following the example of
other optional dependencies).
Cc: Jon Hunter
Signed-off-by: Dmitry Baryshkov
to happen. If 3.5 is
the minimal one, then be it.
AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should
at least be aware *why* we'd be sticking to old versions.
From my side, the 3.5 was chosen basing on the previous feedback from
Jon Hunter:
https://lore.kerne
On 08/05/2024 17:46, Abhinav Kumar wrote:
On 5/8/2024 2:17 AM, Jon Hunter wrote:
Building the kernel with python3 versions earlier than v3.9 fails with
...
Traceback (most recent call last):
File "drivers/gpu/drm/msm/registers/gen_header.py", line 970, in
main(
ier python3 versions by
explicitly defining '--validate' and '--no-validate' arguments.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/msm/registers/gen_header.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/registers/gen_header.py
b/dri
Hi all,
On 12/04/2024 17:54, Jon Hunter wrote:
The gen_header.py script is failing for older versions of python3 such
as python 3.5. Two issues observed with python 3.5 are ...
1. Python 3 versions prior to 3.6 do not support the f-string format.
2. Early python 3 versions do not support
e argparse add_subparsers().
Fix both of the above so that older versions of python 3 still work.
Fixes: 8f7abf0b86fe ("drm/msm: generate headers on the fly")
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/msm/registers/gen_header.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
On 12/04/2024 17:19, Dmitry Baryshkov wrote:
On Fri, 12 Apr 2024 at 19:15, Jon Hunter wrote:
Hi Dmitry,
On 01/04/2024 03:42, Dmitry Baryshkov wrote:
Generate DRM/MSM headers on the fly during kernel build. This removes a
need to push register changes to Mesa with the following manual
Hi Dmitry,
On 01/04/2024 03:42, Dmitry Baryshkov wrote:
Generate DRM/MSM headers on the fly during kernel build. This removes a
need to push register changes to Mesa with the following manual
synchronization step. Existing headers will be removed in the following
commits (split away to ease revi
Hi Thierry,
On 15/03/2024 11:25, Jon Hunter wrote:
On 14/03/2024 15:49, Thierry Reding wrote:
From: Thierry Reding
The host1x devices are virtual compound devices and do not perform DMA
accesses themselves, so they do not need to be set up for DMA.
Ideally we would also not need to set up
t;dev->of_node, true);
-
device->dev.dma_parms = &device->dma_parms;
dma_set_max_seg_size(&device->dev, UINT_MAX);
Tested-by: Jon Hunter
Acked-by: Jon Hunter
Thanks!
Jon
--
nvpublic
... because this fixes a suspend regression on Tegra186.
Thierry, would you be able to add the fixes-tag and send out as a fix
for v6.8? Otherwise ...
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
Thanks!
Jon
--
nvpublic
On 02/02/2024 14:35, Jason Gunthorpe wrote:
On Fri, Feb 02, 2024 at 10:40:36AM +, Jon Hunter wrote:
But, what is the actual log output you see, is it -EEXIST?
I see ...
ERR KERN host1x drm: iommu configuration for device failed with -ENOENT
So that shouldn't happen in you ca
On 01/02/2024 20:02, Jason Gunthorpe wrote:
On Thu, Feb 01, 2024 at 07:35:24PM +, Jon Hunter wrote:
You mean this sequence?
err = device_add(&ctx->dev);
if (err) {
dev_err(host1x->dev, "could not add context devic
On 31/01/2024 15:33, Jason Gunthorpe wrote:
On Tue, Jan 30, 2024 at 09:55:18PM +, Jon Hunter wrote:
On 30/01/2024 16:15, Jason Gunthorpe wrote:
This was added in commit c95469aa5a18 ("gpu: host1x: Set DMA ops on device
creation") with the note:
Currently host1x-in
ses:
https://lore.kernel.org/all/bbmhcoghrprmbdibnjum6lefix2eoquxrde7wyqeulm4xabmlm@b6jy32saugqh/
Reported-by: Jon Hunter
Closes:
https://lore.kernel.org/all/b0334c5e-3a6c-4b58-b525-e72bed889...@nvidia.com/
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/host1x/bus.c | 2 --
1 file changed, 2 deletions(-)
trs;
/* Allocate backing memory */
for (i = 0; i < npages; i++) {
@@ -533,7 +533,7 @@ gk20a_instobj_new(struct nvkm_instmem *base, u32 size, u32
align, bool zero,
else
ret = gk20a_instobj_ctor_dma(imem, size >> PAGE_SHIFT,
align, &node);
- *pmemory = node ? &node->memory : NULL;
+ *pmemory = node ? &node->base.memory : NULL;
if (ret)
return ret;
Tested-by: Jon Hunter
Thanks!
Jon
--
nvpublic
On 08/03/2023 16:56, Nathan Chancellor wrote:
Ping? This warning is now in 6.3-rc1.
Thierry is away at the moment.
David, Daniel, do you want to pick this up directly in the meantime as a
fix for 6.3? Mikko has already reviewed and FWIW ...
Reviewed-by: Jon Hunter
Thanks
Jon
On Thu
Thierry,
On 21/10/2022 08:41, Jon Hunter wrote:
On 20/10/2022 15:23, Robin Murphy wrote:
Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
bus") quite some time ago, the GART driver has effectively disabled
itself to avoid issues with the GPU driver expecting it
On 04/11/2022 15:48, Krzysztof Kozlowski wrote:
On 04/11/2022 11:46, Jon Hunter wrote:
On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
On 04/11/2022 11:33, Jon Hunter wrote:
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko
On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
On 04/11/2022 11:33, Jon Hunter wrote:
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
From: Mikko Perttunen
On Tegra234 NVDEC firmware is loaded from a
Hi Thierry, Krzysztof,
On 24/10/2022 14:15, Thierry Reding wrote:
On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
From: Mikko Perttunen
On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell i
it 57365a04c921 ("iommu: Move bus setup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.
Reported-by: Jon Hunter
Suggested-by: Dmitry Osipenko
Signed-off-by: Robin M
t. As of commit 57365a04c921 ("iommu: Move bus setup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.
Reported-by: Jon Hunter
Suggested-by: Dmitry Osipenko
Signed-off-by: Ro
On 21/06/2022 21:49, Uwe Kleine-König wrote:
On Tue, Jun 21, 2022 at 08:57:00PM +0100, Jon Hunter wrote:
Some of our Tegra boards are not booting with the current -next and
bisect is pointing to this commit. Looking at the boot log I am
seeing the following panic ...
[2.097048] 8
Hi Uwe,
On 14/03/2022 14:16, Uwe Kleine-König wrote:
Allow to add an exit hook to devm managed clocks. Also use
clk_get_optional() in devm_clk_get_optional instead of open coding it.
The generalisation will be used in the next commit to add some more
devm_clk helpers.
Reviewed-by: Jonathan Came
accelerator."
Hi,
nice to see this work going on. For subsequent revisions, can you please
also Cc the Tegra mailing list (linux-te...@vger.kernel.org) as well as
the Tegra platform maintainers (that's Jon Hunter and myself). This will
make sure that more people with an interest in thi
t the need to explicitly remove the
final reference to the mapping in the cache.
Signed-off-by: Thierry Reding
I have tested this and verified that it is working well.
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
Thanks
Jon
--
nvpublic
On 29/03/2022 11:37, cgel@gmail.com wrote:
From: Lv Ruyi
Before leave the nvdec_load_firmware, we shuold free virt which is alloced
s/shuold/should
s/alloced/allocated
by dma_alloc_coherent, so change "return err" to "goto cleanup".
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
--
Sparse warns about the following cast in the function
falcon_copy_firmware_image() ...
drivers/gpu/drm/tegra/falcon.c:66:27: warning: cast to restricted __le32
Fix this by casting the firmware data array to __le32 instead of u32.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/falcon.c
have not been used yet. Note that when the syncpt status
is dumped by the kernel itself for debugging only the active syncpt are
shown.
Signed-off-by: Jon Hunter
---
drivers/gpu/host1x/debug.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x
On 22/12/2021 19:01, Dmitry Osipenko wrote:
...
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index e08e331e46ae..8194826c9ce3 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -137,6 +137,15 @@ void host1x_syncpt_restore(struct host1x *hos
On 22/12/2021 09:47, Jon Hunter wrote:
On 21/12/2021 20:58, Dmitry Osipenko wrote:
Hi,
Thank you for testing it all.
21.12.2021 21:55, Jon Hunter пишет:
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
Add runtime PM and OPP support to the Host1x driver. For the starter
On 21/12/2021 20:58, Dmitry Osipenko wrote:
Hi,
Thank you for testing it all.
21.12.2021 21:55, Jon Hunter пишет:
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
Add runtime PM and OPP support to the Host1x driver. For the starter we
will keep host1x always-on because
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
Add runtime PM and OPP support to the Host1x driver. For the starter we
will keep host1x always-on because dynamic power management require a major
refactoring of the driver code since lot's of code paths are missing the
RPM handlin
On 14/12/2021 15:38, Robin Murphy wrote:
...
IOMMU/DT folks, any thoughts about this approach? The patches that are
of interest outside of Host1x/TegraDRM specifics are patches 1, 2, 4,
and 5.
FWIW it looks fairly innocuous to me. I don't understand host1x -
neither hardware nor driver ab
Hi all,
Still no response on this :-(
On 06/12/2021 09:55, Jon Hunter wrote:
Will, Joerg, Rob,
On 08/11/2021 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom
Will, Joerg, Rob,
On 08/11/2021 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when progr
using older versions of GCC.
Fix this by using the '##__VA_ARGS__' macro instead.
Fixes: 43636451db8c ("drm/tegra: Implement job submission part of new UAPI")
Reported-by: Linux Kernel Functional Testing
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/submit.c | 2 +-
Hi Mikko,
On 10/06/2021 12:04, Mikko Perttunen wrote:
> Implement the job submission IOCTL with a minimum feature set.
>
> Signed-off-by: Mikko Perttunen
> ---
> v7:
> * Allocate gather BO with DMA API to get page-aligned
> memory
> * Add error prints to a few places where they were missing
>
On 10/06/2021 12:04, Mikko Perttunen wrote:
> Implement the job submission IOCTL with a minimum feature set.
>
> Signed-off-by: Mikko Perttunen
> ---
> v7:
> * Allocate gather BO with DMA API to get page-aligned
> memory
> * Add error prints to a few places where they were missing
> v6:
> * R
1x_client_register(&sor->client);
> + if (err < 0) {
> + dev_err(&pdev->dev, "failed to register host1x client: %d\n",
> + err);
> + goto uninit;
> }
>
> return 0;
>
> -u
On 13/02/2021 10:15, Mikko Perttunen wrote:
> Add support for booting and using NVDEC on Tegra210, Tegra186
> and Tegra194 to the Host1x and TegraDRM drivers. Booting in
> secure mode is not currently supported.
>
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/drm/tegra/Makefile | 3 +-
On 30/11/2020 22:57, Dmitry Osipenko wrote:
> 01.12.2020 00:17, Jon Hunter пишет:
>> Hi Dmitry,
>>
>> On 23/11/2020 00:27, Dmitry Osipenko wrote:
>>> Add EMC OPP DVFS tables and update board device-trees by removing
>>> unsupported OPPs.
>>>
>&
Hi Dmitry,
On 23/11/2020 00:27, Dmitry Osipenko wrote:
> Add EMC OPP DVFS tables and update board device-trees by removing
> unsupported OPPs.
>
> Signed-off-by: Dmitry Osipenko
This change is generating the following warning on Tegra20 Ventana
and prevents the EMC from probing ...
[2.48571
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
On 04/11/2020 10:49, Dmitry Osipenko wrote:
> 04.11.2020 12:23, Jon Hunter пишет:
>> 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
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 V1:
- This time, I actually validated it!
drivers/gp
On 03/11/2020 11:44, Jon Hunter wrote:
> 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
> ---
&
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
---
drivers/gpu/drm/tegra/sor.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Hi Lee,
On 16/03/2020 09:05, Daniel Thompson wrote:
> On Fri, Mar 13, 2020 at 02:16:16PM +0000, Jon Hunter wrote:
>> Hi Lee, Daniel,
>>
>> On 24/02/2020 14:37, Daniel Thompson wrote:
>>> On Mon, Feb 24, 2020 at 02:07:48PM +, Jon Hunter wrote:
>>>> I
that all
> the system memory can be used for command buffers, irrespective of
> whether or not the host1x firewall is enabled.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/host1x/dev.c | 46
> 1 file changed, 42 insertions(+), 4
s: 2d9384ff9177 ("drm/tegra: Relax IOMMU usage criteria on old Tegra")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/drm.c | 3 ++-
> drivers/gpu/host1x/dev.c| 13 +
> include/linux/host1x.h | 3 +++
> 3 files changed, 18 ins
Hi Lee, Daniel,
On 24/02/2020 14:37, Daniel Thompson wrote:
> On Mon, Feb 24, 2020 at 02:07:48PM +0000, Jon Hunter wrote:
>> If probing the LP885x backlight fails after the regulators have been
>> enabled, then the following warning is seen when releasing the
>> regulators ..
el0_sync_handler+0xf4/0x1b0
el0_sync+0x140/0x180
Fix this by ensuring that the regulators are disabled, if enabled, on
probe failure.
Finally, ensure that the vddio regulator is disabled in the driver
remove handler.
Signed-off-by: Jon Hunter
---
drivers/video/backlight/lp855x_bl.c | 20
On 24/07/2019 10:27, Dmitry Osipenko wrote:
> 23.07.2019 15:40, Viswanath L пишет:
>> HDMI plugout calls runtime suspend, which clears interrupt registers
>> and causes audio functionality to break on subsequent plug-in; setting
>> interrupt registers in sor_audio_prepare() solves the issue.
>>
>
t;hpd_gpio)) {
> + if (PTR_ERR(output->hpd_gpio) == -ENOENT)
> + output->hpd_gpio = NULL;
> + else
> + return PTR_ERR(output->hpd_gpio);
> + }
>
> if (output->hpd_gpio) {
> err = gpiod_to_irq(output->hpd_gpio);
>
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 09/07/2019 14:26, Jon Hunter wrote:
>
> On 09/07/2019 13:52, Dmitry Osipenko wrote:
>> 09.07.2019 15:45, Maxime Ripard пишет:
>>> Hi,
>>>
>>> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote:
>>>> 17.06.2019 17
On 09/07/2019 13:52, Dmitry Osipenko wrote:
> 09.07.2019 15:45, Maxime Ripard пишет:
>> Hi,
>>
>> On Fri, Jul 05, 2019 at 07:54:47PM +0300, Dmitry Osipenko wrote:
>>> 17.06.2019 17:51, Maxime Ripard пишет:
From: Maxime Ripard
Rewrite the command line parser in order to get away fro
On 18/06/2019 16:19, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
>> Greg is busy already, but maybe he won't do everything ...
>>
>> Cc: Greg Kroah-Hartman
>> Signed-off-by: Daniel Vetter
>> ---
>> Documentation/gpu/todo.rst | 3 +++
>> 1 file chan
t it first and then find a safer solution instead.
>
> Reported-by: Tony Lindgren
> Signed-off-by: Nicolin Chen
> ---
> Tony,
>
> Would you please test and verify? Thanks!
This also fixes various memory allocation failures we have seen on
32-bit Tegra as well.
T
On 29/11/2018 14:51, Thierry Reding wrote:
> On Thu, Nov 29, 2018 at 01:40:32PM +0000, Jon Hunter wrote:
>>
>> On 23/11/2018 12:06, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Tegra supports generic PM domains on 64-bit ARM, and if that is en
On 23/11/2018 12:06, Thierry Reding wrote:
> From: Thierry Reding
>
> Tegra supports generic PM domains on 64-bit ARM, and if that is enabled,
> the power domain code will make sure that resets are asserted and
> deasserted at appropriate points in time.
>
> If generic PM domains are not implem
hat both are actually the same, which
> is a good explanation for why the driver performs flawlessly.
>
> That said, your change is obviously correct. I've applied it, but since
> it doesn't actually fix anything, and doesn't change anything from a
> binary point of view,
On 07/09/18 12:42, Maxime Ripard wrote:
> On Fri, Sep 07, 2018 at 01:26:30PM +0200, Arnd Bergmann wrote:
>> On Fri, Sep 7, 2018 at 11:41 AM Jon Hunter wrote:
>>>
>>>
>>> On 11/07/18 15:43, Arnd Bergmann wrote:
>>>> Having DRM_SUN4I built-in
On 11/07/18 15:43, Arnd Bergmann wrote:
> Having DRM_SUN4I built-in but DRM_SUN8I_MIXER as a loadable module results in
> a link error, as we try to access a symbol from the sun8i_tcon_top.ko module:
>
> ERROR: "sun8i_tcon_top_of_table" [drivers/gpu/drm/sun4i/sun8i-drm-hdmi.ko]
> undefined!
> ER
On 02/08/18 12:59, Venkat Reddy Talla wrote:
> The IO pins of Tegra SoCs are grouped for common control
> of IO interface like setting voltage signal levels and
> power state of the interface. These groups are referred
> to as IO pads.The power state and voltage control of IO pins
> can be done at
e teardown helper for
gk20a.
This is based upon a previous patch by Guillaume Tucker but limits
the workaround to only gk20a GPUs.
Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown")
Reported-by: Guillaume Tucker
Signed-off-by: Jon Hunter
---
I am not happy that we do not
out = sor->clk;
> }
>
> sor->clk_parent = devm_clk_get(&pdev->dev, "parent");
> --- >8 ---
>
> That said, I suspect the SOR might be compatible from a clock point of
> view with later versions and perhaps we just didn't implement c
On 06/12/17 17:18, Jon Hunter wrote:
>
> On 06/12/17 09:22, Guillaume Tucker wrote:
>> On 05/12/17 18:32, Ben Skeggs wrote:
>>> On Wed, Dec 6, 2017 at 12:30 AM, Jon Hunter wrote:
>>>
>>>>
>>>> On 04/12/17 18:37, Guillaume Tucker wrote:
>
On 06/12/17 09:22, Guillaume Tucker wrote:
> On 05/12/17 18:32, Ben Skeggs wrote:
>> On Wed, Dec 6, 2017 at 12:30 AM, Jon Hunter wrote:
>>
>>>
>>> On 04/12/17 18:37, Guillaume Tucker wrote:
>>>> If the firmware fails to load then ->fini(
device = base->subdev.device;
> +
> + if (base->subdev.oneinit)
> + nvkm_mask(device, 0x001704, 0x8000, 0x);
> }
>
> void
I have tested this and it works for me. Thanks for fixing this! Would be
good to get Ben's ACK, but you can have my
Hi Linus,
On 28/09/17 08:10, Linus Lüssing wrote:
> Hi,
>
> Sorry, did not search for the exact commit yet, but since v4.14-rc1
> I get a build error when trying to build the ARM multi_v7_defconfig
> target:
>
> ~~
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x00208000
n DRM
> + depends on OF
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL
Thanks Arnd. I am curious if it can still fail if PINCTRL is not
selected in whatever config you are using?
That said ...
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
__
On 07/07/17 07:11, Gustavo A. R. Silva wrote:
> Check return value from call to of_match_device()
> in order to prevent a NULL pointer dereference.
>
> In case of NULL print error message and return.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/tegra/sor.c | 4
> 1 file
On 16/04/17 05:08, Wei Yongjun wrote:
> From: Wei Yongjun
>
> PTR_ERR should access the value just tested by IS_ERR, otherwise
> the wrong error code will be returned.
>
> Fixes: b386c6b73ac6 ("gpu: host1x: Support module reset")
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/host1x/dev.c |
er pincontrol\n");
> - return -ENODEV;
> + return PTR_ERR(dpaux->pinctrl);
> }
> #endif
> /* enable and clear all interrupts */
Thanks for the fix!
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 04/10/16 12:25, Daniel Vetter wrote:
> On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter wrote:
>> Looks like crtc is a errno in the above case. I see this function is
>> called by looping through all the crtc and we never check to see if
>> they are valid. Should we?
>
&g
Hi Tomeu,
On 09/09/16 10:56, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> star
Jonathan Hunter
> Signed-off-by: Thierry Reding
This patch along with the fix from Vince [0] fixes the hang during boot
on Tegra114. So ...
Tested-by: Jon Hunter
Cheers
Jon
[0] http://marc.info/?l=linux-kernel&m=144017122430016&w=2
--
nvpublic
ERR(dpaux->pinctrl)) {
> dev_err(&pdev->dev, "failed to register pincontrol\n");
> - return -ENODEV;
> + return PTR_ERR(dpaux->pinctrl);
> }
> #endif
> /* enable and clear all interrupts */
>
Acked-by: Jon Hunter
Cheers!
Jon
--
nvpublic
On 02/08/16 07:26, Tomeu Vizoso wrote:
> On 23 June 2016 at 17:59, Jon Hunter wrote:
>> If the 'i2c-bus' device-tree node is present for an I2C adapter then
>> parse this subnode for I2C slaves.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> drivers/
The DSI device requires that the SOR power partition is enabled when
active. Populate this power partition for the Tegra210 DSI nodes.
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210
because we cannot guarantee
that the reset will be asserted/de-asserted at the appropriate time.
Therefore, given that the Tegra generic PM domain code will handle the
resets, do not request the reset in the SOR driver if the SOR device has
a PM domain associated.
Signed-off-by: Jon Hunter
because we cannot guarantee
that the reset will be asserted/de-asserted at the appropriate time.
Therefore, given that the Tegra generic PM domain code will handle the
resets, do not request the reset in the DSI driver if the DSI device has
a PM domain associated.
Signed-off-by: Jon Hunter
fault, idle, etc) because the SOR driver will directly
set the state needed. For I2C clients only the I2C mode is used and so
we can simplify matters by using the generic pinctrl states for default
and idle.
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 54 ++
power-domain will be turned on before probing SOR or DPAUX
devices and kept on while the devices are bound.
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
: Jon Hunter
---
drivers/gpu/drm/tegra/dpaux.c | 122 --
1 file changed, 119 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 61821f457209..7b2abaf33a7a 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
e.
Update the main DPAUX binding documentation to reference the DPAUX pad
controller binding document and add the 'i2c-bus' subnode. The 'i2c-bus'
subnode is used for populating I2C slaves for the DPAUX device so that
the I2C driver core does not attempt to add the DPAUX pad con
1 - 100 of 183 matches
Mail list logo
