From: Jon Hunter <jon-hunter@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Afzal Mohammed <afzal@ti.com>
Subject: Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
Date: Mon, 4 Feb 2013 09:05:36 -0600 [thread overview]
Message-ID: <510FCE40.5040202@ti.com> (raw)
In-Reply-To: <20130202181147.GC577@atomide.com>
On 02/02/2013 12:11 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [130201 17:25]:
>>
>> On 02/01/2013 03:51 PM, Tony Lindgren wrote:
>>>
>>> How about let's fix this properly to start with so we don't add
>>> more blockers moving this code to drivers/bus?
>>>
>>> Looks like gpmc_mem_init() gets called from gpmc_probe() so
>>> we can pass that information in pdev.
>>
>> I wondered if you would suggest that ;-)
>
> :)
>
>> I definitely can and it is probably best. Things like this become
>> painful when we move to device-tree. We really need a generic way for
>> passing stuff like this to drivers for omap. Our options are auxdata or
>> bus notifiers. I am wondering whether we can plug pdata in the
>> omap_device bus notifier for device-tree. Let me know if you have any
>> thoughts.
>
> Hmm but in this case can't you just do it based on the compatible
> flag? For legacy systems we also need to pass it in pdata.
This is a boot-time configuration. So really you need to read the
control status register at boot and then determine the mapping. We could
store the address of the control status read in the pdata, but I think
that is a bit of a hack.
> Regarding omap_device, we should find a way to keep the dependencies
> between drivers and the bus code down to minimum. So ideally things
> like this would be only done using just the compatible flag. But the
> pdata we cannot remove quite yet.
Agree. However, there are several drivers today (gpio, dmtimer, mmc,
serial, dss, etc), that make use of a function pointer to
omap_pm_get_dev_context_loss_count() to determine when the peripheral's
state has been lost. When booting with DT this function pointer is not
populated and so with DT we currently have no way to determine this. I
see this as a blocker to migrating completely to DT. Ideally we would
find a way for RPM to handle this and remove the function pointer.
However, right now we still need a generic way to pass this type of
platform data to drivers.
Cheers
Jon
WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation
Date: Mon, 4 Feb 2013 09:05:36 -0600 [thread overview]
Message-ID: <510FCE40.5040202@ti.com> (raw)
In-Reply-To: <20130202181147.GC577@atomide.com>
On 02/02/2013 12:11 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [130201 17:25]:
>>
>> On 02/01/2013 03:51 PM, Tony Lindgren wrote:
>>>
>>> How about let's fix this properly to start with so we don't add
>>> more blockers moving this code to drivers/bus?
>>>
>>> Looks like gpmc_mem_init() gets called from gpmc_probe() so
>>> we can pass that information in pdev.
>>
>> I wondered if you would suggest that ;-)
>
> :)
>
>> I definitely can and it is probably best. Things like this become
>> painful when we move to device-tree. We really need a generic way for
>> passing stuff like this to drivers for omap. Our options are auxdata or
>> bus notifiers. I am wondering whether we can plug pdata in the
>> omap_device bus notifier for device-tree. Let me know if you have any
>> thoughts.
>
> Hmm but in this case can't you just do it based on the compatible
> flag? For legacy systems we also need to pass it in pdata.
This is a boot-time configuration. So really you need to read the
control status register at boot and then determine the mapping. We could
store the address of the control status read in the pdata, but I think
that is a bit of a hack.
> Regarding omap_device, we should find a way to keep the dependencies
> between drivers and the bus code down to minimum. So ideally things
> like this would be only done using just the compatible flag. But the
> pdata we cannot remove quite yet.
Agree. However, there are several drivers today (gpio, dmtimer, mmc,
serial, dss, etc), that make use of a function pointer to
omap_pm_get_dev_context_loss_count() to determine when the peripheral's
state has been lost. When booting with DT this function pointer is not
populated and so with DT we currently have no way to determine this. I
see this as a blocker to migrating completely to DT. Ideally we would
find a way for RPM to handle this and remove the function pointer.
However, right now we still need a generic way to pass this type of
platform data to drivers.
Cheers
Jon
next prev parent reply other threads:[~2013-02-04 15:05 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 16:38 [PATCH 0/2] ARM: OMAP2+: GPMC Fixes Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 16:38 ` [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 22:08 ` Tony Lindgren
2013-02-01 22:08 ` Tony Lindgren
2013-02-08 22:56 ` Jon Hunter
2013-02-08 22:56 ` Jon Hunter
2013-02-09 15:55 ` Ezequiel Garcia
2013-02-09 15:55 ` Ezequiel Garcia
2013-02-14 12:04 ` Philip, Avinash
2013-02-14 12:04 ` Philip, Avinash
2013-02-16 22:37 ` Grazvydas Ignotas
2013-02-16 22:37 ` Grazvydas Ignotas
2013-02-01 16:38 ` [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation Jon Hunter
2013-02-01 16:38 ` Jon Hunter
2013-02-01 21:51 ` Tony Lindgren
2013-02-01 21:51 ` Tony Lindgren
2013-02-02 1:22 ` Jon Hunter
2013-02-02 1:22 ` Jon Hunter
2013-02-02 18:11 ` Tony Lindgren
2013-02-02 18:11 ` Tony Lindgren
2013-02-04 15:05 ` Jon Hunter [this message]
2013-02-04 15:05 ` Jon Hunter
2013-02-04 17:45 ` Tony Lindgren
2013-02-04 17:45 ` Tony Lindgren
2013-02-04 18:46 ` Jon Hunter
2013-02-04 18:46 ` Jon Hunter
2013-02-04 19:15 ` Tony Lindgren
2013-02-04 19:15 ` Tony Lindgren
2013-02-04 19:33 ` Jon Hunter
2013-02-04 19:33 ` Jon Hunter
2013-02-04 19:47 ` Tony Lindgren
2013-02-04 19:47 ` Tony Lindgren
2013-02-04 19:51 ` Jon Hunter
2013-02-04 19:51 ` Jon Hunter
2013-02-04 22:12 ` Jon Hunter
2013-02-04 22:12 ` Jon Hunter
2013-02-04 22:45 ` Jon Hunter
2013-02-04 22:45 ` Jon Hunter
2013-02-05 23:34 ` Tony Lindgren
2013-02-05 23:34 ` Tony Lindgren
2013-02-06 0:22 ` Jon Hunter
2013-02-06 0:22 ` Jon Hunter
2013-02-06 17:28 ` Tony Lindgren
2013-02-06 17:28 ` 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=510FCE40.5040202@ti.com \
--to=jon-hunter@ti.com \
--cc=afzal@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.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.