; For all these reasons, add support for the OLDI TXes as DRM bridges.
>
> Signed-off-by: Aradhya Bhatia
> Signed-off-by: Aradhya Bhatia
Tested-by: Michael Walle # on am67a
(with local patches from downstream for DSS support)
Thanks,
-michael
signature.asc
Description: PGP signature
ck.
FWIW, I'm seeing exactly 300MHz on the AM67A (the FCLK is 2.1GHz
according
to k3conf).
-michael
Aradhya, Devarsh, do you remember how the clocking goes here? Or if
it's
in the TRM, please point me to it...
I think what you described is correct, if any specific questions I
. Waiting 20us after
asserting the EN line resolves this issue.
Signed-off-by: Michael Walle
---
I couldn't find a good commit for a Fixes: tag and I'm not sure how
fixes are handled in drm.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
1 file changed, 11 insertions(+)
di
h (or I just didn't find it yet).
So, if the soc.dtsi has them already connected, then the
board.dts/panel.dtso would still need to explicitly delete those
properties to get the 2 OLDI TXes to work independently.
Yeah looks like that should really be a board property.
-michael
tcrtc->hw_videoport,
> +adjusted_mode->clock * 1000);
> + if (rate < 0)
> + return -EINVAL;
> +
> + adjusted_mode->clock = rate / 1000;
While after this statement, adjusted_mod
port@0 {
> +reg = <0>;
> +oldi0_in: endpoint {
> + remote-endpoint = <&dpi0_out0>;
> +};
> +
Hi Aradhya,
On Mon May 26, 2025 at 4:17 PM CEST, Aradhya Bhatia wrote:
> Thank you for reviewing and testing the patches! =)
Thank you for your dedication to bring this feature upstream :)
> On 26/05/25 15:05, Michael Walle wrote:
> >
> >> +static int get_oldi_mode(struct
Hi,
On Mon, May 26, 2025 at 07:30:35PM +0200, Maxime Ripard wrote:
On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consol
On Mon, May 12, 2025 at 10:27:07PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid")
With
link is reported as "OLDI_MODE_SINGLE_LINK".
I'll dig deeper into this tomorrow.
-michael
> +
> + if (of_property_read_u32(companion, "reg", &companion_reg))
> + return OLDI_MODE_UNSUPPORTED;
> +
> + if (companion_reg >
The panel lacked the connector type which causes a warning. Adding the
connector type reveals wrong bus_flags and bits per pixel. Fix all of
it.
Fixes: 1319f2178bdf ("drm/panel-simple: add Evervision VGG644804 panel entry")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/panel/pane
horizontal
timings are only for one half of the panel.
[1]
https://www.fortec-integrated.de/fileadmin/pdf/produkte/TFT-Displays/AUO/P238HAN01.0_Datasheet.pdf
Signed-off-by: Michael Walle
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff
Add AUO P238HAN01 23.8" 1920x1080 LVDS panel compatible string.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.ya
On Tue, May 13, 2025 at 12:18:44PM +0200, Gerd Hoffmann wrote:
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > index e32e680c7197..71c6ccad4b99 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > +++ b/drivers/gpu/drm/virtio/virt
; For all these reasons, add support for the OLDI TXes as DRM bridges.
>
> Reviewed-by: Tomi Valkeinen
> Tested-by: Alexander Sverdlin
> Signed-off-by: Aradhya Bhatia
> Signed-off-by: Aradhya Bhatia
Tested-by: Michael Walle # on a j722s/am67a
FWIW, I have a few downstream patches
th clock=0, causing the function to return MODE_NOCLOCK.
In the old sun4i_hdmi_mode_valid() before the patch, mode->clock is
always!=0, maybe that gives someone a hint.
--
Michael
On Tue, Apr 22, 2025 at 06:49:04PM +0200, Eric Auger wrote:
> Hi Gerd, Michael,
>
> On 4/16/25 3:57 PM, Gerd Hoffmann wrote:
> > On Tue, Apr 15, 2025 at 10:00:48AM -0400, Michael S. Tsirkin wrote:
> >> On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> >
ce from trying to use that
MMIO space and failing. It's a hack but probably better than
leaving things as they currently are.
The problem can currently happen only on x86/x64 VMs,
but will probably be possible on arm64 VMs as well at some
point in the future.
Any input is appreciated. Thanks.
Michael
[1]
https://lore.kernel.org/linux-hyperv/20231009211845.3136536-9-a...@kernel.org/
On Tue, Apr 15, 2025 at 01:16:32PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +static void virtio_gpu_shutdown(struct virtio_device *vdev)
> > +{
> > + /*
> > +* drm does its own synchronization on shutdown.
> > +* Do nothing here, opt out of device reset.
> > +*/
>
> I think a call
From: Christoph Hellwig Sent: Thursday, April 10, 2025 12:42 AM
>
> On Wed, Apr 09, 2025 at 02:10:26PM +, Michael Kelley wrote:
> > Hmmm. What's the reference to "as told last time"? I don't think I've had
> > this conversation before.
>
>
ce_shutdown()")
Cc: Eric Auger
Cc: Jocelyn Falempe
Signed-off-by: Michael S. Tsirkin
---
changes from v1 RFC:
tested by Eric
fixed up commit log and comments as suggested by Jocelyn
drivers/gpu/drm/virtio/virtgpu_drv.c | 9 +
drivers/virtio/virtio.c | 6 ++
includ
On Thu, Apr 10, 2025 at 02:51:47PM +0200, Jocelyn Falempe wrote:
> > > So it looks like the shutdown is called in the middle of console drawing,
> > > so
> > > either wait for it to finish, or let drm handle the shutdown, like your
> > > patch does.
The cleanest approach is actually just fixing s
On Thu, Apr 10, 2025 at 02:33:26PM +0200, Jocelyn Falempe wrote:
> On 10/04/2025 09:16, Michael S. Tsirkin wrote:
> > It looks like GPUs are used by panic after shutdown is invoked.
> > Thus, breaking virtio gpu in the shutdown callback is not a good idea -
> > guest hangs at
ing buffers, it looks like
GPU can just have a NOP there.
Fixes: 8bd2fa086a04 ("virtio: break and reset virtio devices on
device_shutdown()")
Cc: Eric Auger
Signed-off-by: Michael S. Tsirkin
---
Can someone who knows more about DRM and shutdown please tell me if this
is a good i
From: Christoph Hellwig Sent: Wednesday, April 9, 2025 3:50 AM
>
> On Tue, Apr 08, 2025 at 11:36:44AM -0700, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Export vmf_insert_mixed_mkwrite() for use by fbdev deferred I/O code,
>
> But they are usi
Move to using the new API devm_drm_panel_alloc() to allocate the
panel.
Signed-off-by: Anusha Srivatsa
Reviewed-by: Michael Walle
-michael
From: Helge Deller Sent: Saturday, March 8, 2025 6:59 PM
>
> On 2/19/25 00:01, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
[snip]
> >
> > Reported-by: Thomas Tai
> > Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen
o_cleanup(info);
>
> - unregister_framebuffer(info);
> cancel_delayed_work_sync(&par->dwork);
>
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
> -
> - hvfb_putmem(info);
> - framebuffer_release(info);
> }
>
> static int hvfb_suspend(struct hv_device *hdev)
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
> vmbus_close(hdev->channel);
> error1:
> @@ -1226,7 +1226,7 @@ static void hvfb_remove(struct hv_device *hdev)
> vmbus_close(hdev->channel);
> hv_set_drvdata(hdev, NULL);
>
> - hvfb_putmem(hdev, info);
> + hvfb_putmem(info);
> framebuffer_release(info);
> }
>
> --
> 2.43.0
Reviewed-by: Michael Kelley
Tested-by: Michael Kelley
From: Vivek Kasireddy
We need to determine if the client is new enough to support multiple
codecs -- which might include any of the Gstreamer based ones.
v2: (suggestions and fixups from Frediano)
- Add is_gl_client() method to DisplayChannelClient instead of a
dcc_is_gl_client() function.
- A
add dmabuf encoding if `drm/drm_fourcc.h` is present and
gstreamer is at least 1.24 due to
`gst_video_dma_drm_fourcc_to_format()`.
Signed-off-by: Michael Scherle
---
meson.build| 10 +-
server/gstreamer-encoder.c | 34 +++---
2 files changed
Oh I made a mistake and send this to the wrong mailing list, I'm
so sorry, I wanted to send it to the spice devel.
On 27.02.25 12:03, Michael Scherle wrote:
> This merge request is based on Vivek Kasireddy's
> [PATCH v8 0/6] dcc: Create a stream for non-gl/remote clients th
From: Vivek Kasireddy
For remote (or non-gl) clients, if a valid gl_draw stream exists,
then we first extract the dmabuf fd associated with the scanout and
share it with the encoder along with other key parameters such as
stride, width and height. Once the encoder finishes creating an
encoded buf
This brings in the following changes:
common: Add a udev helper to identify GPU Vendor
build: Avoid Meson warning
Drop Python 2 from m4/spice-deps.m4
Stop using Python six package
codegen: Use context manager when opening files
Signed-off-by: Michael Scherle
Prevent a freeze that occurs if the video stream is stopped while a
gl draw is in progress (e.g., when the client requests a new codec).
Ensure proper cleanup of the ongoing gl draw.
Signed-off-by: Michael Scherle
---
server/dcc-send.cpp | 4
1 file changed, 4 insertions(+)
diff --git a
From: Vivek Kasireddy
Once it is determined that an Intel GPU is available/active (after
looking into udev's database), we try to see if there is a h/w
based encoder (element) available (in Gstreamer's registry cache)
for the user selected video codec. In other words, if we find that
the Intel Me
ver/display-channel.cpp:2074:display_channel_create_surface:
condition `!display->priv->surfaces[surface_id]' failed
Rebase all patches on master
v2:
Update all patches to address review comments from Frediano
Tested this series with msdkh264enc/dec plugins that will be added
in anothe
From: Vivek Kasireddy
This patch adds a new function to enable the creation of Gst memory with
the dmabuf fd as the source by using a dmabuf allocator. And, it also
adds a mechanism to register and invoke any callbacks once the Gst memory
object is no longer used by the pipeline.
This patch also
From: Vivek Kasireddy
For non-gl/remote clients, if there is no stream associated with
the DisplayChannel, then we create a new stream. Otherwise, we
just update the current stream's timestamp.
v2: (suggestions and fixups from Frediano)
- Moved the gl_draw_stream object from DCC to DC
- Moved th
From: Vivek Kasireddy
We need to convert the scanout's drm format to the correct Gstreamer
format while configuring the pipeline. This can be done using
gst_video_dma_drm_fourcc_to_format() API, which will take the drm
fourcc value and return the appropriate Gst format.
Signed-off-by: Vivek Kasi
From: Vivek Kasireddy
We do not want to stop a stream associated with gl_draw as a result
of timeout because we may not get another opportunity to create a
new stream if the current one gets stopped. However, when the
stream does get stopped for other reasons, we need to clear the
gl_draw_stream
nly to get the device pointer,
which is already stored in info->device. hvfb_release_phymem()
would also need to be updated to take a struct device instead of
struct hv_device. But if you made those changes, then the
container_of() to get the hdev wouldn't be needed either.
A similar simplificat
From: Saurabh Singh Sengar Sent: Monday, February
24, 2025 5:30 AM
>
> On Mon, Feb 24, 2025 at 12:38:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Sunday,
> > February 23, 2025 6:10 AM
> > >
> > > On Sat, Feb 22, 2025 at 08
From: Saurabh Singh Sengar Sent: Sunday, February
23, 2025 6:10 AM
>
> On Sat, Feb 22, 2025 at 08:16:53PM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Saturday,
> > February 22, 2025 9:27 AM
> > >
[anip]
> > >
> > > I
From: Saurabh Singh Sengar Sent: Saturday,
February 22, 2025 9:27 AM
>
> On Wed, Feb 19, 2025 at 05:22:36AM +, Michael Kelley wrote:
> > From: Saurabh Sengar Sent: Saturday, February
> > 15,
> 2025 1:21 AM
> > >
> > > When a Hyper-V framebuffer devi
ry_SYSCALL_64_after_hwframe+0x76/0x7e
For all three cases, I think the memory freeing and iounmap() operations
can be moved to the new hvfb_destroy() function so that the memory
is cleaned up only when there aren't any users. While these additional
changes could be done as a separate patch, it see
From: Michael Kelley Sent: Monday, February 10, 2025
1:36 PM
>
> From: thomas@oracle.com Sent: Monday, February
> 10, 2025 7:08 AM
> >
> >
> >
> > >> Then the question is why the efifb driver doesn't work in the kdump
> > >> ker
On Thu, Feb 13, 2025 at 04:49:14PM +0100, Sergio Lopez wrote:
> There's an incresing number of machines supporting multiple page sizes
> and, on these machines, the host and a guest can be running with
> different pages sizes.
>
> In addition to this, there might be devices that have a required an
From: Saurabh Singh Sengar Sent: Wednesday,
February 12, 2025 7:07 PM
>
> On Thu, Feb 13, 2025 at 01:35:22AM +, Michael Kelley wrote:
> > From: Saurabh Singh Sengar Sent: Monday,
> > February 10, 2025 8:52 AM
> > >
> > [snip]
> > > > > >
r,
> > > but maybe you are doing something different.
> > >
> > > FWIW, there is yet another issue where after doing two unbind/bind
> > > cycles of the hyperv_fb driver, there's an error about freeing a
> > > non-existent resource. I know what that
From: Maxim Levitsky Sent: Monday, February 10, 2025 3:57
PM
>
> On Mon, 2025-02-10 at 21:35 +, Michael Kelley wrote:
> > From: thomas@oracle.com Sent: Monday, February
> > 10, 2025 7:08 AM
> > >
> > >
> > > > > Then the questio
From: Thomas Zimmermann Sent: Monday, February 10, 2025
11:35 PM
>
> Hi
>
> Am 10.02.25 um 20:34 schrieb mhkelle...@gmail.com:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram, and maps
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 8:52 AM
>
> On Mon, Feb 10, 2025 at 06:58:25AM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 10, 2025 at 02:28:35PM +0000, Michael Kelley wrote:
> > > From: Saurabh Singh Sengar Sent: Monday,
> >
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 7:33 PM
>
> On Mon, Feb 10, 2025 at 11:34:41AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V DRM device is probed, the driver allocates MMIO space for
> > the vram,
ent, I modified the kdumpctl shell
> > script to add the "-c" option to kexec, but in that case the value "0x0"
> > is passed as the framebuffer address, which is wrong. Furthermore,
> > the " screen_info.orig_video_isVGA" value (which I mentioned earlier
From: Saurabh Singh Sengar Sent: Monday, February
10, 2025 4:41 AM
>
> On Sun, Feb 09, 2025 at 03:52:52PM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > When a Hyper-V framebuffer device is removed, or the driver is unbound
> > from a devic
From: Saurabh Singh Sengar Sent: Friday, February 7,
2025 6:06 AM
>
> Thanks Michael, for the analysis.
>
> I have tried the kdump steps on Oracle 9.4, 6.13.0 kernel as well. Although I
> couldn't see
> the soft lockup issue I see some other VMBus failures. But I
From: Michael Kelley Sent: Thursday, February 6, 2025
1:00 PM
>
> From: Michael Kelley
> >
> > From: Thomas Tai Sent: Thursday, January 30, 2025
> > 12:44 PM
> > >
> > > > -----Original Message-
> > > > From: Michael
From: Michael Kelley
>
> From: Thomas Tai Sent: Thursday, January 30, 2025
> 12:44 PM
> >
> > > -Original Message-
> > > From: Michael Kelley Sent: Thursday, January 30,
> > > 2025 3:20 PM
> > >
> > > From:
From: Thomas Tai Sent: Thursday, January 30, 2025 12:44
PM
>
> > -Original Message-
> > From: Michael Kelley
> > Sent: Thursday, January 30, 2025 3:20 PM
> > To: Thomas Tai ; mhkelle...@gmail.com;
> > haiya...@microsoft.com; wei@kernel.org; d
From: Thomas Tai Sent: Thursday, January 30, 2025 10:50
AM
>
> Sorry for the typo in the subject title. It should have been 'hyperv_fb soft
> lockup on
> Azure Gen2 VM when taking kdump or executing kexec'
>
> Thomas
>
> >
> > Hi Michael,
> >
On Mon, 30 Sep 2024 13:20:46 +0200, Julia Lawall wrote:
> Reorganize kerneldoc parameter names to match the parameter
> order in the function header.
>
> The misordered cases were identified using the following
> Coccinelle semantic patch:
>
> //
> @initialize:ocaml@
> @@
>
> [...]
Applied to
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 274 ++-
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 1948 -
> 5 files changed, 2683 insertions(+), 1128 deletions(-)
I gave your changes a quick test on my RK3568 device and did not find
any regressions ->
Tested-by: Michael Riesch # on RK3568
Thanks and best regards,
Michael
> > Diff from V3: as Greg KH and Lucas Stach noticed, there was a
> > behavioural change between the two versions: I used guard(spinlock),
> > while the expected behaviour should have come from a spinlock_irqsave
> > guard. This has been fixed.
> >
Maybe you should j
tested and even measured and decoded the DSI link and the LVDS
stream. But IIRC this delay was only to compensate the difference
between the DSI clock and the LVDS clock, that is, if you push the
pixel stream slower into the bridge than the bridge is pushing it
out to the LVDS panel.
So the back porch should be irrelevant here (?!).
-michael
signature.asc
Description: PGP signature
didn't
post, which had this line removed. Will post a new version soon.
Probably also going to split the patches because it seems due to
the controversy in patch 01/20 this whole series is ignored.
-michael
signature.asc
Description: PGP signature
; get merged), other than some other conversion commits for other MediaTek
> > DTs from
> > myself.
> >
> > As for the MT8195/NIO12L commits, I'm planning to send them on the lists
> > tomorrow,
> > along with some code to properly support devicetree over
Hi Doug
On Wed, Aug 7, 2024 at 11:02 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Aug 7, 2024 at 5:39 AM Michael Nazzareno Trimarchi
> wrote:
> >
> > Hi Doug
> >
> > +cc Doug
> >
> > I have seen that you have done some re-working a
Hi Doug
+cc Doug
I have seen that you have done some re-working and investigation on
drm stack, do you have some
suggestion on this case?
On Mon, Jun 24, 2024 at 8:53 PM Michael Trimarchi
wrote:
>
> The shutdown function can be called when the display is already
> unprepared. Fo
Y altogether to change
its PLL). But doing so will violate the bridge requirements again.
-michael
[1] https://lore.kernel.org/dri-devel/d2r83vfpuwe3.3mbx3lqocd...@kernel.org/
signature.asc
Description: PGP signature
; DMT028VGHMCMI-1A - ST7701
> DMT028VGHMCMI-1D - ILI9806E
>
> Signed-off-by: Marek Vasut
Reviewed-by: Michael Walle
-michael
> >>>> Thank you for testing and keeping up with this. I will wait for more
> >>>> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> >>>> objections, then I can merge it in a week or two ?
> >>>
> >>>
>-Original Message-
>From: Daniel Vetter
>Sent: Tuesday, July 16, 2024 5:34 AM
>To: Ruhl, Michael J
>Cc: Dave Airlie ; dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH] drm/test: fix the gem shmem test to map the sg table.
>
>On Mon, Jul 15, 2024 at 04:07:57P
I.e. just because you have an sgt pointer, should you also have a mapping?
If the errors are really just noise (form the specific platforms), and this
patch is covering
for that, then:
Reviewed-by: Michael J. Ruhl
Thanks,
Mike
>This also sets a 64-bit dma mask, as I see an swiotlb warning if I
ard
>declaration of oops_to_nvram()
>
> Signed-off-by: Jocelyn Falempe
> ---
> arch/powerpc/kernel/nvram_64.c | 8
> arch/powerpc/platforms/powernv/opal-kmsg.c | 4 ++--
Acked-by: Michael Ellerman (powerpc)
cheers
Jocelyn Falempe writes:
> On 02/07/2024 14:26, Jocelyn Falempe wrote:
>> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
>> callback.
>> This patch adds a new struct kmsg_dump_detail, that will hold the
>> reason and description, and pass it to the dump() callback.
>>
>> To a
Hi Marek,
> >> Thank you for testing and keeping up with this. I will wait for more
> >> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> >> objections, then I can merge it in a week or two ?
> >
> > I'll try to use your ap
On Wed Jul 10, 2024 at 9:12 PM CEST, Doug Anderson wrote:
> Hi,
>
> On Wed, Jul 10, 2024 at 2:02 AM Michael Walle wrote:
> >
> > On Wed Jul 10, 2024 at 10:47 AM CEST, Cong Yang wrote:
> > > Break select page cmds into helper function.
> >
> > Why though?
ight from the datasheet. So,
I'd like to keep it that way.
-michael
> Signed-off-by: Cong Yang
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9806e.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9806
On Mon, Jun 10, 2024 at 04:55:38PM +0800, Lu Baolu wrote:
> Replace iommu_domain_alloc() with iommu_paging_domain_alloc().
>
> Signed-off-by: Lu Baolu
Acked-by: Michael S. Tsirkin
I assume it's merged with the rest of the stuff, right?
> ---
> drivers/vhost/vdpa.c | 14
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display
controller.
Co-developed-by: Gunnar Dibbern
Signed-off-by: Gunnar Dibbern
Signed-off-by: Michael Walle
---
MAINTAINERS | 5 +
drivers/gpu/drm/panel/Kconfig | 9
Add the device tree binding for the Ilitek ILI9806E controller which can
be found on the Ortustech COME35H3P70ULC DSI display panel.
There are no peculiarities except for two different power signals.
Reviewed-by: Conor Dooley
Signed-off-by: Michael Walle
---
.../display/panel/ilitek
Add initial support for the 480x640 DSI panel from Ortustech. The
panel uses an Ilitek ILI9806E panel driver IC.
v2:
- use drm_connector_helper_get_modes_fixed(), thanks Dmitry.
- slight header files cleanup
Michael Walle (2):
dt-bindings: display: panel: add Ilitek ili9806e panel controller
On Wed Jun 26, 2024 at 5:21 AM CEST, Marek Vasut wrote:
> Thank you for testing and keeping up with this. I will wait for more
> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> objections, then I can merge it in a week or two ?
I'll try to use your a
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display
controller.
Co-developed-by: Gunnar Dibbern
Signed-off-by: Gunnar Dibbern
Signed-off-by: Michael Walle
---
MAINTAINERS | 5 +
drivers/gpu/drm/panel/Kconfig | 9
Add the device tree binding for the Ilitek ILI9806E controller which can
be found on the Ortustech COME35H3P70ULC DSI display panel.
There are no peculiarities except for two different power signals.
Signed-off-by: Michael Walle
---
.../display/panel/ilitek,ili9806e.yaml| 63
Add initial support for the 480x640 DSI panel from Ortustech. The
panel uses an Ilitek ILI9806E panel driver IC.
Michael Walle (2):
dt-bindings: display: panel: add Ilitek ili9806e panel controller
drm/panel: add Ilitek ILI9806E panel driver
.../display/panel/ilitek,ili9806e.yaml
The shutdown function can be called when the display is already
unprepared. For example during reboot this trigger a kernel
backlog. Calling the drm_panel_unprepare, allow us to avoid
to trigger the kernel warning
Signed-off-by: Michael Trimarchi
---
It's not obviovus if shutdown can be dr
Add OF graph support for board path
> dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
> drm/mediatek: Implement OF graphs support for display paths
Thanks!
Tested-by: Michael Walle # on kontron-sbc-i1200
-michael
signature.asc
Description: PGP signature
&data->third_path,
> &data->third_len);
> + if (ret == 0)
> + valid_output_found = true;
> + else if (ret != -ENODEV)
> + return ret;
> + }
> +
> + if (!valid_output_found)
> + return -ENODEV;
This doesn't work. My proposal just ignored the ENODEV error. Now
you'll return ENODEV if there is no output for a given mmsys. In my
case, that is true for the first mmsys. Subsequent mmsys's doesn't
get probed in that case, it seems.
Anyway, you shouldn't return ENODEV here because disabled just
means not available, i.e. it should be treated the same as
"output_present[] == false".
-michael
signature.asc
Description: PGP signature
: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
---
You can find v4 at [1]. Unfortunately, it was never applied and in the
meantime there was a change in mtk_find_possible_crtcs(). So I've
s more sensible.
>
> Granted that there can be several DSI devices sharing the DSI bus (aka
> split-link), I was toying with the idea of making the DSI host call
> attached DSI devices when the transition happens.
So almost the same, as this patch?
> I don't have a fully working P
On Mon May 6, 2024 at 3:34 PM CEST, Michael Walle wrote:
> This patchset fixes the bridge initialization according to the
> datasheet. Not sure how that even worked before. Maybe because the
> initialization was done prior to linux (?).
>
> The bridge has some peculiarities:
>
ready described but are disabled. An overlay (or maybe another
dts variant) can then just enable the pipeline/output port by
overwriting the status property.
Also, this is the usual DT usage, as a node with status = "disabled"
should just be skipped. Without handling this, the cur
s a missing
"rotation" property gracefully.
Also, all other panel drivers I checked handle the
of_drm_get_panel_orientation call as you suggested. Nice to see this
becoming aligned.
Reviewed-by: Michael Riesch
Thanks and best regards,
Michael
t_present[CRTC_MAIN]) {
> + ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_MAIN,
> + &data->main_path,
> &data->main_len);
> + if (ret)
if (ret && ret != -ENODEV)
> + ret
: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
---
You can find v4 at [1]. Unfortunately, it was never applied and in the
meantime there was a change in mtk_find_possible_crtcs(). So I've
Use the device resource managed version of drm_bridge_add(). This
simplifies the error handling and we can get rid of tc_remove_bridge().
Also, add a check for the return code.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 -
1 file changed, 4
d the additional
reset, nor the additional write to VFUEN. With that fixed, the init
sequence is exactly how the vendor is requiring it.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 62 +++
1 file changed, 37 insertions(+), 25 deletions(-)
: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index d5b3d691d2c1..99dbbb1fee78 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm
1 - 100 of 1064 matches
Mail list logo
