Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Simon, On Thu, Apr 26, 2018 at 4:40 PM, Simon Glasswrote: > Hi Mario, > > On 26 April 2018 at 00:07, Mario Six wrote: >> Hi Simon, >> >> On Tue, Apr 24, 2018 at 11:53 PM, Simon Glass wrote: >>> Hi Mario, >>> >>> On 19 April 2018 at 01:50, Mario Six wrote: Hi Simon, On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass wrote: > Hi Mario, > > On 18 April 2018 at 02:35, Mario Six wrote: >> Hi Simon, >> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: >>> Hi Mario, >>> >>> On 11 April 2018 at 00:39, Mario Six wrote: Hi Simon, On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: > Hi, > > On 28 March 2018 at 20:38, Mario Six wrote: >> Add a cpu_print_info function to the CPU uclass to emulate the >> behavior >> of some current non-DM drivers (e.g. MPC83xx) to print CPU >> information >> during startup. >> >> Signed-off-by: Mario Six >> --- >> drivers/cpu/cpu-uclass.c | 10 ++ >> include/cpu.h| 15 +++ >> 2 files changed, 25 insertions(+) >> > > I really don't want drivers printing stuff. Can you use the existing > get_info() method? > I could, but I'm just emulating the behavior of the legacy code here, which prints some information when the CPU is initialized. I think that's pretty useful, and I can do that in our board file, but that would mean implementing the same routine in every MPC83xx board to get the legacy behavior back. >>> >>> Yes, but I don't want the legacy code creeping into the eclass. Can >>> you convert the board to use the CPU eclass instead? >>> >> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does >> exactly >> what is needed. I'll implement the print_cpuinfo function in the CPU >> driver, so >> I can get rid of the print function in the uclass (and still retain the >> information printing at bootup). > > OK I see. Ideally we would have a function (perhaps in board_f) which > prints out the CPU info after obtaining it from the uclass. So could > you move your print_cpuinfo() function into board_f? Would it be > possible to use that if CONFIG_CPU is defined? > > At some point print_cpuinfo() could be removed from various board files. > The function prints the following (example for our device): --- >8 --- Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz --- >8 --- So there are some values that are very specific to the platform, such as the CSB (Coherent System Bus) frequency, or the reset status. While it's probably possible to put some of that into a generic info printing routine, lots of it is so MPC83xx-specific that it doesn't make much sense for other CPUs. >>> >>> Well you get to provide a string from get_desc() so you can add >>> whatever you like! >>> >> >> OK, I thought I was supposed to decode the cpu_info and print that in the >> function. If i can use get_desc(), then it's fine. :-) >> Any idea how to tackle this? I don't really want to get rid of the Reset Status printing especially, since it's pretty useful information for debugging devices in the field. >>> >>> Re the reset status, shouldn't that come from the sysreset driver? I >>> wonder if we should add an API call for that? Or is it something >>> printed by the board? >>> >> >> No, that's indeed printed on every MPC83xx board (see prt_83xx_rsr in >> arch/powerpc/cpu/mpc83xx/cpu_init.c). A sysreset driver would probably be a >> good canonical candidate for printing such a message, true. But since there >> is >> no real system reset on MPC83xx to speak of, that would (for now at least) be >> the only thing a MPC83xx sysreset driver did. Also, we'd need another >> function >> in board_f.c, and I don't really know if reset cause printing is very >> wide-spread on other platforms to justify that. > > Well I've certainly printed this info myself so I think it is useful, > particularly things like whether it was a watchdog reset or user > reset. > OK, I'll write a sysreset driver for MPC83xx; shouldn't be too complicated. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Mario, On 26 April 2018 at 00:07, Mario Sixwrote: > Hi Simon, > > On Tue, Apr 24, 2018 at 11:53 PM, Simon Glass wrote: >> Hi Mario, >> >> On 19 April 2018 at 01:50, Mario Six wrote: >>> >>> Hi Simon, >>> >>> On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass wrote: >>> > Hi Mario, >>> > >>> > On 18 April 2018 at 02:35, Mario Six wrote: >>> >> Hi Simon, >>> >> >>> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: >>> >>> Hi Mario, >>> >>> >>> >>> On 11 April 2018 at 00:39, Mario Six wrote: >>> Hi Simon, >>> >>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass >>> wrote: >>> > Hi, >>> > >>> > On 28 March 2018 at 20:38, Mario Six wrote: >>> >> Add a cpu_print_info function to the CPU uclass to emulate the >>> >> behavior >>> >> of some current non-DM drivers (e.g. MPC83xx) to print CPU >>> >> information >>> >> during startup. >>> >> >>> >> Signed-off-by: Mario Six >>> >> --- >>> >> drivers/cpu/cpu-uclass.c | 10 ++ >>> >> include/cpu.h| 15 +++ >>> >> 2 files changed, 25 insertions(+) >>> >> >>> > >>> > I really don't want drivers printing stuff. Can you use the existing >>> > get_info() method? >>> > >>> >>> I could, but I'm just emulating the behavior of the legacy code here, >>> which >>> prints some information when the CPU is initialized. I think that's >>> pretty >>> useful, and I can do that in our board file, but that would mean >>> implementing >>> the same routine in every MPC83xx board to get the legacy behavior >>> back. >>> >>> >>> >>> Yes, but I don't want the legacy code creeping into the eclass. Can >>> >>> you convert the board to use the CPU eclass instead? >>> >>> >>> >> >>> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does >>> >> exactly >>> >> what is needed. I'll implement the print_cpuinfo function in the CPU >>> >> driver, so >>> >> I can get rid of the print function in the uclass (and still retain the >>> >> information printing at bootup). >>> > >>> > OK I see. Ideally we would have a function (perhaps in board_f) which >>> > prints out the CPU info after obtaining it from the uclass. So could >>> > you move your print_cpuinfo() function into board_f? Would it be >>> > possible to use that if CONFIG_CPU is defined? >>> > >>> > At some point print_cpuinfo() could be removed from various board files. >>> > >>> >>> The function prints the following (example for our device): >>> >>> --- >8 --- >>> >>> Reset Status: External/Internal Soft, External/Internal Hard >>> >>> CPU: e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz >>> >>> --- >8 --- >>> >>> So there are some values that are very specific to the platform, such as the >>> CSB (Coherent System Bus) frequency, or the reset status. While it's >>> probably >>> possible to put some of that into a generic info printing routine, lots of >>> it >>> is so MPC83xx-specific that it doesn't make much sense for other CPUs. >> >> Well you get to provide a string from get_desc() so you can add >> whatever you like! >> > > OK, I thought I was supposed to decode the cpu_info and print that in the > function. If i can use get_desc(), then it's fine. :-) > >>> >>> Any idea how to tackle this? I don't really want to get rid of the Reset >>> Status >>> printing especially, since it's pretty useful information for debugging >>> devices >>> in the field. >> >> Re the reset status, shouldn't that come from the sysreset driver? I >> wonder if we should add an API call for that? Or is it something >> printed by the board? >> > > No, that's indeed printed on every MPC83xx board (see prt_83xx_rsr in > arch/powerpc/cpu/mpc83xx/cpu_init.c). A sysreset driver would probably be a > good canonical candidate for printing such a message, true. But since there is > no real system reset on MPC83xx to speak of, that would (for now at least) be > the only thing a MPC83xx sysreset driver did. Also, we'd need another function > in board_f.c, and I don't really know if reset cause printing is very > wide-spread on other platforms to justify that. Well I've certainly printed this info myself so I think it is useful, particularly things like whether it was a watchdog reset or user reset. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Simon, On Tue, Apr 24, 2018 at 11:53 PM, Simon Glasswrote: > Hi Mario, > > On 19 April 2018 at 01:50, Mario Six wrote: >> >> Hi Simon, >> >> On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass wrote: >> > Hi Mario, >> > >> > On 18 April 2018 at 02:35, Mario Six wrote: >> >> Hi Simon, >> >> >> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: >> >>> Hi Mario, >> >>> >> >>> On 11 April 2018 at 00:39, Mario Six wrote: >> Hi Simon, >> >> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >> > Hi, >> > >> > On 28 March 2018 at 20:38, Mario Six wrote: >> >> Add a cpu_print_info function to the CPU uclass to emulate the >> >> behavior >> >> of some current non-DM drivers (e.g. MPC83xx) to print CPU information >> >> during startup. >> >> >> >> Signed-off-by: Mario Six >> >> --- >> >> drivers/cpu/cpu-uclass.c | 10 ++ >> >> include/cpu.h| 15 +++ >> >> 2 files changed, 25 insertions(+) >> >> >> > >> > I really don't want drivers printing stuff. Can you use the existing >> > get_info() method? >> > >> >> I could, but I'm just emulating the behavior of the legacy code here, >> which >> prints some information when the CPU is initialized. I think that's >> pretty >> useful, and I can do that in our board file, but that would mean >> implementing >> the same routine in every MPC83xx board to get the legacy behavior back. >> >>> >> >>> Yes, but I don't want the legacy code creeping into the eclass. Can >> >>> you convert the board to use the CPU eclass instead? >> >>> >> >> >> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does >> >> exactly >> >> what is needed. I'll implement the print_cpuinfo function in the CPU >> >> driver, so >> >> I can get rid of the print function in the uclass (and still retain the >> >> information printing at bootup). >> > >> > OK I see. Ideally we would have a function (perhaps in board_f) which >> > prints out the CPU info after obtaining it from the uclass. So could >> > you move your print_cpuinfo() function into board_f? Would it be >> > possible to use that if CONFIG_CPU is defined? >> > >> > At some point print_cpuinfo() could be removed from various board files. >> > >> >> The function prints the following (example for our device): >> >> --- >8 --- >> >> Reset Status: External/Internal Soft, External/Internal Hard >> >> CPU: e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz >> >> --- >8 --- >> >> So there are some values that are very specific to the platform, such as the >> CSB (Coherent System Bus) frequency, or the reset status. While it's probably >> possible to put some of that into a generic info printing routine, lots of it >> is so MPC83xx-specific that it doesn't make much sense for other CPUs. > > Well you get to provide a string from get_desc() so you can add > whatever you like! > OK, I thought I was supposed to decode the cpu_info and print that in the function. If i can use get_desc(), then it's fine. :-) >> >> Any idea how to tackle this? I don't really want to get rid of the Reset >> Status >> printing especially, since it's pretty useful information for debugging >> devices >> in the field. > > Re the reset status, shouldn't that come from the sysreset driver? I > wonder if we should add an API call for that? Or is it something > printed by the board? > No, that's indeed printed on every MPC83xx board (see prt_83xx_rsr in arch/powerpc/cpu/mpc83xx/cpu_init.c). A sysreset driver would probably be a good canonical candidate for printing such a message, true. But since there is no real system reset on MPC83xx to speak of, that would (for now at least) be the only thing a MPC83xx sysreset driver did. Also, we'd need another function in board_f.c, and I don't really know if reset cause printing is very wide-spread on other platforms to justify that. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Mario, On 19 April 2018 at 01:50, Mario Sixwrote: > > Hi Simon, > > On Wed, Apr 18, 2018 at 5:45 PM, Simon Glass wrote: > > Hi Mario, > > > > On 18 April 2018 at 02:35, Mario Six wrote: > >> Hi Simon, > >> > >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: > >>> Hi Mario, > >>> > >>> On 11 April 2018 at 00:39, Mario Six wrote: > Hi Simon, > > On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: > > Hi, > > > > On 28 March 2018 at 20:38, Mario Six wrote: > >> Add a cpu_print_info function to the CPU uclass to emulate the behavior > >> of some current non-DM drivers (e.g. MPC83xx) to print CPU information > >> during startup. > >> > >> Signed-off-by: Mario Six > >> --- > >> drivers/cpu/cpu-uclass.c | 10 ++ > >> include/cpu.h| 15 +++ > >> 2 files changed, 25 insertions(+) > >> > > > > I really don't want drivers printing stuff. Can you use the existing > > get_info() method? > > > > I could, but I'm just emulating the behavior of the legacy code here, > which > prints some information when the CPU is initialized. I think that's > pretty > useful, and I can do that in our board file, but that would mean > implementing > the same routine in every MPC83xx board to get the legacy behavior back. > >>> > >>> Yes, but I don't want the legacy code creeping into the eclass. Can > >>> you convert the board to use the CPU eclass instead? > >>> > >> > >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does > >> exactly > >> what is needed. I'll implement the print_cpuinfo function in the CPU > >> driver, so > >> I can get rid of the print function in the uclass (and still retain the > >> information printing at bootup). > > > > OK I see. Ideally we would have a function (perhaps in board_f) which > > prints out the CPU info after obtaining it from the uclass. So could > > you move your print_cpuinfo() function into board_f? Would it be > > possible to use that if CONFIG_CPU is defined? > > > > At some point print_cpuinfo() could be removed from various board files. > > > > The function prints the following (example for our device): > > --- >8 --- > > Reset Status: External/Internal Soft, External/Internal Hard > > CPU: e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz > > --- >8 --- > > So there are some values that are very specific to the platform, such as the > CSB (Coherent System Bus) frequency, or the reset status. While it's probably > possible to put some of that into a generic info printing routine, lots of it > is so MPC83xx-specific that it doesn't make much sense for other CPUs. Well you get to provide a string from get_desc() so you can add whatever you like! > > Any idea how to tackle this? I don't really want to get rid of the Reset > Status > printing especially, since it's pretty useful information for debugging > devices > in the field. Re the reset status, shouldn't that come from the sysreset driver? I wonder if we should add an API call for that? Or is it something printed by the board? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Simon, On Wed, Apr 18, 2018 at 5:45 PM, Simon Glasswrote: > Hi Mario, > > On 18 April 2018 at 02:35, Mario Six wrote: >> Hi Simon, >> >> On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: >>> Hi Mario, >>> >>> On 11 April 2018 at 00:39, Mario Six wrote: Hi Simon, On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: > Hi, > > On 28 March 2018 at 20:38, Mario Six wrote: >> Add a cpu_print_info function to the CPU uclass to emulate the behavior >> of some current non-DM drivers (e.g. MPC83xx) to print CPU information >> during startup. >> >> Signed-off-by: Mario Six >> --- >> drivers/cpu/cpu-uclass.c | 10 ++ >> include/cpu.h| 15 +++ >> 2 files changed, 25 insertions(+) >> > > I really don't want drivers printing stuff. Can you use the existing > get_info() method? > I could, but I'm just emulating the behavior of the legacy code here, which prints some information when the CPU is initialized. I think that's pretty useful, and I can do that in our board file, but that would mean implementing the same routine in every MPC83xx board to get the legacy behavior back. >>> >>> Yes, but I don't want the legacy code creeping into the eclass. Can >>> you convert the board to use the CPU eclass instead? >>> >> >> That's what I did, and I just discovered DISPLAY_CPUINFO, which does exactly >> what is needed. I'll implement the print_cpuinfo function in the CPU driver, >> so >> I can get rid of the print function in the uclass (and still retain the >> information printing at bootup). > > OK I see. Ideally we would have a function (perhaps in board_f) which > prints out the CPU info after obtaining it from the uclass. So could > you move your print_cpuinfo() function into board_f? Would it be > possible to use that if CONFIG_CPU is defined? > > At some point print_cpuinfo() could be removed from various board files. > The function prints the following (example for our device): --- >8 --- Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c3, MPC8308, Rev: 1.1 at 400 MHz, CSB: 133.333 MHz --- >8 --- So there are some values that are very specific to the platform, such as the CSB (Coherent System Bus) frequency, or the reset status. While it's probably possible to put some of that into a generic info printing routine, lots of it is so MPC83xx-specific that it doesn't make much sense for other CPUs. Any idea how to tackle this? I don't really want to get rid of the Reset Status printing especially, since it's pretty useful information for debugging devices in the field. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Mario, On 18 April 2018 at 02:35, Mario Sixwrote: > Hi Simon, > > On Thu, Apr 12, 2018 at 6:37 PM, Simon Glass wrote: >> Hi Mario, >> >> On 11 April 2018 at 00:39, Mario Six wrote: >>> Hi Simon, >>> >>> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: Hi, On 28 March 2018 at 20:38, Mario Six wrote: > Add a cpu_print_info function to the CPU uclass to emulate the behavior > of some current non-DM drivers (e.g. MPC83xx) to print CPU information > during startup. > > Signed-off-by: Mario Six > --- > drivers/cpu/cpu-uclass.c | 10 ++ > include/cpu.h| 15 +++ > 2 files changed, 25 insertions(+) > I really don't want drivers printing stuff. Can you use the existing get_info() method? >>> >>> I could, but I'm just emulating the behavior of the legacy code here, which >>> prints some information when the CPU is initialized. I think that's pretty >>> useful, and I can do that in our board file, but that would mean >>> implementing >>> the same routine in every MPC83xx board to get the legacy behavior back. >> >> Yes, but I don't want the legacy code creeping into the eclass. Can >> you convert the board to use the CPU eclass instead? >> > > That's what I did, and I just discovered DISPLAY_CPUINFO, which does exactly > what is needed. I'll implement the print_cpuinfo function in the CPU driver, > so > I can get rid of the print function in the uclass (and still retain the > information printing at bootup). OK I see. Ideally we would have a function (perhaps in board_f) which prints out the CPU info after obtaining it from the uclass. So could you move your print_cpuinfo() function into board_f? Would it be possible to use that if CONFIG_CPU is defined? At some point print_cpuinfo() could be removed from various board files. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Simon, On Thu, Apr 12, 2018 at 6:37 PM, Simon Glasswrote: > Hi Mario, > > On 11 April 2018 at 00:39, Mario Six wrote: >> Hi Simon, >> >> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >>> Hi, >>> >>> On 28 March 2018 at 20:38, Mario Six wrote: Add a cpu_print_info function to the CPU uclass to emulate the behavior of some current non-DM drivers (e.g. MPC83xx) to print CPU information during startup. Signed-off-by: Mario Six --- drivers/cpu/cpu-uclass.c | 10 ++ include/cpu.h| 15 +++ 2 files changed, 25 insertions(+) >>> >>> I really don't want drivers printing stuff. Can you use the existing >>> get_info() method? >>> >> >> I could, but I'm just emulating the behavior of the legacy code here, which >> prints some information when the CPU is initialized. I think that's pretty >> useful, and I can do that in our board file, but that would mean implementing >> the same routine in every MPC83xx board to get the legacy behavior back. > > Yes, but I don't want the legacy code creeping into the eclass. Can > you convert the board to use the CPU eclass instead? > That's what I did, and I just discovered DISPLAY_CPUINFO, which does exactly what is needed. I'll implement the print_cpuinfo function in the CPU driver, so I can get rid of the print function in the uclass (and still retain the information printing at bootup). > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Mario, On 11 April 2018 at 00:39, Mario Sixwrote: > Hi Simon, > > On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass wrote: >> Hi, >> >> On 28 March 2018 at 20:38, Mario Six wrote: >>> Add a cpu_print_info function to the CPU uclass to emulate the behavior >>> of some current non-DM drivers (e.g. MPC83xx) to print CPU information >>> during startup. >>> >>> Signed-off-by: Mario Six >>> --- >>> drivers/cpu/cpu-uclass.c | 10 ++ >>> include/cpu.h| 15 +++ >>> 2 files changed, 25 insertions(+) >>> >> >> I really don't want drivers printing stuff. Can you use the existing >> get_info() method? >> > > I could, but I'm just emulating the behavior of the legacy code here, which > prints some information when the CPU is initialized. I think that's pretty > useful, and I can do that in our board file, but that would mean implementing > the same routine in every MPC83xx board to get the legacy behavior back. Yes, but I don't want the legacy code creeping into the eclass. Can you convert the board to use the CPU eclass instead? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi Simon, On Fri, Mar 30, 2018 at 10:41 AM, Simon Glasswrote: > Hi, > > On 28 March 2018 at 20:38, Mario Six wrote: >> Add a cpu_print_info function to the CPU uclass to emulate the behavior >> of some current non-DM drivers (e.g. MPC83xx) to print CPU information >> during startup. >> >> Signed-off-by: Mario Six >> --- >> drivers/cpu/cpu-uclass.c | 10 ++ >> include/cpu.h| 15 +++ >> 2 files changed, 25 insertions(+) >> > > I really don't want drivers printing stuff. Can you use the existing > get_info() method? > I could, but I'm just emulating the behavior of the legacy code here, which prints some information when the CPU is initialized. I think that's pretty useful, and I can do that in our board file, but that would mean implementing the same routine in every MPC83xx board to get the legacy behavior back. > Regards, > Simon > Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Hi, On 28 March 2018 at 20:38, Mario Sixwrote: > Add a cpu_print_info function to the CPU uclass to emulate the behavior > of some current non-DM drivers (e.g. MPC83xx) to print CPU information > during startup. > > Signed-off-by: Mario Six > --- > drivers/cpu/cpu-uclass.c | 10 ++ > include/cpu.h| 15 +++ > 2 files changed, 25 insertions(+) > I really don't want drivers printing stuff. Can you use the existing get_info() method? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/8] cpu: Add cpu_print_info function
Add a cpu_print_info function to the CPU uclass to emulate the behavior of some current non-DM drivers (e.g. MPC83xx) to print CPU information during startup. Signed-off-by: Mario Six--- drivers/cpu/cpu-uclass.c | 10 ++ include/cpu.h| 15 +++ 2 files changed, 25 insertions(+) diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c index 73e4853939..854cedd1b0 100644 --- a/drivers/cpu/cpu-uclass.c +++ b/drivers/cpu/cpu-uclass.c @@ -54,6 +54,16 @@ int cpu_get_vendor(struct udevice *dev, char *buf, int size) return ops->get_vendor(dev, buf, size); } +int cpu_print_info(struct udevice *dev) +{ + struct cpu_ops *ops = cpu_get_ops(dev); + + if (!ops->get_vendor) + return -ENOSYS; + + return ops->print_info(dev); +} + U_BOOT_DRIVER(cpu_bus) = { .name = "cpu_bus", .id = UCLASS_SIMPLE_BUS, diff --git a/include/cpu.h b/include/cpu.h index 954257715a..37ff000bf9 100644 --- a/include/cpu.h +++ b/include/cpu.h @@ -83,6 +83,14 @@ struct cpu_ops { * @return 0 if OK, -ENOSPC if buffer is too small, other -ve on error */ int (*get_vendor)(struct udevice *dev, char *buf, int size); + + /** +* print_info() - Print information about a CPU +* +* @dev:Device to check (UCLASS_CPU) +* @return 0 if OK, -ENOSPC if buffer is too small, other -ve on error +*/ + int (*print_info)(struct udevice *dev); }; #define cpu_get_ops(dev)((struct cpu_ops *)(dev)->driver->ops) @@ -124,4 +132,11 @@ int cpu_get_count(struct udevice *dev); */ int cpu_get_vendor(struct udevice *dev, char *buf, int size); +/** + * cpu_print_info() - Print information about a CPU + * + * @dev: Device to check (UCLASS_CPU) + * @return 0 if OK, -ENOSPC if buffer is too small, other -ve on error + */ +int cpu_print_info(struct udevice *dev); #endif -- 2.16.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot