mpc5200: digsy_mtc: update for next
Subsystems (2)
cover mpc5200: digsy_mtc: update for next
This patch series mainly updates digsy_mtc board to initialize graphic extention hardware and add splash screen support. The last patch is an update for "mtc appreg" command.
Anatolij Gustschin (5):
video: mb862xx: support Coral-PA controller
pci: option for configurable delay between pci reset and pci bus scan
mpc5200: digsy_mtc: enable pci_scan_delay option
mpc5200: digsy_mtc: add support for graphic extension board
mpc5200: digsy_mtc: add support for writing 'appreg' value
board/digsy_mtc/Makefile | 7 +++-- board/digsy_mtc/cmd_disp.c | 54 +++++++++++++++++++++++++++++++++++++++++++ board/digsy_mtc/cmd_mtc.c | 46 +++++++++++++++++++++++++++++++---- board/digsy_mtc/digsy_mtc.c | 49 +++++++++++++++++++++++++++++++++++++++ board/digsy_mtc/exbo.h | 17 +++++++++++++ drivers/pci/pci.c | 14 +++++++++++ drivers/video/mb862xx.c | 32 +++++++++++++++++++++---- include/configs/digsy_mtc.h | 28 ++++++++++++++++++++++ 8 files changed, 233 insertions(+), 14 deletions(-) create mode 100644 board/digsy_mtc/cmd_disp.c create mode 100644 board/digsy_mtc/exbo.h
Signature · 1 line
1.7.4.4
PATCH 1/5 video: mb862xx: support Coral-PA controller
Add detection of Coral-PA and configure Coral CCF an MMR parameters using CONFIG_SYS_MB862xx_CCF and CONFIG_SYS_MB862xx_MMR macros. Use CCF and MMR parameters for Coral-P Eval. Board if the appropriate macros weren't defined.
--- drivers/video/mb862xx.c | 32 +++++++++++++++++++++++++++----- 1 files changed, 27 insertions(+), 5 deletions(-)
drivers/video/mb862xx.c +27 -5
@@ -189,10 +189,19 @@ static void de_init (void) }#if defined(CONFIG_VIDEO_CORALP ) +/* use CCF and MMR parameters for Coral-P Eval. Board as default */ +#ifndef CONFIG_SYS_MB862xx_CCF +#define CONFIG_SYS_MB862xx_CCF 0x00090000 +#endif +#ifndef CONFIG_SYS_MB862xx_MMR +#define CONFIG_SYS_MB862xx_MMR 0x11d7fa13 +#endif +unsigned int pci_video_init (void ) {GraphicDevice *dev = &mb862xx;pci_dev_t devbusfn; +u16 device;if ((devbusfn =pci_find_devices (supported,0 )) <0 ) {puts ("PCI video controller not found!\n" );
@@ -212,10 +221,25 @@ unsigned int pci_video_init (void) dev->pciBase = dev->frameAdrs; -/* Setup clocks and memory mode for Coral-P Eval. Board */ -HOST_WR_REG (GC_CCF ,0x00090000 ); +puts ("Coral-" ); + +pci_read_config_word (devbusfn,PCI_DEVICE_ID , &device); +switch (device) { +case PCI_DEVICE_ID_CORAL_P : +puts ("P\n" ); +break ; +case PCI_DEVICE_ID_CORAL_PA : +puts ("PA\n" ); +break ; +default : +puts ("Unknown\n" ); +return 0 ; + } + +/* Setup clocks and memory mode for Coral-P(A) */ +HOST_WR_REG (GC_CCF , CONFIG_SYS_MB862xx_CCF);udelay (200 ); -HOST_WR_REG (GC_MMR ,0x11d7fa13 ); +HOST_WR_REG (GC_MMR , CONFIG_SYS_MB862xx_MMR);udelay (100 );return dev->frameAdrs; }
@@ -235,8 +259,6 @@ unsigned int card_init (void)if (!pci_video_init ())return 0 ; -puts ("CoralP\n" ); - tmp =0 ; videomode =0x310 ;/* get video mode via environment */
Signature · 1 line
1.7.4.4
PATCH 1/5 video: mb862xx: support Coral-PA controller
Quoted 9 lines · On Fri, 27 May 2011 16:08:20 +0200 Anatolij Gustschin <[email protected]> wrote:
Add detection of Coral-PA and configure Coral CCF an MMR parameters using
CONFIG_SYS_MB862xx_CCFandCONFIG_SYS_MB862xx_MMRmacros. Use CCF and MMR parameters for Coral-P Eval. Board if the appropriate macros weren't defined.Signed-off-by Anatolij Gustschin <[email protected]>--- drivers/video/mb862xx.c | 32 +++++++++++++++++++++++++++----- 1 files changed, 27 insertions(+), 5 deletions(-)
applied to u-boot-video/master.
Anatolij
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
In reply to Anatolij GustschinPCI cards might need some time after reset to respond.
On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at pci_board_init() time, so we can not use available "pcidelay" option for waiting before pci bus scan here. Add an option to delay bus scan by setting "pci_scan_delay" environment variable.
--- drivers/pci/pci.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
drivers/pci/pci.c +14 -0
@@ -699,6 +699,20 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)int pci_hose_scan (struct pci_controller *hose) { +#if defined(CONFIG_PCI_SCAN_DELAY ) +const char *s; +int i; + +/* wait "pci_scan_delay" ms, limit to max. 1 s */ + s =getenv ("pci_scan_delay" ); +if (s) { +int val =simple_strtoul (s,NULL ,10 ); +if (val >1000 ) + val =1000 ; +for (i =0 ; i < val; i++) +udelay (1000 ); + } +#endif /* Start scan at current_busno. * PCIe will start scan@first_busno+1. */
Signature · 1 line
1.7.4.4
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
Hi Anatolij,
Quoted 5 lines
PCI cards might need some time after reset to respond.
On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted atpci_board_init()time, so we can not use available "pcidelay" option for waiting before pci bus scan here. Add an option to delay bus scan by setting "pci_scan_delay" environment variable.
Hm, I'm not sure I understand the situation, so please correct me. We have a "pcidelay" variable, which is used to wait before pci_board_init() (I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you define pci_scan_delay which is used _after_ pci_init_board(), correct?
If this is correct, then why don't you keep your new delay also in the pci_init() function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsys pci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug.
Apart from that, having two variables "pcidelay" and "pci_scan_delay" we would need good documentation to explain their usage - the names do not help (me) much ;)
Cheers
Detlev
Signature · 5 lines
Practice random senselessness and act kind of beautiful. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
Hi Detlev,
On Fri, 27 May 2011 17:26:24 +0200
Detlev Zundel <[email protected]> wrote:
...
Quoted 11 lines
Quoted 5 lines
PCI cards might need some time after reset to respond.
On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted atpci_board_init()time, so we can not use available "pcidelay" option for waiting before pci bus scan here. Add an option to delay bus scan by setting "pci_scan_delay" environment variable.Hm, I'm not sure I understand the situation, so please correct me. We have a "pcidelay" variable, which is used to wait before
pci_board_init()(I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you definepci_scan_delaywhich is used _after_pci_init_board(), correct?
yes, this is correct.
Quoted 6 lines
If this is correct, then why don't you keep your new delay also in the
pci_init()function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsyspci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug.
The reason for not keeping new delay in pci_init() is:pci_init_board() starts scanning the bus (calls pci_hose_scan()), so when pci_init_board() returns, it is too late, the scanning is already completed.
digsy's pci_init_board() just calls pci_mpc5xxx_init(), when the latter returns, the scanning is completed, too. PCI reset is de-asserted in pci_mpc5xxx_init(), so I thought about putting the delay there, but similar situation is also on mpc8260 based boards, pci_mpc8250_init() de-asserts PCI reset and waits on some boards (on MPC8266ADS 1 sec). So the problem is not only digsy specific. The needed time after reset before config cycles could be up to 1 sec, depending on the card. The pci spec 2.2 allows this.
I think that it would be good to run arch specific pci init not from the pci_board_init(), but from pci_init(). Then we can add delay code in the board specific way. This would reduce the code duplication, too. Currently we have the same pci_init_board() for many 5200 boards, except for mvbc_p and mvsmr boards.
Quoted 3 lines
Apart from that, having two variables "pcidelay" and "
pci_scan_delay" we would need good documentation to explain their usage - the names do not help (me) much ;)
Sure. If there is an agreement to solve the problem as proposed in the patch, I'll add the documentation in the next patch version. Maybe someone have a better idea, lets wait a bit for other comments. Actually I don't like the name of the variable, it is somehow misleading. Any better name?
Thanks,
Anatolij
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
Hi Anatolij,
Quoted 31 lines
Hi Detlev,
On Fri, 27 May 2011 17:26:24 +0200
Detlev Zundel <[email protected]> wrote:
...Quoted 11 lines
Quoted 5 lines
PCI cards might need some time after reset to respond.
On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted atpci_board_init()time, so we can not use available "pcidelay" option for waiting before pci bus scan here. Add an option to delay bus scan by setting "pci_scan_delay" environment variable.Hm, I'm not sure I understand the situation, so please correct me. We have a "pcidelay" variable, which is used to wait before
pci_board_init()(I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you definepci_scan_delaywhich is used _after_pci_init_board(), correct?yes, this is correct.
Quoted 6 lines
If this is correct, then why don't you keep your new delay also in the
pci_init()function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsyspci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug.The reason for not keeping new delay in
pci_init()is:pci_init_board()starts scanning the bus (callspci_hose_scan()), so whenpci_init_board()returns, it is too late, the scanning is already completed.
Quoted 8 lines
digsy's
pci_init_board()just callspci_mpc5xxx_init(), when the latter returns, the scanning is completed, too. PCI reset is de-asserted inpci_mpc5xxx_init(), so I thought about putting the delay there, but similar situation is also on mpc8260 based boards,pci_mpc8250_init()de-asserts PCI reset and waits on some boards (on MPC8266ADS 1 sec). So the problem is not only digsy specific. The needed time after reset before config cycles could be up to 1 sec, depending on the card. The pci spec 2.2 allows this.
Ah, thanks for shedding some light on this. Now I see how you arrived at the solution you propose.
Quoted 5 lines
I think that it would be good to run arch specific pci init not from the
pci_board_init(), but frompci_init(). Then we can add delay code in the board specific way. This would reduce the code duplication, too. Currently we have the samepci_init_board()for many 5200 boards, except formvbc_pand mvsmr boards.
Yes, I have also noticed the massive code duplicatin here. But as I obviously didn't even understand the problem I didn't ponder changing it ;)
Quoted 9 lines
Quoted 3 lines
Apart from that, having two variables "pcidelay" and "
pci_scan_delay" we would need good documentation to explain their usage - the names do not help (me) much ;)Sure. If there is an agreement to solve the problem as proposed in the patch, I'll add the documentation in the next patch version. Maybe someone have a better idea, lets wait a bit for other comments. Actually I don't like the name of the variable, it is somehow misleading. Any better name?
Sorry, no idea. If we are stuck stuck with "pcidelay" (which I think we are), then it is hard to come up with a differentiating name. So good documentation will have to make up for the lack of good names ;)
Cheers
Detlev
Signature · 5 lines
Old mathematicians never die; they just lose some of their functions. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
Hi Anatolij and Detlev,
Quoted 15 lines · On Monday 30 May 2011 09:45:08 Detlev Zundel wrote:
Quoted 15 lines
Quoted 5 lines
Hm, I'm not sure I understand the situation, so please correct me. We have a "pcidelay" variable, which is used to wait before
pci_board_init()(I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you definepci_scan_delaywhich is used _after_pci_init_board(), correct?yes, this is correct.
Quoted 6 lines
If this is correct, then why don't you keep your new delay also in the
pci_init()function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsyspci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug.
Quoted 4 lines
Quoted 4 lines
The reason for not keeping new delay in
pci_init()is:pci_init_board()starts scanning the bus (callspci_hose_scan()), so whenpci_init_board()returns, it is too late, the scanning is already completed.
Right. With this PCI reset "design", the current "pcidelay" option won't work for these platforms. Too bad.
But thinking more about it, couldn't your new code location supersede the old one before pci_init_board()? If this really is the case (we would need to check with users of this "pcidelay" env variable, Mattias?), then we could remove the old code in pci_init() and only use your new version. We would need to use the old env variable name "pcidelay" though, since there are boards in the field already using this version.
Anatolij, what do you think?
Matthias, could you do some tests on some esd boards with the new version when available, to make sure that we don't break backwards compatibility?
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
PATCH 2/5 pci: option for configurable delay between pci reset and pci bus scan
Hi Stefan,
Quoted 26 lines · On Mon, 30 May 2011 16:10:34 +0200 Stefan Roese <[email protected]> wrote:
Hi Anatolij and Detlev,
Quoted 15 lines · On Monday 30 May 2011 09:45:08 Detlev Zundel wrote:
Quoted 15 lines
Quoted 5 lines
Hm, I'm not sure I understand the situation, so please correct me. We have a "pcidelay" variable, which is used to wait before
pci_board_init()(I'm not counting the semantically different usage in the esd boards). This does not fit your need, so you definepci_scan_delaywhich is used _after_pci_init_board(), correct?yes, this is correct.
Quoted 6 lines
If this is correct, then why don't you keep your new delay also in the
pci_init()function so that the delays are easily visible on code inspection? But wait, if this is only needed for this very board, then why don't we put the delay into digsyspci_init_board? Actually I think this is the best way, as on this board we always need the delay as PCI is not hotplug.Quoted 4 lines
Quoted 4 lines
The reason for not keeping new delay in
pci_init()is:pci_init_board()starts scanning the bus (callspci_hose_scan()), so whenpci_init_board()returns, it is too late, the scanning is already completed.Right. With this PCI reset "design", the current "pcidelay" option won't work for these platforms. Too bad.
Quoted 8 lines
But thinking more about it, couldn't your new code location supersede the old one before
pci_init_board()? If this really is the case (we would need to check with users of this "pcidelay" env variable, Mattias?), then we could remove the old code inpci_init()and only use your new version. We would need to use the old env variable name "pcidelay" though, since there are boards in the field already using this version.Anatolij, what do you think?
This should work, I think. I'll send a patch moving pcidelay code to new location.
Quoted 2 lines
Matthias, could you do some tests on some esd boards with the new version when available, to make sure that we don't break backwards compatibility?
Would be great if Matthias could test the patch.
Thanks,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
PATCH 1/1 pci: move pcidelay code to new location just before PCI bus scan
In reply to Stefan RoesePCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at pci_init_board() time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before calling pci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.
--- drivers/pci/pci.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-)
drivers/pci/pci.c +13 -13
@@ -695,6 +695,19 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)int pci_hose_scan (struct pci_controller *hose) { +#if defined(CONFIG_PCI_BOOTDELAY ) +char *s; +int i; + +/* wait "pcidelay" ms (if defined)... */ + s =getenv ("pcidelay" ); +if (s) { +int val =simple_strtoul (s,NULL ,10 ); +for (i =0 ; i < val; i++) +udelay (1000 ); + } +#endif /* CONFIG_PCI_BOOTDELAY */ +/* Start scan at current_busno. * PCIe will start scan@first_busno+1. */
@@ -709,19 +722,6 @@ int pci_hose_scan(struct pci_controller *hose)void pci_init (void ) { -#if defined(CONFIG_PCI_BOOTDELAY ) -char *s; -int i; - -/* wait "pcidelay" ms (if defined)... */ - s =getenv ("pcidelay" ); -if (s) { -int val =simple_strtoul (s,NULL ,10 ); -for (i=0 ; i<val; i++) -udelay (1000 ); - } -#endif /* CONFIG_PCI_BOOTDELAY */ - hose_head =NULL ;/* now call board specific pci_init()... */
Signature · 1 line
1.7.1
PATCH 1/1 pci: move pcidelay code to new location just before PCI bus scan
Hi Anatolij,
in general this is a good idea. It also fixes an issue on dual role boards that can act as pci host and target like the PMC440 and PMC405DE. When these boards are configured as target, the pcidelay variable must be ignored or _target_ initialization must be done before the delay.
That's why I put my own pcidelay implementation in our board code.
But I see a problem on boards with more than one PCI bus/PCIe rootcomplex like some 440 parts. In this case the delay is executed multiple times.
So it might be a good idea to restrict pci_hose_scan to wait for only during its initial call and to ignore pcidelay for any further call.
BTW, 4xx_pcie.c also implements an additional delay controlled by the pciscandelay variable before calling pci_hose_scan() :-) I think this is obsolete.
Matthias
Quoted 57 lines · Anatolij Gustschin
PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at
pci_init_board()time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before callingpci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.Signed-off-by Anatolij Gustschin <[email protected]>--- drivers/pci/pci.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-)drivers/pci/pci.c +13
-13@@ -695,6 +695,19 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)int pci_hose_scan (struct pci_controller *hose) { +#if defined(CONFIG_PCI_BOOTDELAY ) +char *s; +int i; + +/* wait "pcidelay" ms (if defined)... */ + s =getenv ("pcidelay" ); +if (s) { +int val =simple_strtoul (s,NULL ,10 ); +for (i =0 ; i < val; i++) +udelay (1000 ); + } +#endif /* CONFIG_PCI_BOOTDELAY */ +/* Start scan at current_busno. * PCIe will start scan at first_busno+1. */ @@ -709,19 +722,6 @@ int pci_hose_scan(struct pci_controller *hose)void pci_init (void ) { -#if defined(CONFIG_PCI_BOOTDELAY ) -char *s; -int i; - -/* wait "pcidelay" ms (if defined)... */ - s =getenv ("pcidelay" ); -if (s) { -int val =simple_strtoul (s,NULL ,10 ); -for (i=0 ; i<val; i++) -udelay (1000 ); - } -#endif /* CONFIG_PCI_BOOTDELAY */ - hose_head =NULL ;/* now call board specific pci_init()... */
Signature · 16 lines
------------------------------------------------------------------------ Dipl.-Ing. Matthias Fuchs Head of System Design esd electronic system design gmbh Vahrenwalder Str. 207 - 30165 Hannover - GERMANY Phone: +49-511-37298-0 - Fax: +49-511-37298-68 Please visit our homepage http://www.esd.eu Quality Products - Made in Germany Besuchen Sie uns auf der Hannover Messe 2011 in Halle 9, Stand D13 vom 04.-08. April 2011 in Hannover! ------------------------------------------------------------------------- Gesch?ftsf?hrer: Klaus Detering Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832 -------------------------------------------------------------------------
PATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
In reply to Anatolij GustschinPCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at pci_init_board() time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before calling pci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.
Since pci_hose_scan() could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias).
---
Changes since first version:
- extend to wait only during initial pci_hose_scan() call as pointed out by Matthias
drivers/pci/pci.c | 30 +++++++++++++++++------------- 1 files changed, 17 insertions(+), 13 deletions(-)
drivers/pci/pci.c +17 -13
@@ -695,6 +695,23 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)int pci_hose_scan (struct pci_controller *hose) { +#if defined(CONFIG_PCI_BOOTDELAY ) +static int pcidelay_done; +char *s; +int i; + +if (!pcidelay_done) { +/* wait "pcidelay" ms (if defined)... */ + s =getenv ("pcidelay" ); +if (s) { +int val =simple_strtoul (s,NULL ,10 ); +for (i =0 ; i < val; i++) +udelay (1000 ); + } + pcidelay_done =1 ; + } +#endif /* CONFIG_PCI_BOOTDELAY */ +/* Start scan at current_busno. * PCIe will start scan@first_busno+1. */
@@ -709,19 +726,6 @@ int pci_hose_scan(struct pci_controller *hose)void pci_init (void ) { -#if defined(CONFIG_PCI_BOOTDELAY ) -char *s; -int i; - -/* wait "pcidelay" ms (if defined)... */ - s =getenv ("pcidelay" ); -if (s) { -int val =simple_strtoul (s,NULL ,10 ); -for (i=0 ; i<val; i++) -udelay (1000 ); - } -#endif /* CONFIG_PCI_BOOTDELAY */ - hose_head =NULL ;/* now call board specific pci_init()... */
Signature · 1 line
1.7.1
PATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
Quoted 8 lines · On Wednesday 12 October 2011 10:44:30 Anatolij Gustschin wrote:
PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at
pci_init_board()time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before callingpci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.
Quoted 6 lines
Since
pci_hose_scan()could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias).Signed-off-by Anatolij Gustschin <[email protected]>Cc Matthias Fuchs <[email protected]>
Looks good, so:
Thanks,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
PATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
In reply to Anatolij GustschinQuoted 12 lines · Anatolij Gustschin
PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at
pci_init_board()time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before callingpci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.Since
pci_hose_scan()could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias).
Quoted 6 lines
Signed-off-by Anatolij Gustschin <[email protected]>Cc Matthias Fuchs <[email protected]>---
Changes since first version:
- extend to wait only during initialpci_hose_scan()call as pointed out by Matthias
Tested on PMC440. Works fine.
Matthias
PATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
Quoted 17 lines · On Thursday 13 October 2011 14:50:02 Matthias Fuchs wrote:
Quoted 16 lines · Anatolij Gustschin
PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at
pci_init_board()time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before callingpci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.Since
pci_hose_scan()could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias).Signed-off-by Anatolij Gustschin <[email protected]>Cc Matthias Fuchs <[email protected]>---
Quoted 8 lines
Quoted 4 lines
Changes since first version:
- extend to wait only during initialpci_hose_scan()callas pointed out by Matthias
Tested on PMC440. Works fine.
Acked-by Matthias Fuchs <[email protected]>
Thanks. In this case a:
would be even better. :)
Thanks,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
PATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
Quoted 11 lines · Stefan Roese
Quoted 4 lines
Tested on PMC440. Works fine.
Acked-by Matthias Fuchs <[email protected]>Thanks. In this case a:
Tested-by ...would be even better. :)
Even both if you like :-)
Matthias
Wolfgang Denk
AppliedPATCH v2 1/1 pci: move pcidelay code to new location just before PCI bus scan
In reply to Anatolij GustschinDear Anatolij Gustschin,
Quoted 14 lines · In message <[email protected]> you wrote:
PCI cards might need some time after reset to respond. On some boards (mpc5200 or mpc8260 based) the PCI bus reset is deasserted at
pci_init_board()time, so we currently can not use available "pcidelay" option for waiting before PCI bus scan since this waiting takes place before callingpci_init_board(). By moving the pcidelay code to the new location using of the "pcidelay" option is possible on mpc5200 or mpc8260 based boards, too.Since
pci_hose_scan()could be called multiple times, restrict the function to wait only during its first call and to ignore pcidelay for any further call (as pointed out by Matthias).Signed-off-by Anatolij Gustschin <[email protected]>Cc Matthias Fuchs <[email protected]>
Quoted 7 lines
---
Changes since first version:
- extend to wait only during initialpci_hose_scan()call as pointed out by Matthiasdrivers/pci/pci.c | 30 +++++++++++++++++------------- 1 files changed, 17 insertions(+), 13 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A Freudian slip is when you say one thing but mean your mother.
PATCH 3/5 mpc5200: digsy_mtc: enable pci_scan_delay option
In reply to Anatolij GustschinA delay of approximately 250 ms after PCI bus reset in pci_mpc5xxx_init() is needed to recognize the Coral-PA controller on graphic extention board. With this option enabled we can set the environment variable "pci_scan_delay" to the needed value.
--- include/configs/digsy_mtc.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
include/configs/digsy_mtc.h +1 -0
@@ -70,6 +70,7 @@#define CONFIG_PCI 1#define CONFIG_PCI_PNP 1#define CONFIG_PCI_SCAN_SHOW 1 +#define CONFIG_PCI_SCAN_DELAY #define CONFIG_PCI_MEM_BUS 0x40000000#define CONFIG_PCI_MEM_PHYS CONFIG_PCI_MEM_BUS
Signature · 1 line
1.7.4.4
PATCH 3/5 mpc5200: digsy_mtc: enable pci_scan_delay option
Hi Anatolij,
Quoted 7 lines
A delay of approximately 250 ms after PCI bus reset in
pci_mpc5xxx_init()is needed to recognize the Coral-PA controller on graphic extention board. With this option enabled we can set the environment variable "pci_scan_delay" to the needed value.Signed-off-by Anatolij Gustschin <[email protected]>
Although I propose not to introduce a new environment variable for this option, _if_ you do want to use it, you should also set its value in the boards default configuration.
Cheers
Detlev
Signature · 8 lines
Ich glaube, da? die Weltanschauung, die aus der modernen Physik hervorgeht, mit unserer gegenw?rtigen Gesellschaft unvereinbar ist, weil sie den har- monischen Zusammenh?ngen, die wir in der Natur beaobachten, nicht Rechnung tr?gt. -- Fritjof Capra -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
PATCH 1/1 mpc5200: digsy_mtc: fix detection of Coral-PA
In reply to Anatolij GustschinA delay of approximately 250 ms after PCI bus reset in pci_mpc5xxx_init() is needed to recognize the Coral-PA controller on the graphic extention board.
---
To make it actually work another patch
"pci: move pcidelay code to new location just before PCI bus scan" is also required. It has been submitted earlier [1] and there is already some positive feedback.
[1] http://patchwork.ozlabs.org/patch/119171/
include/configs/digsy_mtc.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
include/configs/digsy_mtc.h +1 -0
@@ -70,6 +70,7 @@#define CONFIG_PCI 1#define CONFIG_PCI_PNP 1#define CONFIG_PCI_SCAN_SHOW 1 +#define CONFIG_PCI_BOOTDELAY 250#define CONFIG_PCI_MEM_BUS 0x40000000#define CONFIG_PCI_MEM_PHYS CONFIG_PCI_MEM_BUS
Signature · 1 line
1.7.1
PATCH 1/1 mpc5200: digsy_mtc: fix detection of Coral-PA
Hi Anatolij,
Quoted 4 lines
A delay of approximately 250 ms after PCI bus reset in
pci_mpc5xxx_init()is needed to recognize the Coral-PA controller on the graphic extention board.
Quoted 8 lines
Signed-off-by Anatolij Gustschin <[email protected]>---
To make it actually work another patch
"pci: move pcidelay code to new location just before PCI bus scan" is also required. It has been submitted earlier [1] and there is already some positive feedback.
Signature · 9 lines
And like the software patent issue, I also don't necessarily like DRM myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse to play politics with Linux, and I think you can use Linux for whatever you want to - which very much includes things I don't necessarily personally approve of. -- Linus Torvalds in lmkl -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
Wolfgang Denk
AppliedPATCH 1/1 mpc5200: digsy_mtc: fix detection of Coral-PA
In reply to Anatolij GustschinDear Anatolij Gustschin,
Quoted 11 lines · In message <[email protected]> you wrote:
A delay of approximately 250 ms after PCI bus reset in
pci_mpc5xxx_init()is needed to recognize the Coral-PA controller on the graphic extention board.Signed-off-by Anatolij Gustschin <[email protected]>---
To make it actually work another patch
"pci: move pcidelay code to new location just before PCI bus scan" is also required. It has been submitted earlier [1] and there is already some positive feedback.
Quoted 4 lines
[1] http://patchwork.ozlabs.org/patch/119171/
include/configs/digsy_mtc.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Plan to throw one away. You will anyway."
- Fred Brooks, "The Mythical Man Month"PATCH 4/5 mpc5200: digsy_mtc: add support for graphic extension board
In reply to Anatolij GustschinAdd detection and initialisation for graphic extension board and support splash screen when booting. Enable "bmp" command in the board configuration and provide "disp" command to be able to switch the display on/off.
--- board/digsy_mtc/Makefile | 7 +++-- board/digsy_mtc/cmd_disp.c | 54 +++++++++++++++++++++++++++++++++++++++++++ board/digsy_mtc/digsy_mtc.c | 49 +++++++++++++++++++++++++++++++++++++++ board/digsy_mtc/exbo.h | 17 +++++++++++++ include/configs/digsy_mtc.h | 27 +++++++++++++++++++++ 5 files changed, 151 insertions(+), 3 deletions(-) create mode 100644 board/digsy_mtc/cmd_disp.c create mode 100644 board/digsy_mtc/exbo.h
board/digsy_mtc/Makefile +4 -3
@@ -7,10 +7,11 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(BOARD).o -COBJS := $(BOARD).o cmd_mtc.o +COBJS-y := $(BOARD).o cmd_mtc.o +COBJS-$(CONFIG_VIDEO) += cmd_disp.o -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(COBJS)) +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) SOBJS := $(addprefix $(obj),$(SOBJS)) $(LIB): $(obj).depend $(OBJS)
board/digsy_mtc/cmd_disp.c new file +54 -0
54 lines not on this page · raw message
board/digsy_mtc/digsy_mtc.c +49 -0
67 lines not on this page · raw message
board/digsy_mtc/exbo.h new file +17 -0
@@ -0,0 +1,17 @@ +#ifndef _EXBO_H +#define _EXBO_H + +#define GPIO_USB1_0 0x00010000/* Power-On pin */ +#define GPIO_USB1_9 0x00000008/* PX_~EN pin */ + +#define GPIO_EE_DO 0x10000000/* PSC6_0 (DO) pin */ +#define GPIO_EE_CTS 0x20000000/* PSC6_1 (CTS) pin */ +#define GPIO_EE_DI 0x10000000/* PSC6_2 (DI) pin */ +#define GPIO_EE_CLK 0x20000000/* PSC6_3 (CLK) pin */ + +#define GPT_GPIO_ON 0x00000034/* GPT as simple GPIO, high */ + +/* ExBo I2C Addresses */ +#define EXBO_EE_I2C_ADDRESS 0x56 + +#endif
include/configs/digsy_mtc.h +27 -0
@@ -87,10 +87,37 @@#define CONFIG_BZIP2 /* +* Video +*/ +#define CONFIG_VIDEO + +#ifdef CONFIG_VIDEO +#define CONFIG_VIDEO_MB862xx +#define CONFIG_VIDEO_MB862xx_ACCEL +#define CONFIG_VIDEO_CORALP +#define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_LOGO +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_SYS_CONSOLE_IS_IN_ENV +#define CONFIG_SPLASH_SCREEN +#define CONFIG_VIDEO_BMP_GZIP +#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (2 << 20)/* decompressed img */ + +/* Coral-PA clock frequency, geo and other both 133MHz */ +#define CONFIG_SYS_MB862xx_CCF 0x00050000 +/* Video SDRAM parameters */ +#define CONFIG_SYS_MB862xx_MMR 0x11d7fa72 +#endif + +/* * Command line configuration. */ #include <config_cmd_default.h> +#ifdef CONFIG_VIDEO +#define CONFIG_CMD_BMP +#endif #define CONFIG_CMD_DFL #define CONFIG_CMD_CACHE #define CONFIG_CMD_DATE
Signature · 1 line
1.7.4.4
PATCH 4/5 mpc5200: digsy_mtc: add support for graphic extension board
Hi Anatolij,
Quoted 7 lines
Add detection and initialisation for graphic extension board and support splash screen when booting. Enable "bmp" command in the board configuration and provide "disp" command to be able to switch the display on/off.
Signed-off-by Anatolij Gustschin <[email protected]>---
[...]
Quoted 1 line
board/digsy_mtc/exbo.h | 17 +++++++++++++
Please fold this into the digsy_mtc.h file. We should not add more files without proper licensing headers and 17 lines surely do not justify going to this length.
Apart from that
Cheers
Detlev
Signature · 8 lines
Each language has its purpose, however humble. Each language expresses
the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
-- The Tao of Programming
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH 4/5 mpc5200: digsy_mtc: add support for graphic extension board
Hi Detlev,
On Fri, 27 May 2011 17:33:33 +0200
Detlev Zundel <[email protected]> wrote:
...
Quoted 5 lines
Quoted 1 line
board/digsy_mtc/exbo.h | 17 +++++++++++++Please fold this into the
digsy_mtc.hfile. We should not add more files without proper licensing headers and 17 lines surely do not justify going to this length.
Okay. I just noticed that this patch is old. In another branch I've a newer version using register accessors. There is also a small bug in this patch. I'll resend and add the exbo.h header to existing header.
Thanks,
Anatolij
PATCH v2 4/5 mpc5200: digsy_mtc: add support for graphic extension board
In reply to Anatolij GustschinAdd detection and initialisation for graphic extension board and support splash screen when booting. Enable "bmp" command in the board configuration and provide "disp" command to be able to switch the display on/off.
---
v2:
- get rid of exbo.h header and put the needed defines into the .c file
- use accessors when reading/writing gpio registers
- correct GPIO_EE_DO, GPIO_EE_CTS and GPIO_USB1_9 macros for settings in 8-bit wkup gpio registers
board/digsy_mtc/Makefile | 7 ++-- board/digsy_mtc/cmd_disp.c | 57 +++++++++++++++++++++++++++++++++++++ board/digsy_mtc/digsy_mtc.c | 66 +++++++++++++++++++++++++++++++++++++++++++ include/configs/digsy_mtc.h | 27 +++++++++++++++++ 4 files changed, 154 insertions(+), 3 deletions(-) create mode 100644 board/digsy_mtc/cmd_disp.c
board/digsy_mtc/Makefile +4 -3
@@ -7,10 +7,11 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(BOARD).o -COBJS := $(BOARD).o cmd_mtc.o +COBJS-y := $(BOARD).o cmd_mtc.o +COBJS-$(CONFIG_VIDEO) += cmd_disp.o -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(COBJS)) +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) SOBJS := $(addprefix $(obj),$(SOBJS)) $(LIB): $(obj).depend $(OBJS)
board/digsy_mtc/cmd_disp.c new file +57 -0
57 lines not on this page · raw message
board/digsy_mtc/digsy_mtc.c +66 -0
84 lines not on this page · raw message
include/configs/digsy_mtc.h +27 -0
@@ -87,10 +87,37 @@#define CONFIG_BZIP2 /* +* Video +*/ +#define CONFIG_VIDEO + +#ifdef CONFIG_VIDEO +#define CONFIG_VIDEO_MB862xx +#define CONFIG_VIDEO_MB862xx_ACCEL +#define CONFIG_VIDEO_CORALP +#define CONFIG_CFB_CONSOLE +#define CONFIG_VIDEO_LOGO +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_SYS_CONSOLE_IS_IN_ENV +#define CONFIG_SPLASH_SCREEN +#define CONFIG_VIDEO_BMP_GZIP +#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (2 << 20)/* decompressed img */ + +/* Coral-PA clock frequency, geo and other both 133MHz */ +#define CONFIG_SYS_MB862xx_CCF 0x00050000 +/* Video SDRAM parameters */ +#define CONFIG_SYS_MB862xx_MMR 0x11d7fa72 +#endif + +/* * Command line configuration. */ #include <config_cmd_default.h> +#ifdef CONFIG_VIDEO +#define CONFIG_CMD_BMP +#endif #define CONFIG_CMD_DFL #define CONFIG_CMD_CACHE #define CONFIG_CMD_DATE
Signature · 1 line
1.7.1
PATCH v2 4/5 mpc5200: digsy_mtc: add support for graphic extension board
Hi Anatolij,
Quoted 6 lines
Add detection and initialisation for graphic extension board and support splash screen when booting. Enable "bmp" command in the board configuration and provide "disp" command to be able to switch the display on/off.
Signed-off-by Anatolij Gustschin <[email protected]>
Cheers
Detlev
Signature · 6 lines
Quantum physicists can either know how fast they do it, or where they do it, but not both. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
Wolfgang Denk
AppliedPATCH v2 4/5 mpc5200: digsy_mtc: add support for graphic extension board
In reply to Anatolij GustschinDear Anatolij Gustschin,
Quoted 13 lines · In message <[email protected]> you wrote:
Add detection and initialisation for graphic extension board and support splash screen when booting. Enable "bmp" command in the board configuration and provide "disp" command to be able to switch the display on/off.
Signed-off-by Anatolij Gustschin <[email protected]>---
v2:
- get rid ofexbo.hheader and put the needed defines into the .c file
- use accessors when reading/writing gpio registers
- correctGPIO_EE_DO,GPIO_EE_CTSandGPIO_USB1_9macros for settings in 8-bit wkup gpio registers
Quoted 6 lines
board/digsy_mtc/Makefile | 7 ++-- board/digsy_mtc/cmd_disp.c | 57 +++++++++++++++++++++++++++++++++++++ board/digsy_mtc/digsy_mtc.c | 66 +++++++++++++++++++++++++++++++++++++++++++ include/configs/digsy_mtc.h | 27 +++++++++++++++++ 4 files changed, 154 insertions(+), 3 deletions(-) create mode 100644 board/digsy_mtc/cmd_disp.c
Applied, thanks.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Harrisberger's Fourth Law of the Lab: Experience is directly proportional to the amount of equipment ruined.
PATCH 5/5 mpc5200: digsy_mtc: add support for writing 'appreg' value
In reply to Anatolij GustschinUp to now only reading 'appreg' value was implemented in the digsyMTC special 'mtc appreg' command. Extend the command to support writing appreg value, too.
--- board/digsy_mtc/cmd_mtc.c | 46 +++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 6 deletions(-)
board/digsy_mtc/cmd_mtc.c +40 -6
@@ -31,6 +31,8 @@DECLARE_GLOBAL_DATA_PTR ; +static uchar user_out; +static const char *led_names[] = {"diag" ,"can1" ,
@@ -112,6 +114,8 @@ static int do_mtc_led(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])else pcmd.cmd_val2 =0 ; + pcmd.user_out = user_out; +mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -128,6 +132,7 @@ static int do_mtc_key(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])memset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_GET_VIM ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -160,6 +165,7 @@ static int do_mtc_digout(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv pcmd.cmd =CMD_GET_VIM ; pcmd.user_out = channel_mask; + user_out = channel_mask;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -187,6 +193,7 @@ static int do_mtc_digin(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[memset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_GET_VIM ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -205,6 +212,7 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argvrx_msp_cmd prx;int err;char buf[5 ]; +uchar appreg;/* read appreg */ memset (&pcmd,0 ,sizeof (pcmd));
@@ -214,13 +222,34 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv pcmd.cmd_val0 =5 ;/* max. Count */ pcmd.cmd_val1 =5 ;/* max. Time */ pcmd.cmd_val2 =0 ;/* =0 means read appreg */ + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx); +/* on success decide between read or write */ if (!err) { -sprintf (buf,"%d" , prx.ack2); -setenv ("appreg" , buf); +if (argc ==2 ) { + appreg =simple_strtol (argv[1 ],NULL ,10 ); +if (appreg ==0 ) { +printf ("mtc appreg: invalid parameter - " +"must be betwenn 1 and 255\n" ); +return -1 ; + } +memset (&pcmd,0 ,sizeof (pcmd)); + pcmd.cmd =CMD_WD_PARA ; + pcmd.cmd_val0 = prx.ack3;/* max. Count */ + pcmd.cmd_val1 = prx.ack0;/* max. Time */ + pcmd.cmd_val2 = appreg;/* !=0 means write appreg */ + pcmd.user_out = user_out; +memset (&prx,0 ,sizeof (prx)); + +mtc_calculate_checksum (&pcmd); + err =msp430_xfer (&pcmd, &prx); + }else { +sprintf (buf,"%d" , prx.ack2); +setenv ("appreg" , buf); + } }return err;
@@ -236,6 +265,7 @@ static int do_mtc_version(cmd_tbl_t *cmdtp, int flag, int argc, char * const argmemset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_FW_VERSION ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -259,6 +289,7 @@ static int do_mtc_state(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[ pcmd.cmd =CMD_WD_WDSTATE ; pcmd.cmd_val2 =1 ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -288,8 +319,10 @@ cmd_tbl_t cmd_mtc_sub[] = { "returns state of user key", ""),U_BOOT_CMD_MKENT (version,0 ,1 , do_mtc_version,"returns firmware version of supervisor uC" ,"" ), -U_BOOT_CMD_MKENT (appreg,0 ,1 , do_mtc_appreg, -"reads appreg value and stores in environment variable 'appreg'" ,"" ), +U_BOOT_CMD_MKENT (appreg,1 ,1 , do_mtc_appreg, +"reads or writes appreg value and stores in environment " +"variable 'appreg'" , +"[value] - value (1 - 255) to write to appreg" ),U_BOOT_CMD_MKENT (digin,1 ,1 , do_mtc_digin,"returns state of digital input" , "<channel_num> - get state of digital input (1 or 2)\n"),
@@ -342,8 +375,9 @@ U_BOOT_CMD(mtc, 5, 1, cmd_mtc," [blink]: blink interval in 100ms steps (1 - 10; 0 = static)\n" "key - returns state of user key\n" "version - returns firmware version of supervisor uC\n" -"appreg - reads appreg value and stores in environment variable" -" 'appreg'\n" +"appreg [value] - reads (in environment variable 'appreg') or writes" +" appreg value\n" +" [value]: value (1 - 255) to write to appreg\n" "digin [channel] - returns state of digital input (1 or 2)\n" "digout <on|off> <on|off> - sets state of two digital outputs\n" "state - displays state\n"
Signature · 1 line
1.7.4.4
PATCH 5/5 mpc5200: digsy_mtc: add support for writing 'appreg' value
Hi Anatolij,
Quoted 14 lines
Up to now only reading 'appreg' value was implemented in the digsyMTC special 'mtc appreg' command. Extend the command to support writing appreg value, too.
Signed-off-by Werner Pfister <[email protected]>Signed-off-by Anatolij Gustschin <[email protected]>--- board/digsy_mtc/cmd_mtc.c | 46 +++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 6 deletions(-)board/digsy_mtc/cmd_mtc.c +0
-0
[...]
Quoted 8 lines
board/digsy_mtc/cmd_mtc.c +1
-0@@ -214,13 +222,34 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv pcmd.cmd_val0 =5 ;/* max. Count */ pcmd.cmd_val1 =5 ;/* max. Time */ pcmd.cmd_val2 =0 ;/* =0 means read appreg */ + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
board/digsy_mtc/cmd_mtc.c static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv · line 236
Quoted 10 lines
board/digsy_mtc/cmd_mtc.c +6
-2+/* on success decide between read or write */ if (!err) { -sprintf (buf,"%d" , prx.ack2); -setenv ("appreg" , buf); +if (argc ==2 ) { + appreg =simple_strtol (argv[1 ],NULL ,10 ); +if (appreg ==0 ) { +printf ("mtc appreg: invalid parameter - " +"must be betwenn 1 and 255\n" );
Typo, should be "between"
Otherwise
Thanks
Detlev
Signature · 6 lines
An elephant is a mouse with an operating system.
-- Donald Knuth
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.dePATCH 5/5 mpc5200: digsy_mtc: add support for writing 'appreg' value
Hi Detlev,
On Fri, 27 May 2011 17:36:01 +0200
Detlev Zundel <[email protected]> wrote:
...
Quoted 3 lines
board/digsy_mtc/cmd_mtc.c static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv · line 236
Quoted 1 line
board/digsy_mtc/cmd_mtc.c +1
-0+ "must be betwenn 1 and 255\n");Typo, should be "between"
I'll fix it. Thanks for catching!
Thanks,
Anatolij
PATCH v2 5/5 mpc5200: digsy_mtc: add support for writing 'appreg' value
In reply to Anatolij GustschinUp to now only reading 'appreg' value was implemented in the digsyMTC special 'mtc appreg' command. Extend the command to support writing appreg value, too.
---
v2:
- fix typo in error message
board/digsy_mtc/cmd_mtc.c | 46 +++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 6 deletions(-)
board/digsy_mtc/cmd_mtc.c +40 -6
@@ -31,6 +31,8 @@DECLARE_GLOBAL_DATA_PTR ; +static uchar user_out; +static const char *led_names[] = {"diag" ,"can1" ,
@@ -112,6 +114,8 @@ static int do_mtc_led(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])else pcmd.cmd_val2 =0 ; + pcmd.user_out = user_out; +mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -128,6 +132,7 @@ static int do_mtc_key(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])memset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_GET_VIM ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -160,6 +165,7 @@ static int do_mtc_digout(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv pcmd.cmd =CMD_GET_VIM ; pcmd.user_out = channel_mask; + user_out = channel_mask;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -187,6 +193,7 @@ static int do_mtc_digin(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[memset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_GET_VIM ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -205,6 +212,7 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argvrx_msp_cmd prx;int err;char buf[5 ]; +uchar appreg;/* read appreg */ memset (&pcmd,0 ,sizeof (pcmd));
@@ -214,13 +222,34 @@ static int do_mtc_appreg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv pcmd.cmd_val0 =5 ;/* max. Count */ pcmd.cmd_val1 =5 ;/* max. Time */ pcmd.cmd_val2 =0 ;/* =0 means read appreg */ + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx); +/* on success decide between read or write */ if (!err) { -sprintf (buf,"%d" , prx.ack2); -setenv ("appreg" , buf); +if (argc ==2 ) { + appreg =simple_strtol (argv[1 ],NULL ,10 ); +if (appreg ==0 ) { +printf ("mtc appreg: invalid parameter - " +"must be between 1 and 255\n" ); +return -1 ; + } +memset (&pcmd,0 ,sizeof (pcmd)); + pcmd.cmd =CMD_WD_PARA ; + pcmd.cmd_val0 = prx.ack3;/* max. Count */ + pcmd.cmd_val1 = prx.ack0;/* max. Time */ + pcmd.cmd_val2 = appreg;/* !=0 means write appreg */ + pcmd.user_out = user_out; +memset (&prx,0 ,sizeof (prx)); + +mtc_calculate_checksum (&pcmd); + err =msp430_xfer (&pcmd, &prx); + }else { +sprintf (buf,"%d" , prx.ack2); +setenv ("appreg" , buf); + } }return err;
@@ -236,6 +265,7 @@ static int do_mtc_version(cmd_tbl_t *cmdtp, int flag, int argc, char * const argmemset (&prx,0 ,sizeof (prx)); pcmd.cmd =CMD_FW_VERSION ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -259,6 +289,7 @@ static int do_mtc_state(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[ pcmd.cmd =CMD_WD_WDSTATE ; pcmd.cmd_val2 =1 ; + pcmd.user_out = user_out;mtc_calculate_checksum (&pcmd); err =msp430_xfer (&pcmd, &prx);
@@ -288,8 +319,10 @@ cmd_tbl_t cmd_mtc_sub[] = { "returns state of user key", ""),U_BOOT_CMD_MKENT (version,0 ,1 , do_mtc_version,"returns firmware version of supervisor uC" ,"" ), -U_BOOT_CMD_MKENT (appreg,0 ,1 , do_mtc_appreg, -"reads appreg value and stores in environment variable 'appreg'" ,"" ), +U_BOOT_CMD_MKENT (appreg,1 ,1 , do_mtc_appreg, +"reads or writes appreg value and stores in environment " +"variable 'appreg'" , +"[value] - value (1 - 255) to write to appreg" ),U_BOOT_CMD_MKENT (digin,1 ,1 , do_mtc_digin,"returns state of digital input" , "<channel_num> - get state of digital input (1 or 2)\n"),
@@ -342,8 +375,9 @@ U_BOOT_CMD(mtc, 5, 1, cmd_mtc," [blink]: blink interval in 100ms steps (1 - 10; 0 = static)\n" "key - returns state of user key\n" "version - returns firmware version of supervisor uC\n" -"appreg - reads appreg value and stores in environment variable" -" 'appreg'\n" +"appreg [value] - reads (in environment variable 'appreg') or writes" +" appreg value\n" +" [value]: value (1 - 255) to write to appreg\n" "digin [channel] - returns state of digital input (1 or 2)\n" "digout <on|off> <on|off> - sets state of two digital outputs\n" "state - displays state\n"
Signature · 1 line
1.7.1
PATCH 1/1 digsy_mtc: move board into vendor dir and add vendor logo
---
Another digsy_mtc patch for this merge window.
It applies on top of patch series
[PATCH 0/5] mpc5200: digsy_mtc: update for next.
board/{ => intercontrol}/digsy_mtc/Makefile | 0
board/{ => intercontrol}/digsy_mtc/cmd_disp.c | 0
board/{ => intercontrol}/digsy_mtc/cmd_mtc.c | 0
board/{ => intercontrol}/digsy_mtc/cmd_mtc.h | 0
board/{ => intercontrol}/digsy_mtc/digsy_mtc.c | 0
board/{ => intercontrol}/digsy_mtc/eeprom.h | 0
.../{ => intercontrol}/digsy_mtc/is42s16800a-7t.h | 0
board/{ => intercontrol}/digsy_mtc/is45s16800a2.h | 0
boards.cfg | 8 ++++----
include/configs/digsy_mtc.h | 1 +
tools/Makefile | 3 +++
tools/logos/intercontrol.bmp | Bin 0 -> 4998 bytes
12 files changed, 8 insertions(+), 4 deletions(-)
rename board/{ => intercontrol}/digsy_mtc/Makefile (100%)
rename board/{ => intercontrol}/digsy_mtc/cmd_disp.c (100%)
rename board/{ => intercontrol}/digsy_mtc/cmd_mtc.c (100%)
rename board/{ => intercontrol}/digsy_mtc/cmd_mtc.h (100%)
rename board/{ => intercontrol}/digsy_mtc/digsy_mtc.c (100%)
rename board/{ => intercontrol}/digsy_mtc/eeprom.h (100%)
rename board/{ => intercontrol}/digsy_mtc/is42s16800a-7t.h (100%)
rename board/{ => intercontrol}/digsy_mtc/is45s16800a2.h (100%)
create mode 100644 tools/logos/intercontrol.bmpboard/intercontrol/digsy_mtc/Makefile renamed from board/digsy_mtc/Makefile +0 -0
board/intercontrol/digsy_mtc/cmd_disp.c renamed from board/digsy_mtc/cmd_disp.c +0 -0
board/intercontrol/digsy_mtc/cmd_mtc.c renamed from board/digsy_mtc/cmd_mtc.c +0 -0
board/intercontrol/digsy_mtc/cmd_mtc.h renamed from board/digsy_mtc/cmd_mtc.h +0 -0
board/intercontrol/digsy_mtc/digsy_mtc.c renamed from board/digsy_mtc/digsy_mtc.c +0 -0
board/intercontrol/digsy_mtc/eeprom.h renamed from board/digsy_mtc/eeprom.h +0 -0
board/intercontrol/digsy_mtc/is42s16800a-7t.h renamed from board/digsy_mtc/is42s16800a-7t.h +0 -0
board/intercontrol/digsy_mtc/is45s16800a2.h renamed from board/digsy_mtc/is45s16800a2.h +0 -0
boards.cfg +4 -4
@@ -317,10 +317,10 @@ a4m072 powerpc mpc5xxx a4m072 BC3450 powerpc mpc5xxx bc3450 canmb powerpc mpc5xxx cm5200 powerpc mpc5xxx -digsy_mtc powerpc mpc5xxx digsy_mtc -digsy_mtc_RAMBOOT powerpc mpc5xxx digsy_mtc - - digsy_mtc:SYS_TEXT_BASE=0x00100000 -digsy_mtc_rev5 powerpc mpc5xxx digsy_mtc - - digsy_mtc:DIGSY_REV5 -digsy_mtc_rev5_RAMBOOT powerpc mpc5xxx digsy_mtc - - digsy_mtc:SYS_TEXT_BASE=0x00100000,DIGSY_REV5 +digsy_mtc powerpc mpc5xxx digsy_mtc intercontrol +digsy_mtc_RAMBOOT powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:SYS_TEXT_BASE=0x00100000 +digsy_mtc_rev5 powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:DIGSY_REV5 +digsy_mtc_rev5_RAMBOOT powerpc mpc5xxx digsy_mtc intercontrol - digsy_mtc:SYS_TEXT_BASE=0x00100000,DIGSY_REV5 galaxy5200 powerpc mpc5xxx galaxy5200 - - galaxy5200:galaxy5200 galaxy5200_LOWBOOT powerpc mpc5xxx galaxy5200 - - galaxy5200:galaxy5200_LOWBOOT icecube_5200 powerpc mpc5xxx icecube - - IceCube
include/configs/digsy_mtc.h +1 -0
@@ -97,6 +97,7 @@#define CONFIG_VIDEO_CORALP #define CONFIG_CFB_CONSOLE #define CONFIG_VIDEO_LOGO +#define CONFIG_VIDEO_BMP_LOGO #define CONFIG_VIDEO_SW_CURSOR #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_SYS_CONSOLE_IS_IN_ENV
tools/Makefile +3 -0
@@ -129,6 +129,9 @@ endif ifeq ($(VENDOR),syteco) LOGO_BMP= logos/syteco.bmp endif +ifeq ($(VENDOR),intercontrol) +LOGO_BMP= logos/intercontrol.bmp +endif # now $(obj) is defined HOSTSRCS += $(addprefix $(SRCTREE)/,$(EXT_OBJ_FILES-y:.o=.c))
tools/logos/intercontrol.bmp new file binary +0 -0
z=ad*qnv!nTI5UeagHVVa=F5CwPK9|EAol*HCF32)=C at ZEU?~eup!On1 at jb?Gi<Vq z@dYySEZZX6Zn0IG4_P*Zik)H9=rV>ds3F2$PYLigx=^s;qXSjKjDphFZ}%- at 1(=w zOn#)D{CLDsDW~m>JkO~MFOV0c{EULUIGxBZI0-)qC!NnYD_wB8T#);U!8!z at ijce zna;eMMSZx=}J(O^N6E_IMGF_FKn7ex2I;S)oSqH)~|s1R)R0w8YEgW9yGnlwcu5q zL8)*eq7Y;@L93);6_*Eir@?KaiVd52no*i2(O at u$l5{a>m@#0!m7rx?Ng8*ogGPt4 zjmBCKfJn*}eWis{d#i%otPHM^-t7{Je6x>tqe3wH_phk57<W=SiTWgTLGTjh^(~q z7n%r)3bKVI7*!M;%#0N|7%QsUsvB_w*Gh}rBx;=JE-CxDFe+kv8%%Sdo>^{>rbV; zs=!~0avXXP4RgQ{qz5yjbJZNG91A*e8h_xM5%wG_#aC;=W?B!;tZuiw<(0Fv&N++ zk8_HFYo;Q&B=OJMd(_o9%AJ2V}GJgdl5jW?$77WD|Yp(-L~o|EUpat>RfK<CG_!F z0f_x?#JgL0<W(l|*bd6<K)AcnBB|-crYpMyg;$<s=0r1hbl|lECC%q4SqDZx1vj} zNvx>su1H-|F2Jzv{@mO0P<P4aL+nU=s)ISC2I!sfAzw5KxDaMFSyhn=JIJT?r7?# zEIgd{c7ajh-Pm+5MfdEpB$i*ZtH@0pX08feb|?Yexg_%Xo1qacI-!y;>IxW>5&=<q zoUz2**^1@7j(2*#NJAl%8Hg1DLu3oRKGFP>u=1PdT|pltj*%p%Cv6+=&(z9feo5 z=~unDpT-A~mp_(I=D0=QwU=p|9a;XJEoF2mz_skJNf{JAV#E{<rpjGyl%*=UE8-8` V3!BqctLOhzzJDw~BYxls{0k2L>t6r>
literal 0
HcmV?d00001
Signature · 1 line
1.7.1
Wolfgang Denk
AppliedPATCH 1/1 digsy_mtc: move board into vendor dir and add vendor logo
Dear Anatolij Gustschin,
Quoted 20 lines · In message <[email protected]> you wrote:
Signed-off-by Anatolij Gustschin <[email protected]>---
Anotherdigsy_mtcpatch for this merge window.
It applies on top of patch series
[PATCH 0/5] mpc5200:digsy_mtc: update for next.board/{ => intercontrol}/digsy_mtc/Makefile | 0 board/{ => intercontrol}/digsy_mtc/cmd_disp.c | 0 board/{ => intercontrol}/digsy_mtc/cmd_mtc.c | 0 board/{ => intercontrol}/digsy_mtc/cmd_mtc.h | 0 board/{ => intercontrol}/digsy_mtc/digsy_mtc.c | 0 board/{ => intercontrol}/digsy_mtc/eeprom.h | 0 .../{ => intercontrol}/digsy_mtc/is42s16800a-7t.h | 0 board/{ => intercontrol}/digsy_mtc/is45s16800a2.h | 0 boards.cfg | 8 ++++---- include/configs/digsy_mtc.h | 1 + tools/Makefile | 3 +++ tools/logos/intercontrol.bmp | Bin 0 -> 4998 bytes 12 files changed, 8 insertions(+), 4 deletions(-) rename board/{ => intercontrol}/digsy_mtc/Makefile (100%)
Quoted 8 lines
rename board/{ => intercontrol}/digsy_mtc/cmd_disp.c (100%)
rename board/{ => intercontrol}/digsy_mtc/cmd_mtc.c (100%)
rename board/{ => intercontrol}/digsy_mtc/cmd_mtc.h (100%)
rename board/{ => intercontrol}/digsy_mtc/digsy_mtc.c (100%)
rename board/{ => intercontrol}/digsy_mtc/eeprom.h (100%)
rename board/{ => intercontrol}/digsy_mtc/is42s16800a-7t.h (100%)
rename board/{ => intercontrol}/digsy_mtc/is45s16800a2.h (100%)
create mode 100644 tools/logos/intercontrol.bmpApplied, thanks.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "We don't have to protect the environment -- the Second Coming is at hand." - James Watt
Wolfgang Denk
AppliedPATCH v2 5/5 mpc5200: digsy_mtc: add support for writing 'appreg' value
In reply to Anatolij GustschinDear Anatolij Gustschin,
Quoted 7 lines · In message <[email protected]> you wrote:
Up to now only reading 'appreg' value was implemented in the digsyMTC special 'mtc appreg' command. Extend the command to support writing appreg value, too.
Signed-off-by Werner Pfister <[email protected]>Signed-off-by Anatolij Gustschin <[email protected]>Acked-by Detlev Zundel <[email protected]>
Quoted 6 lines
---
v2:
- fix typo in error messageboard/digsy_mtc/cmd_mtc.c | 46 +++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 6 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I often quote myself; it adds spice to my conversation. - G. B. Shaw