#
f5cb5ada |
|
08-Nov-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: Drop userptr support from hmm After the conversion to videobuf2 userptr support is no longer needed, drop it. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
931d87d2 |
|
26-Sep-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: Add hmm_create_from_vmalloc_buf() function Add a new hmm creating function to create a vmm object from a vmalloc-ed kernel buffer. This is a preparation patch for adding videobuf2 (and working MMAP mode) support. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
4cc20c9c |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: Simplify hmm_alloc() calls Make hmm_alloc() only take size as a parameter and remove other parameters. since all callers always pass the same flags. Link: https://lore.kernel.org/linux-media/20220615205037.16549-30-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
ceff4bdb |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: add hmm_create_from_userdata() helper Most hmm_alloc() callers want BO_PRIVATE type memory. Add a hmm_create_from_userdata() helper for other cases so that the hmm_alloc() calls for all the callers who don't want this can be simplied. Link: https://lore.kernel.org/linux-media/20220615205037.16549-29-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
a9796c7b |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: remove unused hmm address translation functions hmm_isp_vaddr_to_host_vaddr() and hmm_host_vaddr_to_hrt_vaddr() are unused, remove them. Link: https://lore.kernel.org/linux-media/20220615205037.16549-28-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
c0039ef3 |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: remove pool related kernel cmdline options Since we have removed the hmm pools these are completely meaningless now. Link: https://lore.kernel.org/linux-media/20220615205037.16549-14-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
454da4d2 |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: remove hmm_mem_stats Without pool support the (optional) debug logging done by these is not really meaningful, drop it all. Link: https://lore.kernel.org/linux-media/20220615205037.16549-13-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
c35f36b7 |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: remove hmm pool code Since we never register any pools, this is all dead code, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-12-hdegoede@redhat.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
ad4c63c3 |
|
15-Jun-2022 |
Hans de Goede <hdegoede@redhat.com> |
media: atomisp: remove hmm_pool_[un]register() These are no-ops, so lets remove them. Link: https://lore.kernel.org/linux-media/20220615205037.16549-10-hdegoede@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
#
f5fbb83f |
|
29-May-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: add SPDX headers This driver is licensed under GPL 2.0, as stated inside their headers. Add the proper tag there. We should probably latter cleanup the reduntant licensing text, but this could be done later, after we get rid of other abstraction layers. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
abbd669d |
|
28-May-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: do another round of coding style cleanup Run checkpatch --fix-inline again, in order to get rid of some additional issues that got introduced (or that checkpatch can now detect). This should help preventing receiving random cleanups, while keeping the code on a better shape. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
08fef4fa |
|
26-May-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: get rid of memory_access.c Now that we have everything in place, we can get rid of the memory_access abstraction layer. Now, everything related to heterogeneous memory management (hmm) is under hmm.c & related pools. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
b92d99ae |
|
24-May-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: go one step further to drop ia_css_memory_access.c Move the attrs handling into hmm, simplifying even further what the ia_css_memory_access.c file does. Yet, the returned type for ia_css_memory_access.c is an integer, instead of a pointer. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
86df6ff2 |
|
25-May-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: reduce abstraction at ia_css_memory_access Yet another memory abstraction layer. Getting rid of this may be a little trickier, but let's reduce it to a minimal. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
#
9d4fa1a1 |
|
30-Apr-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
media: atomisp: cleanup directory hierarchy This driver has very long directories without a good reason (IMHO). Let's drop two directories from such hierarchy, in order to simplify things a little bit and make the dir output a bit more readable. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|