Also, IMHO reset should always be done during probe() so driver can be
dead sure that we're starting from a known state. This is even more
Depends on the IP block. Eg: you might want to keep the screen showing the
contents drawn by the bootloader while booting the kernel and smoothly
change
Peter == Peter De Schrijver pdeschrij...@nvidia.com writes:
Also, IMHO reset should always be done during probe() so driver can be
dead sure that we're starting from a known state. This is even more
Peter Depends on the IP block. Eg: you might want to keep the screen
Peter showing the
Hi,
I think Vaibhav has covered most of the ground here, but just a few
comments:
On Fri, 15 Feb 2013, Felipe Balbi wrote:
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't
why not ? It's part of the
Hi,
On Wed, Feb 20, 2013 at 05:38:49PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't
just now I noticed this fun fact:
driver's should touch *their* SYSCONFIG registers
You're stating yourself that SYSCONFIG belongs to the IP and the
Hi,
On Wed, 20 Feb 2013, Felipe Balbi wrote:
On Wed, Feb 20, 2013 at 05:38:49PM +, Paul Walmsley wrote:
Drivers shouldn't touch their IP block's SYSCONFIG registers. They
don't
just now I noticed this fun fact:
driver's should touch *their* SYSCONFIG registers
You're
On Wed, Feb 20, 2013 at 09:16:38PM +0200, Felipe Balbi wrote:
Also, IMHO reset should always be done during probe() so driver can be
dead sure that we're starting from a known state. This is even more
important for the complex IPs which are licensed from RTL vendors and
are used in different
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch the SYSCONFIG register
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are allowed. That would require adding
a function pointer to struct
On Tue, Feb 19, 2013 at 03:30:01PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
On Tue, Feb 19, 2013 at 03:30:01PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
The other option could be to allow custom ioremap function pointers
based on address range in
* Paul Walmsley p...@pwsan.com [130219 07:30]:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed
Hi,
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need
* Felipe Balbi ba...@ti.com [130219 09:01]:
Hi,
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
If you want such things as pci_enable_device(), then what you're actually
asking for is omap_enable_device() for OMAP devices. OMAP devices are
already specific
Hi,
On Tue, Feb 19, 2013 at 09:43:36AM -0800, Tony Lindgren wrote:
On Tue, Feb 19, 2013 at 08:38:20AM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the
[...]
Just to recap what we've discussed earlier, the reasons why we want
reset and idle functions should be in the driver specific header are:
1. There's often driver specific logic needed in addition to the
syconfig tinkering in the reset/idle functions.
It's been a while since
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 10:26]:
On Tue, Feb 19, 2013 at 08:30:53AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [130219 07:49]:
If you want such things as pci_enable_device(), then what you're actually
asking for is
Hi,
On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
[ ... ]
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed in certain error recovery
scenarios.
Hi,
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of huge churn, think again. Remember, churn is evil. I've
complained to
Felipe Balbi ba...@ti.com writes:
Hi,
On Tue, Feb 19, 2013 at 11:16:38AM -0800, Kevin Hilman wrote:
[ ... ]
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed
Hi,
On Tue, Feb 19, 2013 at 11:50:37AM -0800, Kevin Hilman wrote:
The other problem is the where reset is need during runtime. Again,
what are the specific examples here? The one I can think of off the top
of my head is I2C, where it's needed in certain error recovery
scenarios.
* Felipe Balbi ba...@ti.com [130219 11:47]:
Hi,
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of huge churn, think again.
Hi,
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
However... if you think you're going to get away with another total
rewrite of OMAP device support away from hwmod to a new scheme with a
new load of
* Felipe Balbi ba...@ti.com [130219 14:26]:
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
..that means massive amount of churn in the board-*.c files to convert
them to various init functions to be called from board-generic.c and
removing the ones that are working with
Hi,
On Tue, Feb 19, 2013 at 02:31:28PM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130219 14:26]:
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
..that means massive amount of churn in the board-*.c files to convert
them to various init functions to be
On Wednesday 20 February 2013 12:46 AM, Kevin Hilman wrote:
[...]
Just to recap what we've discussed earlier, the reasons why we want
reset and idle functions should be in the driver specific header are:
1. There's often driver specific logic needed in addition to the
syconfig tinkering
On Sat, Feb 16, 2013 at 11:18:36, Shilimkar, Santosh wrote:
[...]
For the duplicate ioremapping, I don't think there's any need to
do it if we get things right.
Note that if the ioremap matches a static map area there is no cost to
ioremap it multiple times.
Thats true though now
On Monday 18 February 2013 01:38 PM, Bedia, Vaibhav wrote:
On Sat, Feb 16, 2013 at 11:18:36, Shilimkar, Santosh wrote:
[...]
For the duplicate ioremapping, I don't think there's any need to
do it if we get things right.
Note that if the ioremap matches a static map area there is no cost to
Santosh Shilimkar santosh.shilim...@ti.com writes:
On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by
Felipe Balbi ba...@ti.com writes:
Hi,
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for hwmod from DT as Santosh has
Hi,
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for hwmod from DT as Santosh has already demonstrated.
Then we also want
+ Rafael,
On Saturday 16 February 2013 02:25 PM, Felipe Balbi wrote:
Hi,
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for
Hi,
On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote:
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for
On Saturday 16 February 2013 02:52 PM, Felipe Balbi wrote:
Hi,
On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote:
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Regarding ioremap(), it seems reasonable for drivers to call ioremap(), as
long as the implementation of ioremap() can be overridden by the device's
bus. PCI device drivers already do this -- albeit in a PCI-specific way
--
On Thu, Feb 14, 2013 at 09:40:29PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va = dev-bus-iounmap( ... );
Something like
Russell,
On Friday 15 February 2013 03:46 PM, Russell King - ARM Linux wrote:
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
[..]
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va =
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual ioremap() issue discussed here if the hook
maintains the list of mapped ios.
I was even thinking of having such intelligence within the
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual ioremap() issue discussed here if the hook
maintains the list of
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that relyance on hwmod by moving SYSCONFIG
handling to
Hi,
On Fri, Feb 15, 2013 at 07:40:04AM -0800, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller() hook ? This can allow
us to avoid the dual
Hi,
On Fri, Feb 15, 2013 at 08:30:32AM -0800, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of
On Friday 15 February 2013 09:10 PM, Kevin Hilman wrote:
Felipe Balbi ba...@ti.com writes:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that
On Friday 15 February 2013 10:00 PM, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of
On Fri, 15 Feb 2013, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller()
On Saturday 16 February 2013 11:06 AM, Nicolas Pitre wrote:
On Fri, 15 Feb 2013, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar
On Friday 15 February 2013 10:12 PM, Felipe Balbi wrote:
Hi,
On Fri, Feb 15, 2013 at 08:30:32AM -0800, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that relyance on hwmod by moving SYSCONFIG
handling to driver itself. Note that this also
fixes a
* Felipe Balbi ba...@ti.com [130214 03:19]:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own SYSCONFIG
register.
Remove that relyance on hwmod by moving SYSCONFIG
Hi,
On Thu, Feb 14, 2013 at 09:12:53AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130214 03:19]:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function pointers
provided by hwmod to change its own
* Felipe Balbi ba...@ti.com [130214 10:00]:
Hi,
On Thu, Feb 14, 2013 at 09:12:53AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130214 03:19]:
Currently the omap-serial driver will not
work properly if booted via DT with CPUIDLE
enabled because it depends on function
Hi,
On Thu, Feb 14, 2013 at 10:12:17AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130214 10:00]:
Hi,
On Thu, Feb 14, 2013 at 09:12:53AM -0800, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130214 03:19]:
Currently the omap-serial driver will not
work properly
* Felipe Balbi ba...@ti.com [130214 11:31]:
On Thu, Feb 14, 2013 at 10:12:17AM -0800, Tony Lindgren wrote:
And only in the case there is no driver, hwmod can parse the address
space from DT for the unclaimed hardware in the late_initcall.
sounds good. But then it means our DTS files
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch the SYSCONFIG register during pm_runtime suspend
and resume operations, and during device enable and disable operations.
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va = dev-bus-iounmap( ... );
Something like this is what I was thinking. Obviously there would be more
patches needed,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
va = dev-bus-iounmap( ... );
And this should simply be
dev-bus-iounmap( ... );
I regret the error...
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
* Paul Walmsley p...@pwsan.com [130214 12:51]:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch the SYSCONFIG register during pm_runtime suspend
and resume
* Paul Walmsley p...@pwsan.com [130214 13:44]:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap( ... );
va = dev-bus-iounmap( ... );
Something like this is what I was
Hi,
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch the SYSCONFIG register during pm_runtime suspend
On Thu, Feb 14, 2013 at 02:47:10PM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 13:44]:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev-bus-ioremap(
On Thu, Feb 14, 2013 at 02:22:47PM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod does need to touch
On Fri, Feb 15, 2013 at 12:23:08, Balbi, Felipe wrote:
On Thu, Feb 14, 2013 at 02:22:47PM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 12:51]:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
Hi,
On Fri, Feb 15, 2013 at 12:14:29, Balbi, Felipe wrote:
Hi,
On Thu, Feb 14, 2013 at 08:47:53PM +, Paul Walmsley wrote:
Hi,
On Thu, 14 Feb 2013, Tony Lindgren wrote:
I don't think so as hwmod should only touch the sysconfig space
when no driver has claimed it.
hwmod
+ Tero, Rajendra, Kevin
On Friday 15 February 2013 12:16 PM, Felipe Balbi wrote:
On Thu, Feb 14, 2013 at 02:47:10PM -0800, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [130214 13:44]:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a
65 matches
Mail list logo
