On Monday 13 April 2009, Mark A. Greer wrote:
TBH, we've probably spent way more bits on this than its worth.
I think I'll remove da830_register_devices() (and enums), make the
da830 standard platform_device data global, and use
platform_add_devices() in the board code to add them (or just a
On Monday 13 April 2009, Mark A. Greer wrote:
I tend to be content to have Kconfig expose such messes.
Hmm, sounds like a bunch of 'depends on this !that ...'
in Kconfig files which could get messy.
It would be; use choice instead1 ;)
There may also be an option of some kind of
David Brownell davi...@pacbell.net writes:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Its unfortunate that the hook name in the drivers ATM is clk_enable().
I really *do not understand* where you're coming from at all.
I think what Mark is getting at is that it's unfortunate that the
On Fri, Apr 10, 2009 at 08:57:40PM +0400, Sergei Shtylyov wrote:
Hello.
Mark A. Greer wrote:
An example with the da830 evm is nand nor flash. The board has
both but only one can be used at a time.
Mark, you're ovesimlifying the matter here too much: NAND and NOR
flashes are on the
On Wed, Apr 08, 2009 at 02:58:18PM -0700, David Brownell wrote:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Its better than making a whole bunch of globals and a whole bunch of
platform_device_register() calls in every board file. That's
unnecessary code bloat. This routine (whatever
On Wed, Apr 08, 2009 at 02:30:52PM -0700, David Brownell wrote:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Maybe this will help.
Its just a hack for your dm355 spi example try to get my
point across. It uses lspc as the tag for what the device
is but the clk struct could be
On Mon, Apr 13, 2009 at 10:58:11AM -0700, Kevin Hilman wrote:
David Brownell davi...@pacbell.net writes:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Its unfortunate that the hook name in the drivers ATM is clk_enable().
I really *do not understand* where you're coming from at
On Wed, Apr 08, 2009 at 02:07:24PM -0700, David Brownell wrote:
[ this is the followup re points I didn't address first time ]
On Monday 06 April 2009, Mark A. Greer wrote:
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
...
Without coupling pinmux with the other two,
On Monday 13 April 2009, Kevin Hilman wrote:
David Brownell davi...@pacbell.net writes:
On Tuesday 07 April 2009, Mark A. Greer wrote:
Its unfortunate that the hook name in the drivers ATM is clk_enable().
I really *do not understand* where you're coming from at all.
I think
Hello.
Mark A. Greer wrote:
Pinmux is a distinct problem, and doing it right needs
information that's just not available to clock code.
All it needs to know is what device is being enabled which is
exactly the same thing the clock code needs to know and exactly
the same thing the psc code
Sergei Shtylyov wrote:
diff --git a/arch/arm/mach-davinci/da830.c
b/arch/arm/mach-davinci/da830.c
new file mode 100644
index 000..27c2976
--- /dev/null
+++ b/arch/arm/mach-davinci/da830.c
[...]
+static struct clk scr0_ss_clk = {
+.name= scr0_ss,
+.parent=
Hello.
David Brownell wrote:
Pinmux is a distinct problem, and doing it right needs
information that's just not available to clock code.
All it needs to know is what device is being enabled which is
exactly the same thing the clock code needs to know and exactly
the same thing the psc code
On Friday 10 April 2009, Sergei Shtylyov wrote:
No, you can't determine pins from device; those are functions
of how the board is wired.
This function is not a 1:1 mapping of pin to device as you probably
imagining it.
A mapping device--pins != a mapping pin--device, of course.
Which
Dave,
There are dozens of e-mails going back and forth, and we are still
unable to bridge the gap. If you don't mind, lets take a step back and
see if we can find some common grounds before moving forward. Here are
a few observations.
1. Pinmux conflict should never happen on a correctly
Kevin Hilman wrote:
From: Mark A. Greer mgr...@mvista.com
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
new file mode 100644
index 000..27c2976
--- /dev/null
+++ b/arch/arm/mach-davinci/da830.c
[...]
+static
Hello, I wrote:
+static struct clk tpcc_clk = {
+.name= tpcc,
+.parent= pll0_sysclk2,
+.lpsc= DA830_LPSC0_TPCC,
+.flags= ALWAYS_ENABLED,
+};
+
LPSC for tpcc (LPSC number ZERO) will not get enabled because of the
(clk-lpsc) check in davinci_clk_init
On Mon, Apr 06, 2009 at 07:20:34PM -0700, David Brownell wrote:
On Monday 06 April 2009, Mark A. Greer wrote:
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
On Tuesday 31 March 2009, Mark A. Greer wrote:
+enum {
+ DA830_PDEV_EDMA,
+ DA830_PDEV_I2C_0,
On Tue, Apr 07, 2009 at 11:51:16AM -0700, Mark A. Greer wrote:
On Mon, Apr 06, 2009 at 07:20:34PM -0700, David Brownell wrote:
The pinmux setup is *not* done by the driver, its done by code in
mach-davinci. Its only the triggering of the allocation that is done
by the driver. This is
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
On Tuesday 31 March 2009, Mark A. Greer wrote:
I'm sorry, but the more I read this, the less I understand it.
[David, as I reread this, I think I understand one of our disconnects.
On the da830 evm there are devices populated that
On Monday 06 April 2009, Mark A. Greer wrote:
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
On Tuesday 31 March 2009, Mark A. Greer wrote:
I'm sorry, but the more I read this, the less I understand it.
[David, as I reread this, I think I understand one of our
To: Nori, Sekhar
Cc: davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH 16/18] ARM: da830 - Add base DA830/OMAP-L137 SoC
support
On Wed, 2009-04-01 at 12:48 +0530, Nori, Sekhar wrote:
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Wednesday, April 01, 2009 12:23 PM
Rajashekhara, Sudhakar sudhakar@ti.com writes:
From: Mark A. Greer mgr...@mvista.com
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
new file mode 100644
index 000..27c2976
--- /dev/null
+++
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
[I don't know what's going on with either the mvista email server
or this mail list but none of these emails showed up until this
morning.]
On Tuesday 31 March 2009, Mark A. Greer wrote:
+enum {
+ DA830_PDEV_EDMA,
+
On Thu, Apr 02, 2009 at 10:01:43AM -0700, Mark A. Greer wrote:
On Tue, Mar 31, 2009 at 07:19:13PM -0700, David Brownell wrote:
I think it's simpler and clearer for the SoC code to just register all
the
devices and platform data all the time.
That is, all the devices that are
On Thu, Apr 02, 2009 at 07:54:06PM +0530, Rajashekhara, Sudhakar wrote:
From: Mark A. Greer mgr...@mvista.com
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
new file mode 100644
index 000..27c2976
---
On Tuesday 31 March 2009, Nori, Sekhar wrote:
2) It detects and complains about pinmux contention and there
is a lot of potential contention with the da830.
No less so than with OMAP, or lots of other SoCs. Contention
is rarely a problem given a clearly structured framework for
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Wednesday, April 01, 2009 11:37 AM
On Tuesday 31 March 2009, Nori, Sekhar wrote:
2) It detects and complains about pinmux contention and there
is a lot of potential contention with the da830.
No less so than with OMAP, or
On Tuesday 31 March 2009, Nori, Sekhar wrote:
I am not suggesting that drivers needs to deal with
pinmux variations across SoCs but I think the driver
does need to request the platform that all the pins
required for basic operation be available.
I'm suggesting that it's simpler if the
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Wednesday, April 01, 2009 12:23 PM
On Tuesday 31 March 2009, Nori, Sekhar wrote:
I am not suggesting that drivers needs to deal with
pinmux variations across SoCs but I think the driver
does need to request the platform that all the
On Wednesday 01 April 2009, Nori, Sekhar wrote:
I think we at least
agree that detecting contentions and splitting errors/warnings
would be useful.
I'm still at the convince me, I'm skeptical stage there.
It's literally been *years* since I've seen pin contention
problems.
The
On Wed, 2009-04-01 at 12:48 +0530, Nori, Sekhar wrote:
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Wednesday, April 01, 2009 12:23 PM
On Tuesday 31 March 2009, Nori, Sekhar wrote:
I am not suggesting that drivers needs to deal with
pinmux variations across SoCs but I think
From: Mark A. Greer
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/include/mach/da830.h b/arch/arm/mach-
davinci/include/mach/da830.h
new file mode 100644
index 000..8311006
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/da830.h
@@ -0,0 +1,133
Nori, Sekhar nsek...@ti.com writes:
From: Mark A. Greer
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/include/mach/da830.h b/arch/arm/mach-
davinci/include/mach/da830.h
new file mode 100644
index 000..8311006
--- /dev/null
+++
On Mon, Mar 30, 2009 at 10:21:05PM -0700, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
There are differences, however. Some of those differences
prevent support for davinci and da830 platforms to work
in the same kernel binary. Those differences are:
1) Different
On Tue, Mar 31, 2009 at 11:32:04AM +0530, Nori, Sekhar wrote:
From: Mark A. Greer
Sent: Sunday, March 29, 2009 7:37 AM
[...]
diff --git a/arch/arm/mach-davinci/include/mach/da830.h b/arch/arm/mach-
+#define DA830_TPCC_BASE 0x01C0
...
+#define DA830_IOPU5_BASE
On Tuesday 31 March 2009, Mark A. Greer wrote:
+enum {
+ DA830_PDEV_EDMA,
+ DA830_PDEV_I2C_0,
+ DA830_PDEV_I2C_1,
+ DA830_PDEV_SPI_0,
+ ...
+};
+
+struct da830_pdata {
+ int dev;/* Device to enable */
+ void*pdata; /* platform_data for
From: David Brownell
Sent: Wednesday, April 01, 2009 7:49 AM
On Tuesday 31 March 2009, Mark A. Greer wrote:
There is a patch from Steve Chen (which you haven't seen) that
automatically sets up the pinmux from clk_enable. The patch is
really nice for 2 reason:
We finally *removed*
On Sat, Mar 28, 2009 at 09:30:19PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
-/* dm355 only */
+/* dm355 da830 only */
#define PINMUX20x08
#define PINMUX30x0c
#define PINMUX4
On Sat, Mar 28, 2009 at 09:24:17PM -0700, David Brownell wrote:
On Saturday 28 March 2009, Mark A. Greer wrote:
+ * Device specific mux setup
+ *
+ * soc description mux mode mode mux dbg
+ * reg offset mask mode
Cosmetic nitpickery:
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The da830/omap l137 is a new SoC from TI that is similar
to the davinci line. Since its so similar to davinci,
put the support for the da830 in the same directory as
the davinci code.
There are differences,
Kevin Hilman khil...@deeprootsystems.com writes:
Mark A. Greer mgr...@mvista.com writes:
[...]
2) Different uart addresses. This is only an issue
for the assembly 'addruart' macro when CONFIG_DEBUG_LL
is enabled. Since the code in that macro is called
so early (e.g., by _error_p
From: Kevin Hilman
Sent: Tuesday, March 31, 2009 10:51 AM
Mark A. Greer mgr...@mvista.com writes:
From: Mark A. Greer mgr...@mvista.com
The da830 currently has an issue with writeback data
cache so CONFIG_CPU_DCACHE_WRITETHROUGH is forced on
when CONFIG_ARCH_DAVINCI_DA830 is enabled.
On Saturday 28 March 2009, Mark A. Greer wrote:
+ * Device specific mux setup
+ *
+ * soc description mux mode mode mux dbg
+ * reg offset mask mode
Cosmetic nitpickery: can we have those column headers (above)
line up with the column members
On Saturday 28 March 2009, Mark A. Greer wrote:
-/* dm355 only */
+/* dm355 da830 only */
#define PINMUX20x08
#define PINMUX30x0c
#define PINMUX40x10
/* dm355 only */
but, doesn't dm365 have a mess here
44 matches
Mail list logo
