All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Adam Ford <aford173@gmail.com>
Cc: Linux-OMAP <linux-omap@vger.kernel.org>,
	"Andrew F . Davis" <afd@ti.com>,
	"Dave Gerlach" <d-gerlach@ti.com>,
	"Faiz Abbas" <faiz_abbas@ti.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Keerthy <j-keerthy@ti.com>, "Nishanth Menon" <nm@ti.com>,
	"Peter Ujfalusi" <peter.ujfalusi@ti.com>,
	"Roger Quadros" <rogerq@ti.com>, "Suman Anna" <s-anna@ti.com>,
	"Tero Kristo" <t-kristo@ti.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	"André Hentschel" <nerv@dawncrow.de>,
	"H . Nikolaus Schaller" <hns@goldelico.com>
Subject: Re: [PATCH 6/7] bus: ti-sysc: Implement SoC revision handling
Date: Fri, 4 Mar 2022 08:56:59 +0200	[thread overview]
Message-ID: <YiG4O2h4oVX7CqIe@atomide.com> (raw)
In-Reply-To: <CAHCN7xJ0j4kZXiQs-5GrrKLxXYgkYJsnNDreH0MKi8mHPs_Xvw@mail.gmail.com>

Hi,

* Adam Ford <aford173@gmail.com> [220302 14:37]:
> I apologize for digging up an old thread, but I finally managed to get
> my hands on an OMAP3503.  It seems like older kernels do not boot at
> all or hang somewhere in the boot process.  I am still seeing a
> difference in behavior between OMAP3503 and OMAP3530, where 3505
> throws a bunch of splat and a kernel panic, while the 3530 appears to
> boot happily.
> 
> Using the latest 5.17-rc6, I had to remove some IVA and SGX references
> from omap_l3_smx.h to get the 3503 to stop crashing on boot.

OK interesting, I did not know those registers are not accessible
on 3503.

> Do you have any ideas how we can make the omap3_l3_app_bases and
> omap3_l3_debug_bases more cleanly remove the IVA and SGX references
> if/when OMAP3503 is detected?  I assume the same algorithm would have
> to detect a AM3703 as well.  I'm trying to get my hands on an AM3703
> to see if there is similar behavior as what I'm seeing on the
> OMAP3503.

As there are possibly multiple omap3 variants used on the same
boards, we need to rely on the runtime detection of the SoC.
So yeah soc_device_attribute is the way to go here.

I don't recall any similar issues booting 3703 but it's been a while
so worth testing for sure.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Adam Ford <aford173@gmail.com>
Cc: "Nishanth Menon" <nm@ti.com>, "Tero Kristo" <t-kristo@ti.com>,
	"Dave Gerlach" <d-gerlach@ti.com>, Keerthy <j-keerthy@ti.com>,
	"H . Nikolaus Schaller" <hns@goldelico.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"André Hentschel" <nerv@dawncrow.de>,
	"Andrew F . Davis" <afd@ti.com>,
	"Peter Ujfalusi" <peter.ujfalusi@ti.com>,
	"Faiz Abbas" <faiz_abbas@ti.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	arm-soc <linux-arm-kernel@lists.infradead.org>,
	"Roger Quadros" <rogerq@ti.com>
Subject: Re: [PATCH 6/7] bus: ti-sysc: Implement SoC revision handling
Date: Fri, 4 Mar 2022 08:56:59 +0200	[thread overview]
Message-ID: <YiG4O2h4oVX7CqIe@atomide.com> (raw)
In-Reply-To: <CAHCN7xJ0j4kZXiQs-5GrrKLxXYgkYJsnNDreH0MKi8mHPs_Xvw@mail.gmail.com>

Hi,

* Adam Ford <aford173@gmail.com> [220302 14:37]:
> I apologize for digging up an old thread, but I finally managed to get
> my hands on an OMAP3503.  It seems like older kernels do not boot at
> all or hang somewhere in the boot process.  I am still seeing a
> difference in behavior between OMAP3503 and OMAP3530, where 3505
> throws a bunch of splat and a kernel panic, while the 3530 appears to
> boot happily.
> 
> Using the latest 5.17-rc6, I had to remove some IVA and SGX references
> from omap_l3_smx.h to get the 3503 to stop crashing on boot.

OK interesting, I did not know those registers are not accessible
on 3503.

> Do you have any ideas how we can make the omap3_l3_app_bases and
> omap3_l3_debug_bases more cleanly remove the IVA and SGX references
> if/when OMAP3503 is detected?  I assume the same algorithm would have
> to detect a AM3703 as well.  I'm trying to get my hands on an AM3703
> to see if there is similar behavior as what I'm seeing on the
> OMAP3503.

As there are possibly multiple omap3 variants used on the same
boards, we need to rely on the runtime detection of the SoC.
So yeah soc_device_attribute is the way to go here.

I don't recall any similar issues booting 3703 but it's been a while
so worth testing for sure.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-03-04  6:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 19:52 [PATCH 0/7] ti-sysc driver fix for hdq1w and few improvments Tony Lindgren
2020-02-21 19:52 ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 1/7] bus: ti-sysc: Fix 1-wire reset quirk Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 2/7] bus: ti-sysc: Rename clk related quirks to pre_reset and post_reset quirks Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 3/7] ti-sysc: Improve reset to work with modules with no sysconfig Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 4/7] bus: ti-sysc: Consider non-existing registers too when matching quirks Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 5/7] bus: ti-sysc: Don't warn about legacy property for nested ti-sysc devices Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2020-02-21 19:52 ` [PATCH 6/7] bus: ti-sysc: Implement SoC revision handling Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren
2022-03-02 14:38   ` Adam Ford
2022-03-02 14:38     ` Adam Ford
2022-03-04  6:56     ` Tony Lindgren [this message]
2022-03-04  6:56       ` Tony Lindgren
2022-03-04 13:57       ` Adam Ford
2022-03-04 13:57         ` Adam Ford
2020-02-21 19:52 ` [PATCH 7/7] bus: ti-sysc: Handle module unlock quirk needed for some RTC Tony Lindgren
2020-02-21 19:52   ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YiG4O2h4oVX7CqIe@atomide.com \
    --to=tony@atomide.com \
    --cc=afd@ti.com \
    --cc=aford173@gmail.com \
    --cc=d-gerlach@ti.com \
    --cc=faiz_abbas@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hns@goldelico.com \
    --cc=j-keerthy@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nerv@dawncrow.de \
    --cc=nm@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=rogerq@ti.com \
    --cc=s-anna@ti.com \
    --cc=t-kristo@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.