On Fri, Jul 01 2016, Markus Mayer wrote:
> Add a function called strtolower() to convert strings to lower case
> in-place, overwriting the original string.
>
> This seems to be a recurring requirement in the kernel that is
> currently being solved by several duplicated implementations doing the
On Tue, Jul 05 2016, Markus Mayer wrote:
> Add a collection of generic functions to convert strings to lowercase
> or uppercase.
>
> Changing the case of a string (with or without copying it first) seems
> to be a recurring requirement in the kernel that is currently being
> solved by several
).
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/drm_connector.c | 21 ++---
drivers/gpu/drm/drm_crtc.c | 4 ++--
include/drm/drm_crtc.h | 3 ++-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drive
kernel with these backported, and as expected
they save around 250KB of memory. There's more to gain, but this is
just an RFC.
Rasmus Villemoes (10):
lib/idr.c: reused free bitmaps are already clear
lib/idr.c: delete useless condition
lib/idr.c: only fill ida->idr when needed
lib/tida.c: a very simple i
On Fri, Dec 16 2016, Matthew Wilcox wrote:
> From: Andrew Morton [mailto:akpm at linux-foundation.org]
>> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes
>> wrote:
>> > TL;DR: these patches save 250 KB of memory, with more low-hanging
>> > fruit ready
On Sat, Dec 17 2016, Matthew Wilcox wrote:
> From: Matthew Wilcox
>> From: Rasmus Villemoes [mailto:linux at rasmusvillemoes.dk]
>> > This sounds good. I think there may still be a lot of users that never
>> > allocate more than a handful of IDAs, making a 128 byte all
The current code fails to call i2c_del_adapter on
dev_prev->gmbus[0].adapter, and if the for loop above failed already
at i==0, all hell breaks loose when we do the loop body for
i = -1,-2,...
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/gma500/intel_gmbus.c | 2 +-
1 file changed
This fails to undo the setup for pin==0; moreover, something
interesting happens if the setup failed already at pin==0.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/i915/intel_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b
le background info.
Rasmus Villemoes (5):
drm/gma500: fix error path in gma_intel_setup_gmbus()
drm/i915: fix error path in intel_setup_gmbus()
net/mlx4: fix some error handling in mlx4_multi_func_init()
net: sxgbe: fix error paths in sxgbe_platform_probe()
mm/backing-dev.c: fix error pa
A few more cases where one should use post-decrement when unwinding,
this time found where the unwinding is done inside the setup loop
instead of after an error label.
Rasmus Villemoes (3):
drm/amdgpu: use post-decrement in error handling
drm/nouveau: use post-decrement in error handling
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
We need to use post-decrement to get the dma_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if dma_map_page
failed already at i==0.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
the
upper sysfs layer, whether truncation has happened or not.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 168 +++---
1 file changed, 85 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drive
On Mon, Mar 14 2016, Oded Gabbay wrote:
> On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
> wrote:
>> Passing overlapping source and destination buffers to snprintf
>> formally has undefined behaviour and is rather fragile. While the
>
> I saw there were
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/exynos/exynos_drm_fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 517471b..09ce2bc 100644
--- a/drivers/gpu/drm/exynos
The name of the macro suggests that the include guard idiom was meant,
but the #define was missing.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.h
b/drivers/gpu/drm/vmwgfx
->stolen->start has type unsigned long; relying on the difference
(effectively cast to int) for sorting is wrong.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_deb
arg is long int, so arg = (arg << 22) >> 22 makes the upper 22 bits of
arg equal to bit 9 (or bit 41). But we then mask away all but bits 0-9, so
this is entirely redundant.
Signed-off-by: Rasmus Villemoes
---
gcc seems to be smart enough to realize this - the generated code
an int), but 440fd5283a87 ("drm/mm: Support 4 GiB and
larger ranges") strongly suggests that's not the case.
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/driv
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/omapdrm/tcm-sita.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/tcm-sita.c
b/drivers/gpu/drm/omapdrm/tcm-sita.c
index efb609510540..6df1f2a1bc52 100644
--- a/drivers/gpu/drm/omapdrm/tcm
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/vga/vgaarb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index a0b433456107..3166e4bc4eb6 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -531,7
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 64b50409fa07..38d910ae9b21 100644
--- a/drivers/gpu/drm
loc return value
srf->sizes has been allocated and checked a few lines above; fix up
the copy-pasto so that we check srf->offsets.
Reported-by: kbuild test robot
Signed-off-by: Rasmus Villemoes
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Hi,
The files
drivers/gpu/drm/nouveau/nv50_fbcon.c
drivers/gpu/drm/nouveau/nvc0_fbcon.c
drivers/video/fbdev/nvidia/nv_accel.c
all contain a right-shift of ~0 (aka -1) - just grep for '~0 >>'. gcc
always does arithmetic right shift of signed types, which means that the
result is always -1
This file has been copy-pasted-pasted:
~/linux$ x=drivers/video/fbdev/au1200fb.h; diff -u <(head -n 286 $x; head -n
286 $x) $x
~/linux$
Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk>
---
drivers/video/fbdev/au1200fb.h | 286
lightness*1000 is nowhere near overflowing 32 bits, so we can just use
an ordinary 32/32 division, which is much cheaper than the 64/32 done
via do_div().
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
e formulas agree at
L==8, both yielding the 0.008856 figure to four significant digits.
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_
change to use a power-of-2 scale,
but for a fixed small exponent of 3, there's no advantage in using
repeated squaring.
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers
On 20/09/2019 12.14, Daniel Thompson wrote:
> Hi Rasmus
>
> Has something gone wrong with the mail out for this patch set. I didn't
> get a covering letter or patch 5/5?
Sorry about that. I should have included a cover letter so you'd know
that patch 5 wasn't directly related to the other
On 14/10/2019 09.27, Lee Jones wrote:
> Applied, thanks.
I'm not seeing the series in next-20191023, should it be there?
Rasmus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 07/10/2019 17.28, Daniel Thompson wrote:
> On Thu, Sep 19, 2019 at 04:06:18PM +0200, Rasmus Villemoes wrote:
>
> It feels like there is some rationale missing in the description here.
>
> What is the benefit of replacing the explicit int_pow() with the
> implic
On 08/10/2019 11.31, Daniel Thompson wrote:
> On Mon, Oct 07, 2019 at 08:43:31PM +0200, Rasmus Villemoes wrote:
>> On 07/10/2019 17.28, Daniel Thompson wrote:
>>> On Thu, Sep 19, 2019 at 04:06:18PM +0200, Rasmus Villemoes wrote:
>>>
>>> It feels
-By to the four patches.
Daniel, I took the liberty of adding your R-B to patch 4 despite
changing it a little to fix a thinko - I should add 1<<31 and not
1<<15. Please tell me if that was inappropriate.
Rasmus Villemoes (4):
backlight: pwm_bl: fix cie1913 comments and constant
backl
lightness*1000 is nowhere near overflowing 32 bits, so we can just use
an ordinary 32/32 division, which is much cheaper than the 64/32 done
via do_div().
Reviewed-by: Daniel Thompson
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1
e formulas agree at
L==8, both yielding the 0.008856 figure to four significant digits.
Reviewed-by: Daniel Thompson
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c
-by: Daniel Thompson
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 672c5e7cfcd1..273d3fb628a0 100644
--- a/drivers/video/backlight
).
Reviewed-by: Daniel Thompson
Signed-off-by: Rasmus Villemoes
---
drivers/video/backlight/pwm_bl.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 273d3fb628a0..a99c2210c935
On 03/04/2020 11.11, Sakari Ailus wrote:
> Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> the same implementation can be used.
This seems quite niche to me, I'm not sure that belongs in
On 27/04/2020 16.53, Sakari Ailus wrote:
> Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by fourccs. The fourcc encoding is the same for both
> so the same implementation can be used.
>
> Suggested-by: Mauro Carvalho Chehab
> Signed-off-by:
Keep sparse happy by preserving the __user annotation when casting.
Reported-by: kernel test robot
Signed-off-by: Rasmus Villemoes
---
kernel test robot has already started spamming me due to 9c5743dff. If
I don't fix those warnings I'll keep getting those emails for
months, so let me do
On 24/03/2021 14.33, Arnd Bergmann wrote:
> On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
> wrote:
>> On 23/03/2021 14.04, Arnd Bergmann wrote:
>>> if (securedisplay_cmd->status ==
>>> TA_SECUREDISPLAY_STATUS__SUCCESS) {
>>>
On 24/03/2021 18.20, Joe Perches wrote:
> On Wed, 2021-03-24 at 09:52 -0700, Joe Perches wrote:
>> On Wed, 2021-03-24 at 17:42 +0100, Arnd Bergmann wrote:
>>> On Wed, Mar 24, 2021 at 3:20 PM Joe Perches wrote:
>> []
> diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
On 24/03/2021 20.24, Joe Perches wrote:
> On Wed, 2021-03-24 at 18:33 +0100, Rasmus Villemoes wrote:
>> On 24/03/2021 18.20, Joe Perches wrote:
>>
>>>
>>> Maybe it's better to output non PTR_ERR %pe uses as decimal so this
>>> sort of code would work.
>
On 23/03/2021 14.04, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc warns about an sprintf() that uses the same buffer as source
> and destination, which is undefined behavior in C99:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function
> 'amdgpu_securedisplay_debugfs_write':
On 24/03/2021 23.18, Joe Perches wrote:
> On Wed, 2021-03-24 at 22:27 +0100, Rasmus Villemoes wrote:
>> On 24/03/2021 20.24, Joe Perches wrote:
>>> On Wed, 2021-03-24 at 18:33 +0100, Rasmus Villemoes wrote:
>>>> On 24/03/2021 18.20, Joe Perches wrote:
>>>&g
On 05/02/2021 22.06, Chris Wilson wrote:
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct
On Sat, Jul 31, 2021, 04:59 Kees Cook wrote:
> On Fri, Jul 30, 2021 at 10:19:20PM +, Williams, Dan J wrote:
> > On Wed, 2021-07-28 at 14:59 -0700, Kees Cook wrote:
>
> > /**
> > * struct_group(NAME, MEMBERS)
> > *
> > @@ -67,7 +73,10 @@ enum {
> > * @NAME: The name of the mirrored
On 28/07/2021 07.49, Greg Kroah-Hartman wrote:
> On Tue, Jul 27, 2021 at 01:58:53PM -0700, Kees Cook wrote:
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memcpy(), memmove(), and memset(), avoid
>> intentionally writing across neighboring
On 27/07/2021 22.58, Kees Cook wrote:
> At its core, FORTIFY_SOURCE uses the compiler's __builtin_object_size()
> internal[0] to determine the available size at a target address based on
> the compile-time known structure layout details. It operates in two
> modes: outer bounds (0) and inner
On 27/07/2021 22.57, Kees Cook wrote:
> In order to have a regular programmatic way to describe a struct
> region that can be used for references and sizing, can be examined for
> bounds checking, avoids forcing the use of intermediate identifiers,
> and avoids polluting the global namespace,
On 02/03/2022 00.55, Linus Torvalds wrote:
> On Tue, Mar 1, 2022 at 3:19 PM David Laight wrote:
>>
> With the "don't use iterator outside the loop" approach, the exact
> same code works in both the old world order and the new world order,
> and you don't have the semantic confusion. And *if* you
On 05/07/2022 17.10, Kieran Bingham wrote:
> Hi Rasmus,
>
> Quoting Rasmus Villemoes (2022-07-05 10:08:37)
>> Hi
>>
>> I have an imx8mp board with a sn65dsi86 and a (full-size) DisplayPort
>> connector, which I'm trying to get up and running.
>>
[...]
&
On 11/09/2022 13.04, Andi Shyti wrote:
> Hi Gwan-gyeong,
>
> On Fri, Sep 09, 2022 at 07:59:07PM +0900, Gwan-gyeong Mun wrote:
>> It adds assert_type and assert_typable macros to catch type mis-match while
>
> /Add/It adds/, please use the imperative form.
>
>> compiling. The existing
On 24/10/2022 22.11, Gwan-gyeong Mun wrote:
> From: Kees Cook
>
> Implement a robust overflows_type() macro to test if a variable or
> constant value would overflow another variable or type. This can be
> used as a constant expression for static_assert() (which requires a
> constant
Hi Jagan and others
I'm trying to test this series on our imx8mp-based boards, which has the
mipi-dsi connected to a ti,sn65dsi86 bridge (in turn connected to a
full-size DP-connector). But I don't know how to add the proper nodes to
imx8mp.dtsi. My current, obviously incomplete, attempt is
On 27/01/2023 11.39, Jagan Teki wrote:
> On Fri, Jan 27, 2023 at 4:03 PM Rasmus Villemoes
> wrote:
>>
>> Hi Jagan and others
>>
>> I'm trying to test this series on our imx8mp-based boards, which has the
>> mipi-dsi connected to a ti,sn65dsi86 bridge (in
On 27/01/2023 12.30, Marek Vasut wrote:
> On 1/27/23 12:04, Jagan Teki wrote:
>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>> modification of imx8mp.dtsi in that branch. I'm basically looking for
>>> help to do the equivalent of
>>>
>>> 88775338cd58 - arm64: dts: imx8mm:
On 17/02/2023 09.18, Alexander Stein wrote:
> Hi Liu,
>
> Am Freitag, 17. Februar 2023, 07:54:01 CET schrieb Liu Ying:
>> Hi,
>>
>> This patch set aims to add i.MX93 LCDIF display controller support
>> in the existing LCDIF DRM driver. The LCDIF embedded in i.MX93 SoC
>> is essentially the same
On 07/02/2023 10.09, Rasmus Villemoes wrote:
> I managed to get the whole chain lcdif -> mipi -> bridge -> dp-connector
> to probe with these settings
>
[...]
> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
> that's a separate issue; when I boot
On 22/02/2023 11.05, Frieder Schrempf wrote:
> The NXP kernel is completely different. AFAIK it uses the component
> helpers to bundle all subdrivers from a central driver
> (display-subsystem). This is not how the mainline approach using the
> bridge driver interface works. So you can't compare
On 14/02/2023 12.09, Fabio Estevam wrote:
> Hi Rasmus,
>
> On Tue, Feb 14, 2023 at 7:55 AM Rasmus Villemoes
> wrote:
>
>> Well, the data sheet for the dsi86 says up to 750MHz DSI HS clock, and
>> if the value specified in samsung,burst-clock-frequency is twice the
On 01/02/2023 23.00, Marek Vasut wrote:
> On 1/30/23 13:45, Rasmus Villemoes wrote:
>> On 27/01/2023 12.30, Marek Vasut wrote:
>>> On 1/27/23 12:04, Jagan Teki wrote:
>>
>>>>> Thanks, but that's exactly what I'm doing, and I don't see any
>>>&g
On 07/02/2023 10.23, Marek Vasut wrote:
> On 2/7/23 10:09, Rasmus Villemoes wrote:
>
> [...]
>
>> Now hotplug-detect doesn't work with the current sn65dsi86 driver, but
>> that's a separate issue; when I boot with a monitor attached, its edid
>> is correctly read
On 14/02/2023 11.55, Rasmus Villemoes wrote:
> On 07/02/2023 10.23, Marek Vasut wrote:
>
> Do any of you happen to have this working on the imx8mp-evk, and if so,
> can you share the .dts updates you've done and how exactly you test the
> graphics?
>
Oh, and could those of
On 06/02/2023 09.11, Frieder Schrempf wrote:
> On 03.02.23 13:29, Rasmus Villemoes wrote:
>> On 01/02/2023 23.00, Marek Vasut wrote:
>>> On 1/30/23 13:45, Rasmus Villemoes wrote:
>>>> On 27/01/2023 12.30, Marek Vasut wrote:
>>>>> On 1/27/23 12:04, Jaga
On 07/06/2023 15.27, Adam Ford wrote:
> On Wed, Jun 7, 2023 at 8:15 AM Rasmus Villemoes
> wrote:
>>
>> On 26/05/2023 05.05, Adam Ford wrote:
>>> This series fixes the blanking pack size and the PMS calculation. It then
>>> adds support to allows the DSIM to
On 26/05/2023 05.05, Adam Ford wrote:
> This series fixes the blanking pack size and the PMS calculation. It then
> adds support to allows the DSIM to dynamically DPHY clocks, and support
> non-burst mode while allowing the removal of the hard-coded clock values
> for the PLL for imx8m
On 01/08/2023 22.35, Nick Desaulniers wrote:
> I suspect it's possible to change the indirect goto into a direct goto
> with some further refactoring (macros can take block statements;
Well, with some somewhat subtle restrictions. C99, 6.10.3.11. "The
sequence of preprocessing tokens bounded by
69 matches
Mail list logo
