for_each_entry(pageref, pagelist, list) {
> + struct page *page = pageref->page;
Same here and the other drivers. You only need the page for the index AFAICT.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
message ?
Regardless, the patch looks good to me:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ately. The performance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 6f29e04938bf ("fbdev: Improve performance of sys_imageblit()")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
>
Hello Geert,
On 3/14/22 14:40, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 9:12 PM Javier Martinez Canillas
> wrote:
>> Add support to convert 8-bit grayscale to reversed monochrome for drivers
>> that control monochromatic displays, that only ha
On 3/15/22 10:18, Javier Martinez Canillas wrote:
> Hello YueHaibing,
>
> Thanks for the patch.
>
> On 3/12/22 07:34, YueHaibing wrote:
>> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
>> Depends on [n]: HAS_IOMEM [=y] && DRM [
rformance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 0d03011894d2 ("fbdev: Improve performance of cfb_imageblit()")
> Reported-by: Marek Szyprowski
> Cc: Thomas Zimmermann
> Cc: Javier M
_LIST_HEAD()
> redundantly.
>
> Fixes: 105a940416fc ("fbdev/defio: Early-out if page is already
> enlisted")
> Cc: Thomas Zimmermann
> Signed-off-by: Chuansheng Liu
> ---
This makes sense to me. If you address Geert comment and post a v2,
feel free to add:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
m-misc-next) but left patch 5 since
would like to give Noralf the opportunity to review/test before pushing.
By the way, you should probably request commit access to the drm-misc tree:
https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
&& HAS_IOMEM [=y] && DRM [=m]
>
> DRM_GEM_SHMEM_HELPER depends on MMU, DRM_SSD130X should also depends on MMU.
>
> Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: YueHaibing
> ---
Indeed. All the DRM drivers that select
e operation.
>
> Update the comments accordingly.
>
> Fixes: bcf8b616deb87941 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Geert Uytterhoeven
> ---
Acked-by: Javier Martinez Canillas
I just have a small comment b
> Remove the correction for an unaligned y1 from
> ssd130x_update_rect(), and add a check to make sure y1 is aligned.
>
> Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Thanks for fixing
med that the destination
buffer for the OLED panels were also monochrome reversed.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Geert Uytterhoeven
> ---
Indeed. I haven't noticed that got the calculation wrong until you pointed out.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
888 to
> monochrome conversion")
> Signed-off-by: Geert Uytterhoeven
> ---
> Untested due to lack of hardware.
>
Patch looks good to me but I also don't have this hardware.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
/O from each other.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
02,6 +406,7 @@ static int drm_client_buffer_addfb(struct
> drm_client_buffer *buffer,
> * @width: Framebuffer width
> * @height: Framebuffer height
> * @format: Buffer format
> + * @fbdev: True if the client provides an fbdev device, or false otherwise
> *
An emulated fbdev device ?
Other than those small nit,
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/3/22 21:58, Thomas Zimmermann wrote:
> Add drm_fb_helper_vm_page_mkwrite(), a helper to track pages written
> by fbdev userspace. DRM drivers should use this function to implement
> fbdev deferred I/O.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier
s of mmap'ed framebuffer
> memory.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
optimize the if branch.
[snip]
> +}
> +#else
> +struct drm_gem_object *virtio_gpu_create_object_fbdev(struct drm_device *dev,
> + size_t size)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
As mentioned, I believe this should be
ixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Chen-Yu Tsai
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
OSYS;
> +#endif
> +}
I believe the correct errno code here should be -ENOTSUPP.
[snip]
> + /* We don't use vmf->pgoff since that has the fake offset */
> + page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
I see this (vmf->address - vma->vm_start) calculation in many places of
this series. Maybe we could add a macro to calculate the offset instead ?
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
867 ("drm: Add driver for Solomon SSD130x OLED displays")
> Signed-off-by: Chen-Yu Tsai
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
hink it's worth
> it, I'd change the drivers as well.
>
Thanks for the explanation. No, I don't think is worth it or at least as
as part of this series.
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
er call pin, unpin or get_sg_table.
>
Yeah, that's true too. It was just a suggestion, I'm OK with patch as is.
> Best regards
> Thomas
>
>>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
+ dst_pitch = DIV_ROUND_UP(linepixels, 8);
>
> This is not correct when clip->x1 is not a multiple of 8 pixels.
> Should be:
>
> DIV_ROUND_UP(linepixels + clip->x1 % 8, 8);
>
Agreed.
>> +
>> + drm_WARN_ONCE(dev, dst_pitch % 8 != 0, "dst_pitch is not a multiple
>> of 8\n");
>
> This triggers for me: dst_pitch = 1.
> Which is perfectly fine, when flashing an 8-pixel wide cursor ;-)
>
Indeed. I think we should just drop that warn.
Do you want me to post patches for all these or would you do it
when simplifying the drm_fb_gray8_to_mono_reversed_line() logic ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
w.cs.helsinki.fi/linux/linux-kernel/2002-30/1135.html
>
Thanks for the link. It would be good to have an authoritative guideline
about this in the kernel documentation (and make checkpatch.pl aware).
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/8/22 17:30, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Feb 14, 2022 at 2:37 PM Javier Martinez Canillas
> wrote:
>> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
>> OLED display controllers.
>>
>> It's only the core p
ixes...
>
Right, I believe this is a consequence of introducing shadow buffers at
some point and not adjusting the logic in this function.
Thanks a lot for tracking down the issues and working on fixes for them!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ts.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ber of bits per pixel instead.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
: Geert Uytterhoeven
> ---
Yes, I learned that "Red" actually meant just a color channel
that may not be red in one of the thread about fourcc formats.
So I agree that would be good to have a comment about this.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ion of bits per pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
IIRC the agreement was that it was worth to have both Cx and Rx fourcc
formats separately, so this patch makes sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
rely on proper
> block handling for the calculation of bits per pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
COLOR;
Other than that the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
On 3/9/22 13:56, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Wed, Mar 9, 2022 at 1:14 PM Javier Martinez Canillas
> wrote:
>> On 3/8/22 17:30, Geert Uytterhoeven wrote:
>>> Unfortunately a regression was introduced since your v3: printed
>>> t
h looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
>
> Reduce memory consumption by using the actual number of bits per pixel
> instead.
>
> Signed-off-by: Geert Uytterhoeven
> Acked-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Signed-off-by: Geert Uytterhoeven
> ---
> RFC, as this code path was untested.
>
Looks good to me but haven't tested either.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
or 256 darkness levels.
>
> As the number of bits per pixel may be less than eight, some of these
> formats rely on proper block handling for the calculation of bits per
> pixel and pitch.
>
> Signed-off-by: Geert Uytterhoeven
> ---
Reviewed-by: Javier Martinez Canillas
--
Bes
s")
>> Signed-off-by: Chen-Yu Tsai
>
> Thanks, this fixes the vertically-mirrored display on my Adafruit
> FeatherWing 128x32 OLED.
> Tested-by: Geert Uytterhoeven
> Reviewed-by: Geert Uytterhoeven
>
Thanks for the testing and review. I've pushed both patches to drm-misc-next.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
the screen. Watching a video on the fbdev console felt smoother and
> had less flickering.
>
Awesome. And you also answered here the question I had above.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
just wanted to mention in case I forget later.
Your patch looks good to me and I think it could be pushed
without waiting for the other patches in the series.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 3/8/22 10:56, Thomas Zimmermann wrote:
> Hi
>
> Am 08.03.22 um 10:31 schrieb Javier Martinez Canillas:
>> On 3/3/22 21:58, Thomas Zimmermann wrote:
>>> Don't select shadow buffering for the fbdev console explicitly. The
>>> fbdev emulation's heuristic w
hey, it's debugfs so you shouldn't fail anything else because of that
> anyway.
>
Thanks a lot Doug and Jani for the explanations. That makes sense and it
explains why most code I looked was not checking for the return value.
I guess we should write something about this in the debugfs functions
kernel doc so it's mentioned explicitly and people don't have to guess.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
eviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
; + /*
> + * post_crtc_powerdown will have called pm_runtime_put, so we
> + * don't need it here otherwise we'll get the reference counting
> + * wrong.
> + */
>
I'm not familiar with the BCM2711 SoC nor its HDMI controller but your
commit message clearly explain th
ewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/23/22 20:38, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
imized case, cfb_imageblit() is now ~2x faster than before.
>
> v3:
> * fix commit description (Pekka)
>
> Signed-off-by: Thomas Zimmermann
> ---
Makes sense, improves perf and makes the two more consistent as you mention.
Reviewed-by: Javier Martinez Canillas
Best re
Hello Daniel,
On 2/24/22 13:59, Daniel Vetter wrote:
> Some things changed, and add two useful links.
>
> Cc: Javier Martinez Canillas
> Cc: Pekka Paalanen
> Cc: gpicc...@igalia.com
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 21 +--
Hello Noralf,
On 2/24/22 15:04, Noralf Trønnes wrote:
>
>
> Den 23.02.2022 20.37, skrev Javier Martinez Canillas:
>> There is now a drm_fb_xrgb_to_mono_reversed() helper function to do
>> format conversion from XRGB to reversed monochrome.
>>
>> Use that
On 2/14/22 14:37, Javier Martinez Canillas wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
>
> Using the DRM fbdev emulation, all the tests from Geert Uytterhoeven r
tions(+)
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
f-by: Michal Suchanek
> ---
Thanks for the patch. This makes much more sense to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
on it.
>
> The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86
> platform, move it from fbdev to x86 Kconfig.
>
> Fixes: e3263ab389a7 ("x86: provide platform-devices for boot-framebuffers")
> Signed-off-by: Michal Suchanek
> Acked-by: Borislav
On 2/25/22 21:51, Michal Suchanek wrote:
> efifb is the only user of efifb_setup_from_dmi which is provided by
> sysfb which is selected by efifb. That makes the stub redundant.
>
> Signed-off-by: Michal Suchanek
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
*dst++ = pat;
> - *dst++ = pat;
> - *dst++ = pat;
> - n -= 8;
> - }
> - while (n--)
> - *dst++ = pat;
> + memset_l(dst, pat, n);
> + dst
n answer.
We have many drivers doing the same and I couldn't find one that was doing
it correctly to use as a reference:
$ git grep "TODO: Use mapping abstraction properly" | wc -l
15
If you point me the proper way, I'll be happy to post a patch to change it.
> Lucas De Marchi
>
[0]
&g
On 2/17/22 10:25, Lucas De Marchi wrote:
> On Thu, Feb 17, 2022 at 10:00:42AM +0100, Javier Martinez Canillas wrote:
[snip]
>>> this is now called iosys_map in drm-intel... drm-tip will need a fixup
>>> for the merge.
>>>
>>
>> I thought that the drm
> blit/conversion helpers allocate an internal temporary per-line buffer.
> The code you made for the new driver has this designed outlined already.
>
Indeed. I understand now what you meant when proposing to add those helpers.
> Best regards
> Thomas
>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Signed-off-by: Thomas Zimmermann
> ---
This patch looks good to me as well.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
gpu/drm/drm_modeset_helper.c or a drm_modeset_quirks.c
like we have for drivers/gpu/drm/drm_panel_orientation_quirks.c ?
The patch looks good to me, regardless where you decide to add it.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
sted in the quirk table,
> to make the fbcon (and aware userspace apps) rotate the image to
> display properly.
>
> Cc: Javier Martinez Canillas
> Signed-off-by: Hans de Goede
> ---
The patch looks good to me. Thanks a lot for fixing this
Reviewed-by: Javier Martinez Canillas
t; so the quirk handling uses the display resolution to detect the model.
>
> Signed-off-by: Hans de Goede
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
sing
and probably we should change it at some point...
Patch itself looks good to me though.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
egacy BIOS boot mode" and that isn't
accurate AFAIU (unless you meant sysfb instead).
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/23/22 17:54, Javier Martinez Canillas wrote:
> On 2/23/22 17:45, Michal Suchánek wrote:
>
> [snip]
>
>>>>
>>>> To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
>>>
>>> I think you meant "VESA modes with the
There is now a drm_fb_xrgb_to_mono_reversed() helper function to do
format conversion from XRGB to reversed monochrome.
Use that helper and remove the open coded version in the repaper driver.
Signed-off-by: Javier Martinez Canillas
---
This was only built tested because I don't have
On 2/23/22 18:12, Michal Suchánek wrote:
> On Wed, Feb 23, 2022 at 05:54:54PM +0100, Javier Martinez Canillas wrote:
[snip]
>>
>> Yes, that's what I tried to say. But your commit message says "To enable
>> use of VESA modes with simplefb in legacy BIOS boot mode" a
imple-framebuffer" platform device could be registered by OF if a
Device Tree node with compatible "simple-framebuffer" exists).
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
to merge.
>
The v4 patches looks good to me and have provided my Reviewed-by to all of them.
> Thanks
>
> Michal
>
>>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Colin,
Thanks for the patch.
On Wed, Mar 2, 2022 at 6:53 PM Colin Ian King wrote:
>
> Pointer mode is being assigned a value that is never read, it is
> being re-assigned later with a new value. The initialization is
> redundant and can be removed.
>
Indeed.
Acked-by:
On 3/2/22 19:29, Javier Martinez Canillas wrote:
> Hello Colin,
>
> Thanks for the patch.
>
> On Wed, Mar 2, 2022 at 6:53 PM Colin Ian King wrote:
>>
>> Pointer mode is being assigned a value that is never read, it is
>> being re-assigned later wit
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.
It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.
Signed-off-by: Javier Martinez Canillas
---
Changes
MAINTAINERS entry (Sam Ravnborg)
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Javier Martinez Canillas (6):
drm/format-helper: Add drm_fb_xrgb_to_gray8_line()
drm/format-helper: Add drm_fb_xrgb_to_mono_reversed()
drm: Add driver for Solomon SSD130x OLED disp
Pull the per-line conversion logic into a separate helper function.
This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Andy
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
---
(no changes since v5)
Changes in v5:
- Add Andy Shevchenko's Reviewed
.
The drm_fb_gray8_to_mono_reversed_line() helper was based on code from
drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Andy Shevchenko
---
Changes in v6:
- Add Andy Shevchenko's Reviewed-by to patch #2.
Changes in v5:
- Use
-misc
F: Documentation/devicetree/bindings/display/repaper.txt
F: drivers/gpu/drm/tiny/repaper.c
+DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
+M: Javier Martinez Canillas
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
Reviewed-by: Andy Shevchenko
---
(no changes since v5)
Changes in v5:
- Add Andy Shevchenko's Reviewed-by tag to patch #6.
Changes in v4:
- Add Rob Herring Acked-by tag to patch adding as DT binding co-maintainer
t; The cast can be removed if src32 is changed to "void *".
> For symmetry, gray8 and mono can be changed to "void *", too.
>
Yes, but these being "u32 *" and "u8 *" also express that the source buffer
contains 32-bit XRGB pixels, the intermediate buffer a 8-bit grayscale
pixel format and the destination buffer a 8-bit packed reversed monochrome.
Using "void *" for these would make that less clear when reading the code IMO.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/11/22 20:19, Javier Martinez Canillas wrote:
[snip]
>> I would put GENMASK() directly into FIELD(), but it's up to you
>> (and I haven't checked the use of *_MASK anyway).
>>
>
> Same. I also considered just using GENMASK() directly, but since I was
> already
2 insertions(+)
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 3/22/22 20:27, Thomas Zimmermann wrote:
> Give the Makefile a bit more structure by putting rules for core,
> helpers, drivers, etc next to each other.
>
> Signed-off-by: Thomas Zimmermann
> ---
This is a nice cleanup.
Reviewed-by: Javier Martinez Canillas
-
dp_aux_i2c_transfer_size
I don't know whether those are considered a kernel ABI or not though, and
some already changed when the DP helpers were moved from drm_kms_helper.ko
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
t; by putting code for video-output standards into a local display/
> directory. The new directory's name is aligned with that policy.
>
It is really a policy or just a convention ?
> Signed-off-by: Thomas Zimmermann
> ---
>
Reviewed-by: Javier Martinez Canillas
--
Best regards
ameters. It seems that isn't
documented anywhere.
But since no one complained when these were moved from drm_kms_helper.ko
and the current drm_dp_helper.ko is so recent, I would say that's fine.
If you re-spin feel free to add,
Reviewed-by: Javier Martinez Canillas
> I somehow expected that
the proliferation of Kconfig options, DSC is part of DRM's
> support for DisplayPort. If necessary, a new option could make DSC an
> independent feature.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
n
> ---
After fixing Jani's comment about the drm_hdcp_helper_helper.h typo:
Reviewed-by: Javier Martinez Canillas
[snip]
> diff --git a/drivers/gpu/drm/drm_hdcp.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> similarity index 99%
> rename from drivers/gpu/drm/drm_hdcp.c
>
nes are cargo culting from the previous fbdev driver to make existing
DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings
without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Hello Chen-Yu,
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wrote:
>
> From: Chen-Yu Tsai
>
> Add a vendor prefix entry for SINO WEALTH Eletronics Ltd.
> (http://www.sinowealth.com).
>
> Signed-off-by: Chen-Yu Tsai
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
SSD130X_PAGE_COL_START_SET(col_start & 0xf);
> + col_high = SSD130X_PAGE_COL_START_HIGH |
> + SSD130X_PAGE_COL_START_SET((col_start >> 4) & 0xf);
Maybe instead we should define
SSD130X_PAGE_COL_START_{HIGH,LOW}_{MASK,SET} to be consistent with how
the other fields are set and not
es to this patch, I
believe the convention in DRM is for the subject line to be
"drm/ssd130x:" instead of "drm: ssd130x:"
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
On 4/4/22 18:35, Chen-Yu Tsai wrote:
> On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas
> wrote:
[snip]
>>
>> I wonder if we should also list SH1106 in the
>> drivers/gpu/drm/solomon/Kconfig file so people can find it ?
>
> I can add it to the help te
xisting
>> DTBs compatible with the DRM driver.
>>
>> I've been thinking if I should post a patch to compatible strings
>> without the "fb" and mark the current ones as deprecated...
>>
>> Reviewed-by: Javier Martinez Canillas
>
> I also thoug
6deb8 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> CC: Maxime Ripard
> CC: Thomas Zimmermann
> ---
t of the
SPI series. Thanks a lot for the suggestion, it was very useful.
> I think a friend of mine has a SPI based SH1106 module that I
> could borrow and test/work on, but that's a big if.
>
>
Cool. If it uses 4-wire too then I believe that would mostly work
out-of-the-box if yo
> +++ b/include/drm/drm_file.h
>
> This wasn't enough for the second patch, I had to re-do the changes by hand
> from scratch.
>
Yes, I believe the suggestion should be to use git-format-patch instead.
To make sure that was is posted can be consumed by the git-am command.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
401 - 500 of 2265 matches
Mail list logo
