Hi Dario,
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>
> FWIW, this looks rather messy now. The drm-tip doesn't build.
>
> There was a ne
Hi Michael,
On Mon, Jan 29, 2024 at 5:06 PM Michael Walle wrote:
>
> >> Just FYI this conflictted pretty heavily with drm-misc-next changes in
> >> the same area, someone should check drm-tip has the correct
> >> resolution, I'm not really sure what is definitely should be.
> >
> > FWIW, this loo
On 29.01.24 10:20, Frieder Schrempf wrote:
> On 26.01.24 19:28, Dave Airlie wrote:
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>>
>> Dave.
>
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
Also merge commit 663a907e199b (Merge remote-tracking branch
'drm-misc/drm-misc-next' into drm-tip) is broken because it
completely removes samsung_dsim_atomic_disable(). Dunno whats
going on there.
Actually, that merge commit looks even worse. It somehow folds
the original samsung_dsim_atomic_d
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
On 26.01.24 19:28, Dave Airlie wrote:
> Just FYI this conflictted pretty heavily with drm-misc-next changes in
> the same area, someone should check drm-tip has the correct
> resolution, I'm not really sure what is definitely should be.
>
> Dave.
Thanks! I took a quick look at what is now in Linu
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
Dave.
On Fri, 19 Jan 2024 at 16:37, Inki Dae wrote:
>
> Really sorry for late. Will pick it up.
>
> Tha
Really sorry for late. Will pick it up.
Thanks,
Inki Dae
2024년 1월 9일 (화) 오후 9:50, Daniel Vetter 님이 작성:
> On Tue, Jan 09, 2024 at 09:47:20AM +0100, Michael Walle wrote:
> > Hi,
> >
> > > > Inki, are you picking this up? Or if not, who will?
> > >
> > > I can pick it up but it would be better to g
On Tue, Jan 09, 2024 at 09:47:20AM +0100, Michael Walle wrote:
> Hi,
>
> > > Inki, are you picking this up? Or if not, who will?
> >
> > I can pick it up but it would be better to go to the drm-misc tree. If
> > nobody cares about it then I will pick it up. :)
> >
> > acked-by : Inki Dae
>
> W
Hi,
Inki, are you picking this up? Or if not, who will?
I can pick it up but it would be better to go to the drm-misc tree. If
nobody cares about it then I will pick it up. :)
acked-by : Inki Dae
Who is going to pick this up? Who has access to the drm-misc tree?
-michael
2023년 12월 19일 (화) 오전 11:11, Frieder Schrempf 님이
작성:
> On 01.12.23 10:04, Michael Walle wrote:
> >> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
> >> mode. It seems the bridge internally queues DSI packets and when the
> >> FORCE_STOP_STATE bit is cleared, they are sent i
On 01.12.23 10:04, Michael Walle wrote:
>> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
>> mode. It seems the bridge internally queues DSI packets and when the
>> FORCE_STOP_STATE bit is cleared, they are sent in close succession
>> without any useful timing (this also me
The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
mode. It seems the bridge internally queues DSI packets and when the
FORCE_STOP_STATE bit is cleared, they are sent in close succession
without any useful timing (this also means that the DSI lanes won't go
into LP-11 mode). T
Hi,
My current guess would be that the issue I was seeing was already fixed
with dd9e329af723 ("drm/bridge: ti-sn65dsi83: Fix enable/disable flow
to
meet spec") and I didn't properly test both changes separately.
I had the exact same thought, as I've found your second patch.
My cheap scope
Hi Michael,
On 13.11.23 17:43, Michael Walle wrote:
> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
> mode. It seems the bridge internally queues DSI packets and when the
> FORCE_STOP_STATE bit is cleared, they are sent in close succession
> without any useful timing (thi
Hi Alexander,
The FORCE_STOP_STATE bit is unsuitable to force the DSI link into
LP-11
mode. It seems the bridge internally queues DSI packets and when the
FORCE_STOP_STATE bit is cleared, they are sent in close succession
without any useful timing (this also means that the DSI lanes won't go
in
Hi Michael,
Am Montag, 13. November 2023, 17:43:44 CET schrieb Michael Walle:
> The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
> mode. It seems the bridge internally queues DSI packets and when the
> FORCE_STOP_STATE bit is cleared, they are sent in close succession
> with
The FORCE_STOP_STATE bit is unsuitable to force the DSI link into LP-11
mode. It seems the bridge internally queues DSI packets and when the
FORCE_STOP_STATE bit is cleared, they are sent in close succession
without any useful timing (this also means that the DSI lanes won't go
into LP-11 mode). Th
19 matches
Mail list logo
