[0/3] ti-sysc changes for probing DSS with dts data

Message

Tony Lindgren Feb. 24, 2020, 7:12 p.m. UTC

Hi all,

Here are some changes to start probing display susbsystem (DSS) with
device tree data instead of platform data.

These changes are against v5.6-rc1, and depend on the earlier series
"[PATCH 0/7] ti-sysc driver fix for hdq1w and few improvments".

I'll be posting the related dts changes separately.

Regards,

Tony


Tony Lindgren (3):
  drm/omap: Prepare DSS for probing without legacy platform data
  bus: ti-sysc: Detect display subsystem related devices
  bus: ti-sysc: Implement display subsystem reset quirk

 drivers/bus/ti-sysc.c                         | 144 ++++++++++++++++++
 drivers/gpu/drm/omapdrm/dss/dss.c             |  25 ++-
 .../gpu/drm/omapdrm/dss/omapdss-boot-init.c   |  25 ++-
 include/linux/platform_data/ti-sysc.h         |   1 +
 4 files changed, 184 insertions(+), 11 deletions(-)

Comments

Tony Lindgren Feb. 24, 2020, 11:43 p.m. UTC | #1

* Sebastian Reichel <[e-mail]> [200224 23:32]:
> Hi,
> 
> On Mon, Feb 24, 2020 at 11:12:28AM -0800, Tony Lindgren wrote:
> > In order to probe display subsystem (DSS) components with ti-sysc
> > interconnect target module without legacy platform data and using
> > devicetree, we need to update dss probing a bit.
> > 
> > In the device tree, we will be defining the data also for the interconnect
> > target modules as DSS really is a private interconnect. There is some
> > information about that in 4460 TRM in "Figure 10-3. DSS Integration" for
> > example where it mentions "32-bit interconnect (SLX)".
> > 
> > The changes we need to make are:
> > 
> > 1. Parse also device tree subnodes for the compatible property fixup
> > 
> > 2. Update the component code to consider device tree subnodes
> > 
> > Cc: [e-mail]
> > Cc: Jyri Sarha <[e-mail]>
> > Cc: Laurent Pinchart <[e-mail]>
> > Cc: Tomi Valkeinen <[e-mail]>
> > Signed-off-by: Tony Lindgren <[e-mail]>
> > ---
> > 
> > This is needed for dropping DSS platform data that I'll be posting
> > seprately. If this looks OK, can you guys please test and ack?
> > 
> > ---
> 
> Reviewed-by: Sebastian Reichel <[e-mail]>
> 
> FWIW, I dropped omapdss-boot-init.c in my patch series updating DSI
> code to use common panel infrastructure, so this will conflict.

Hey that's great :) Sounds like we can set up an immutable branch
for just this $subject patch against v5.6-rc1 to resolve the
conflict. I can set it up for Tomi or Tomi can set it up for me,
whichever Tomi prefers.

Regards,

Tony

Tony Lindgren Feb. 27, 2020, 5:44 p.m. UTC | #2

Tomi,

* Tony Lindgren <[e-mail]> [200224 23:44]:
> * Sebastian Reichel <[e-mail]> [200224 23:32]:
> > Hi,
> > 
> > On Mon, Feb 24, 2020 at 11:12:28AM -0800, Tony Lindgren wrote:
> > > In order to probe display subsystem (DSS) components with ti-sysc
> > > interconnect target module without legacy platform data and using
> > > devicetree, we need to update dss probing a bit.
> > > 
> > > In the device tree, we will be defining the data also for the interconnect
> > > target modules as DSS really is a private interconnect. There is some
> > > information about that in 4460 TRM in "Figure 10-3. DSS Integration" for
> > > example where it mentions "32-bit interconnect (SLX)".
> > > 
> > > The changes we need to make are:
> > > 
> > > 1. Parse also device tree subnodes for the compatible property fixup
> > > 
> > > 2. Update the component code to consider device tree subnodes
> > > 
> > > Cc: [e-mail]
> > > Cc: Jyri Sarha <[e-mail]>
> > > Cc: Laurent Pinchart <[e-mail]>
> > > Cc: Tomi Valkeinen <[e-mail]>
> > > Signed-off-by: Tony Lindgren <[e-mail]>
> > > ---
> > > 
> > > This is needed for dropping DSS platform data that I'll be posting
> > > seprately. If this looks OK, can you guys please test and ack?
> > > 
> > > ---
> > 
> > Reviewed-by: Sebastian Reichel <[e-mail]>
> > 
> > FWIW, I dropped omapdss-boot-init.c in my patch series updating DSI
> > code to use common panel infrastructure, so this will conflict.
> 
> Hey that's great :) Sounds like we can set up an immutable branch
> for just this $subject patch against v5.6-rc1 to resolve the
> conflict. I can set it up for Tomi or Tomi can set it up for me,
> whichever Tomi prefers.

Do you want me to send you a pull request for just this one patch
against v5.6-rc1?

Regards,

Tony

Tomi Valkeinen March 2, 2020, 10:28 a.m. UTC | #3

On 27/02/2020 19:44, Tony Lindgren wrote:

>>> FWIW, I dropped omapdss-boot-init.c in my patch series updating DSI
>>> code to use common panel infrastructure, so this will conflict.
>>
>> Hey that's great :) Sounds like we can set up an immutable branch
>> for just this $subject patch against v5.6-rc1 to resolve the
>> conflict. I can set it up for Tomi or Tomi can set it up for me,
>> whichever Tomi prefers.
> 
> Do you want me to send you a pull request for just this one patch
> against v5.6-rc1?

It's probably easier if Sebastian drops the removal patch, and instead creates a patch that removes 
the panel-dsi-cm from omapdss_of_fixups_whitelist. That change should not conflict, and effectively 
makes the omapdss-boot-init.c a no-op.

We can then remove the file later.

  Tomi

Tony Lindgren March 2, 2020, 3:01 p.m. UTC | #4

* Tomi Valkeinen <[e-mail]> [200302 10:29]:
> On 27/02/2020 19:44, Tony Lindgren wrote:
> 
> > > > FWIW, I dropped omapdss-boot-init.c in my patch series updating DSI
> > > > code to use common panel infrastructure, so this will conflict.
> > > 
> > > Hey that's great :) Sounds like we can set up an immutable branch
> > > for just this $subject patch against v5.6-rc1 to resolve the
> > > conflict. I can set it up for Tomi or Tomi can set it up for me,
> > > whichever Tomi prefers.
> > 
> > Do you want me to send you a pull request for just this one patch
> > against v5.6-rc1?
> 
> It's probably easier if Sebastian drops the removal patch, and instead
> creates a patch that removes the panel-dsi-cm from
> omapdss_of_fixups_whitelist. That change should not conflict, and
> effectively makes the omapdss-boot-init.c a no-op.
> 
> We can then remove the file later.

OK for resolving the merge commit that works too.

Tomi, so do you care to ack the $subject patch though so I can set
up an immutable branch for us for the $subject patch?

Or Tomi, do you want to set up an immutable branch for me for the
$subject patch?

Regards,

Tony