Re: [PATCH 2/3] gpio: fix null pointer exception when there is no oftree
On Thu, 6 Jul 2017, Lucas Stach wrote:
> Am Mittwoch, den 05.07.2017, 20:33 +0200 schrieb Sam Ravnborg:
> > From d10f426e1b8cec7de257dabf59e7fe53a591b3c1 Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg
> > Date: Mon, 3 Jul 2017 22:07:41 +0200
> > Subject: [PATCH 2/3] gpio: fix null pointer exception when there is no
> > oftree
> >
> > In a system with oftree support enabled but with no oftree the
> > of_gpiochip_scan_hogs() would fail due to device_node equals NULL.
> >
> > Check device_node and return with 0 in this situation, as this
> > mirrors what would have happened before we added support for gpio-hogs.
> >
> > Use IS_ENABLED(CONFIG_OFDEVICE) to teach compiler to leave
> > out the of_* specific functions if not needed.
> >
> > Fixes: 37e6bee7 ("gpiolib: Add support for GPIO "hog" nodes")
> > Signed-off-by: Alexander Kurz
> > Signed-off-by: Sam Ravnborg
> > ---
> > drivers/gpio/gpiolib.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index a3e17ada0..2bd8ef2a8 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -379,6 +379,9 @@ static int of_gpiochip_scan_hogs(struct gpio_chip *chip)
> > struct device_node *np;
> > int ret, i;
> >
> > + if (!chip->dev->device_node)
> > + return 0;
> > +
> > for_each_available_child_of_node(chip->dev->device_node, np) {
> > if (!of_property_read_bool(np, "gpio-hog"))
> > continue;
> > @@ -416,7 +419,10 @@ int gpiochip_add(struct gpio_chip *chip)
> > for (i = chip->base; i < chip->base + chip->ngpio; i++)
> > gpio_desc[i].chip = chip;
> >
> > - return of_gpiochip_scan_hogs(chip);
> > + if (IS_ENABLED(CONFIG_OFDEVICE))
> > + return of_gpiochip_scan_hogs(chip);
> > + else
> > + return 0;
> > }
> >
> > void gpiochip_remove(struct gpio_chip *chip)
>
> I think this can be simplified to:
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a3e17ada0d39..1a373ef149a5 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -379,6 +379,9 @@ static int of_gpiochip_scan_hogs(struct gpio_chip
> *chip)
> struct device_node *np;
> int ret, i;
>
> + if (!IS_ENABLED(CONFIG_OFDEVICE) || !chip->dev->device_node)
> + return 0;
> +
> for_each_available_child_of_node(chip->dev->device_node, np) {
> if (!of_property_read_bool(np, "gpio-hog"))
> continue;
>
> The optimizer should be able to work this out. Can you check that this
> works for you? No need to resend, if it works I'll just commit this.
This works perfecty fine with gcc-5.2 and gcc-4.6
(although gcc-4.6 compatibilty broke with commit 4ef026c3048)
Thanks, Alexander
>
> Regards,
> Lucas
>
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] ARM: imx: use register defines in imxcfg files instead of plain numbers
Hello Lucas, TL;DR: I did build all affected images, then patched the source with the patch under discussion, called make and the image's dcd tables were unaltered. On Thu, Jul 06, 2017 at 12:23:57PM +0200, Lucas Stach wrote: > Those aren't used anymore and are just the result of missing janitorial > work to the board Makefiles. It's even worse. The build system doesn't notice when I change an imxdcd file: $ armmake ... $ md5sum images/barebox-karo-imx6q-tx6x-1g.img 5e048a92390cafec157e6617570f8cd7 images/barebox-karo-imx6q-tx6x-1g.img $ vim arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg $ git diff arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg diff --git a/arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg b/arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg index be4efe3c706e..a6e4e8b9e140 100644 --- a/arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg +++ b/arch/arm/boards/karo-tx6x/flash-header-tx6q-1g.imxcfg @@ -2,8 +2,8 @@ soc imx6 loadaddr 0x2000 dcdofs 0x400 -wm 32 0x020e00a4 0x0016 wm 32 0x020e00c4 0x0011 +wm 32 0x020e00a4 0x0016 wm 32 0x020e03b8 0xf079 wm 32 0x020e03d8 0xf079 wm 32 0x020e0898 0x $ armmake ... $ md5sum images/barebox-karo-imx6q-tx6x-1g.img 5e048a92390cafec157e6617570f8cd7 images/barebox-karo-imx6q-tx6x-1g.img $ memtool md -s images/barebox-karo-imx6q-tx6x-1g.img 0x400+0x50 0400: 402000d1 20001000 242c.. @... ,.. 0410: 2420 2400 .. ... 0420: 2000 00075000 409005d2... .P.@ 0430: 049403cc a4000e02 1600 c4000e02 0440: 1100 b8030e02 79f0 d8030e02 ...y Look at Offset 0x434, "0x020e00a4 0x0016" is still before "0x020e00c4 0x0011". > > missing (and so unchecked) are: > > > > flash-header-eltec-hipercam.imxcfg > > karo-tx6x/* > > What you need to look for is something like > "arch/arm/boards/tqma6x/.flash-header-tqma6q.dcd.dcd.tmp" which is > generated from the dependencies in images/Makefile.imx This isn't any better: $ find -name \*dcd.dcd.tmp | nl 1 ./arch/arm/boards/cm-fx6/.flash-header-mx6-cm-fx6.dcd.dcd.tmp 2 ./arch/arm/boards/dfi-fs700-m60/.flash-header-fs700-m60-6s.dcd.dcd.tmp 3 ./arch/arm/boards/dfi-fs700-m60/.flash-header-fs700-m60-6q-nanya.dcd.dcd.tmp 4 ./arch/arm/boards/dfi-fs700-m60/.flash-header-fs700-m60-6q-micron.dcd.dcd.tmp 5 ./arch/arm/boards/embedsky-e9/.flash-header-e9.dcd.dcd.tmp 6 ./arch/arm/boards/embest-riotboard/.flash-header-embest-riotboard.dcd.dcd.tmp 7 ./arch/arm/boards/gk802/.flash-header.dcd.dcd.tmp 8 ./arch/arm/boards/freescale-mx6-sabrelite/.flash-header-mx6-sabrelite.dcd.dcd.tmp 9 ./arch/arm/boards/freescale-mx6-sabresd/.flash-header-mx6-sabresd.dcd.dcd.tmp 10 ./arch/arm/boards/technexion-pico-hobbit/.flash-header-imx6ul-pico-hobbit-256.dcd.dcd.tmp 11 ./arch/arm/boards/technexion-pico-hobbit/.flash-header-imx6ul-pico-hobbit-512.dcd.dcd.tmp 12 ./arch/arm/boards/technexion-wandboard/.flash-header-technexion-wandboard.dcd.dcd.tmp 13 ./arch/arm/boards/tqma6x/.flash-header-tqma6q.dcd.dcd.tmp 14 ./arch/arm/boards/tqma6x/.flash-header-tqma6dl.dcd.dcd.tmp 15 ./arch/arm/boards/udoo/.flash-header-mx6-udoo.dcd.dcd.tmp 16 ./arch/arm/boards/variscite-mx6/.flash-header-variscite.dcd.dcd.tmp $ find -name \*.dcd | nl 1 ./arch/arm/boards/cm-fx6/flash-header-mx6-cm-fx6.dcd 2 ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6s.dcd 3 ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-nanya.dcd 4 ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-micron.dcd 5 ./arch/arm/boards/embedsky-e9/flash-header-e9.dcd 6 ./arch/arm/boards/embest-riotboard/flash-header-embest-riotboard.dcd 7 ./arch/arm/boards/gk802/flash-header.dcd 8 ./arch/arm/boards/freescale-mx6-sabrelite/flash-header-mx6-sabrelite.dcd 9 ./arch/arm/boards/freescale-mx6-sabresd/flash-header-mx6-sabresd.dcd 10 ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-256.dcd 11 ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-512.dcd 12 ./arch/arm/boards/technexion-wandboard/flash-header-technexion-wandboard.dcd 13 ./arch/arm/boards/tqma6x/flash-header-tqma6q.dcd 14 ./arch/arm/boards/tqma6x/flash-header-tqma6dl.dcd 15 ./arch/arm/boards/udoo/flash-header-mx6-udoo.dcd 16 ./arch/arm/boards/variscite-mx6/flash-header-variscite.dcd Hmm, the actual command for start_imx6q_tx6x_1g.pblx is: $(CROSS_COMPILE)gcc -E -Wp,-MD,images/.start_
[PATCH] crypto: digest: Fix digesting over memory chunks > 4096 bytes
There are two different cases that are handled in digest_file_window: a) the file to digest is memmappable (e.g. /dev/mem) b) it isn't (e.g. files in /) In both cases a file is digested in hunks of (up to) 4096 bytes. After each hunk in b) the buffer that is fed to digest_update() is then overwritten using read() to get the next hunk to digest. In case a) however it was forgotten to step forward in the buffer and instead the same data was handed to digest_update() again and again. So to fix that increase buffer by the number of bytes already digested for case a) which is characterized by flags == 0. Signed-off-by: Uwe Kleine-König --- Hello, this is the obvious and minimal patch to fix this issue. Maybe it is worth to simplify the function by splitting it in two where each one handles one of the cases above. Best regards Uwe crypto/digest.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/crypto/digest.c b/crypto/digest.c index 7a8c3c092d7d..bc6de0b98f46 100644 --- a/crypto/digest.c +++ b/crypto/digest.c @@ -272,6 +272,9 @@ int digest_file_window(struct digest *d, const char *filename, goto out_free; size -= now; len += now; + + if (!flags) + buf += now; } if (sig) -- 2.11.0 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v1 3/3] regulator: pfuze: provide power over standby handler
Am 06.07.2017 um 16:12 schrieb Lucas Stach: > Am Donnerstag, den 06.07.2017, 16:00 +0200 schrieb Oleksij Rempel: >> This patch is providing an optional power off handler >> which will configure standby state of the PMIC to disable all power lines. >> >> In my power consumption test on RIoTBoard, I got the following results: >> power off without this patch: 320 mA >> power off with this patch: 2 mA >> suspend to ram: 40 mA > > You probably haven't measured suspend to ram with barebox, right? ;) Oops... yeas :) >> >> Signed-off-by: Oleksij Rempel >> --- >> drivers/regulator/pfuze.c | 87 >> +++ >> 1 file changed, 87 insertions(+) >> >> diff --git a/drivers/regulator/pfuze.c b/drivers/regulator/pfuze.c >> index 2a5fb715ce..94fa03ff15 100644 >> --- a/drivers/regulator/pfuze.c >> +++ b/drivers/regulator/pfuze.c >> @@ -26,10 +26,53 @@ >> >> #include >> >> +#include >> +#include >> + > This introduces a build dependency of the PFUZE driver to the i.MX6 > architecture. While I think this is fine, as it keeps things > straight-forward and the PFUZE is unlikely to be used on other SoCs, > this needs at least a "depends on ARCH_IMX6" in the Kconfig entry. Ok. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
RE: Earliest possible GPIO toggle on i.mx6
> -Original Message- > From: Mayur Nande > Sent: Wednesday, July 05, 2017 3:18 PM > To: 'Lucas Stach' > Cc: barebox@lists.infradead.org > Subject: RE: Earliest possible GPIO toggle on i.mx6 > > Hello Lucas, > > Thank you for the reply. > > > -Original Message- > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > Sent: Wednesday, July 05, 2017 2:52 PM > > To: Mayur Nande > > Cc: barebox@lists.infradead.org > > Subject: Re: Earliest possible GPIO toggle on i.mx6 > > > > Am Mittwoch, den 05.07.2017, 12:41 + schrieb Mayur Nande: > > > Hello all, > > > > > > I have a question regarding the earliest possible GPIO toggle with > > > barebox on imx6. We use boards with imx6 quad core processor (from > > > Phytec). In our hardware design we have a push button controller > > > which has a "KILL" pin attached to one of the GPIO pins on i.mx6. > > > The requirement is that this pin should be set to 1 within 400 ms of > > > power on. I tried setting this at various places in barebox with > > > incremental improvements starting from the init script, board.c, > > > lowlevel.c and then DCD/lowlevel.c combination. > > > > > > The best performance I got was by setting the iomux registers > > > (IOMUXC_SW_MUX_CTL_PAD and IOMUXC_SW_PAD_CTL_PAD) in DCD > > and the GPIO > > > direction and value registers in lowlevel.c (since GPIO controller > > > registers are not accessible with DCD). Even with this, I get the > > > GPIO set in around 460-475ms at the best. I understand that some of > > > the time here is used by the hardware for voltage regulation/crystal > > > stabilization which probably we can't do anything about. > > > > If lowlevel.c is too late already, the only chance to make this work > > is setting the DCD padctl to configure a pull-up/down to satisfy the > > KILL pin. Then in the board file set up the GPIO and switch the padctl to > neutral state. > Ok, I will try this. I tried this, but unfortunately none of the available internal pull-up and pull-down values satisfy the KILL pin (it goes through an digital isolator and we cannot satisfy the logic level it asks for). The only way is to set the pin as output. > > Still 400ms sound like a awfully long time to reach lowlevel init. > > What is your boot source, i.e. where is the barebox binary stored? > The bootsource is external 8GB SD/MMC card. I also tried the internal emmc just as an experiment and the delay is nearly the same. I have some suggestions from Chris Healy like trying SPI NOR and using the fast boot bit of SDHC, I will try that as my next steps. The final (non-preferred) solution would be to change the hardware. Thank you. Regards Mayur ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/2] Documentation: socfpga: update sequencer documentation
Update the documentation in regard of the sequencer importer. Signed-off-by: Steffen Trumtrar --- Documentation/boards/socfpga.rst | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/boards/socfpga.rst b/Documentation/boards/socfpga.rst index 358e5ab91030..2b6c8a5b1658 100644 --- a/Documentation/boards/socfpga.rst +++ b/Documentation/boards/socfpga.rst @@ -124,12 +124,19 @@ where `` is the directory where the bsp-editor generated the `` is the directory where Quartus generated the handoff files, and `` is your board directory under `arch/arm/boards`. -The following files are generic and belong into the -`arch/arm/mach-socfpga` directory tree: + +Integrating new SDRAM driver + + +This step must only be executed if the SDRAM driver needs updates. It is not necessary +for adding a new board to barebox. + +The following files are generic and belong into the `arch/arm/mach-socfpga` directory +tree: * sdram_io.h -* sequencer.c -* sequencer.h +* sequencer.c as cyclone5-sequencer.c +* sequencer.h as cyclone5-sequencer.h * sequencer_defines.h * system.h * tclrpt.h -- 2.11.0 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/2] scripts: socfpga_get_sequencer: update importer
Adjust two header files that where renamed in the meantime.
While at it, also remove trailing whitespace and cleanup the
script a little.
Signed-off-by: Steffen Trumtrar
---
scripts/socfpga_get_sequencer | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/scripts/socfpga_get_sequencer b/scripts/socfpga_get_sequencer
index e0f2e6de2abd..36f67498bcbb 100755
--- a/scripts/socfpga_get_sequencer
+++ b/scripts/socfpga_get_sequencer
@@ -41,14 +41,18 @@ copy_source() {
sed -i 's/alt_8/int8_t/g' $tgt
sed -i 's/#include "alt_types.h"//g' $tgt
- echo " Fixing include pathes..."
+ echo " Fixing include paths..."
# Fix include pathes
- sed -i 's/#include /#include /g' $tgt
+ sed -i 's/#include /#include /g' $tgt
sed -i 's/#include "sequencer_auto.h"//g' $tgt
+ sed -i 's/#include "sequencer.h"/#include "cyclone5-sequencer.h"/g' $tgt
echo " Automated readability fixup..."
indent -npro -kr -i8 -ts8 -sob -l100 -ss -ncs -cp1 -il0 $tgt
+ echo " Whitespace cleanup..."
+ sed -i 's/[ \t]\+$//' $tgt
+
echo " Running coccinelle cleanups..."
spatch -sp_file scripts/coccinelle/misc/altera_sequencer.cocci
-in_place arch/arm/mach-socfpga/include/mach
@@ -61,19 +65,10 @@ copy_source() {
sed -i 's/^static void rw_mgr_decr_vfifo_auto(uint32_t grp);$//g' $tgt
}
-copy_source ${ubootsrc}/board/altera/socfpga/sdram/sequencer.c
arch/arm/mach-socfpga/include/mach/sequencer.c
-sed -i 's/static int sdram_calibration(void)/static int
socfpga_mem_calibration(void)/g' arch/arm/mach-socfpga/include/mach/sequencer.c
-
-cat <<'EOF' > arch/arm/mach-socfpga/include/mach/sequencer_defines.h
-#define TINIT_CNTR1_VAL 32
-#define TINIT_CNTR2_VAL 32
-#define TINIT_CNTR0_VAL 99
-#define TRESET_CNTR1_VAL 99
-#define TRESET_CNTR2_VAL 10
-#define TRESET_CNTR0_VAL 99
-EOF
+copy_source ${ubootsrc}/board/altera/socfpga/sdram/sequencer.c
arch/arm/mach-socfpga/include/mach/cyclone5-sequencer.c
+sed -i 's/static int sdram_calibration(void)/static int
socfpga_mem_calibration(void)/g'
arch/arm/mach-socfpga/include/mach/cyclone5-sequencer.c
-copy_source ${ubootsrc}/board/altera/socfpga/sdram/sequencer.h
arch/arm/mach-socfpga/include/mach/sequencer.h
+copy_source ${ubootsrc}/board/altera/socfpga/sdram/sequencer.h
arch/arm/mach-socfpga/include/mach/cyclone5-sequencer.h
copy_source ${ubootsrc}/board/altera/socfpga/sdram/tclrpt.h
arch/arm/mach-socfpga/include/mach/tclrpt.h
copy_source ${ubootsrc}/board/altera/socfpga/sdram/sdram_io.h
arch/arm/mach-socfpga/include/mach/sdram_io.h
cat <<'EOF' >> arch/arm/mach-socfpga/include/mach/sdram_io.h
@@ -85,7 +80,5 @@ cat <<'EOF' >> arch/arm/mach-socfpga/include/mach/sdram_io.h
EOF
copy_source ${ubootsrc}/board/altera/socfpga/sdram/system.h
arch/arm/mach-socfpga/include/mach/system.h
-#unifdef -f ${sequencer_defines}
${ubootsrc}/board/altera/socfpga/sdram/tclrpt.c -o
arch/arm/mach-socfpga/include/mach/tclrpt.c
-
echo "DONE"
--
2.11.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v1 3/3] regulator: pfuze: provide power over standby handler
Am Donnerstag, den 06.07.2017, 16:00 +0200 schrieb Oleksij Rempel:
> This patch is providing an optional power off handler
> which will configure standby state of the PMIC to disable all power lines.
>
> In my power consumption test on RIoTBoard, I got the following results:
> power off without this patch: 320 mA
> power off with this patch: 2 mA
> suspend to ram: 40 mA
You probably haven't measured suspend to ram with barebox, right? ;)
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/regulator/pfuze.c | 87
> +++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/regulator/pfuze.c b/drivers/regulator/pfuze.c
> index 2a5fb715ce..94fa03ff15 100644
> --- a/drivers/regulator/pfuze.c
> +++ b/drivers/regulator/pfuze.c
> @@ -26,10 +26,53 @@
>
> #include
>
> +#include
> +#include
> +
This introduces a build dependency of the PFUZE driver to the i.MX6
architecture. While I think this is fine, as it keeps things
straight-forward and the PFUZE is unlikely to be used on other SoCs,
this needs at least a "depends on ARCH_IMX6" in the Kconfig entry.
Regards,
Lucas
> #define DRIVERNAME "pfuze"
>
> #define MC13XXX_NUMREGS 0x3f
>
> +#define PFUZE_NUMREGS128
> +#define PFUZE100_VOL_OFFSET 0
> +#define PFUZE100_STANDBY_OFFSET 1
> +#define PFUZE100_MODE_OFFSET 3
> +#define PFUZE100_CONF_OFFSET 4
> +
> +#define PFUZE100_DEVICEID0x0
> +#define PFUZE100_REVID 0x3
> +#define PFUZE100_FABID 0x4
> +
> +#define PFUZE100_COINVOL 0x1a
> +#define PFUZE100_SW1ABVOL0x20
> +#define PFUZE100_SW1ABMODE 0x23
> +#define PFUZE100_SW1CVOL 0x2e
> +#define PFUZE100_SW1CMODE0x31
> +#define PFUZE100_SW2VOL 0x35
> +#define PFUZE100_SW2MODE 0x38
> +#define PFUZE100_SW3AVOL 0x3c
> +#define PFUZE100_SW3AMODE0x3f
> +#define PFUZE100_SW3BVOL 0x43
> +#define PFUZE100_SW3BMODE0x46
> +#define PFUZE100_SW4VOL 0x4a
> +#define PFUZE100_SW4MODE 0x4d
> +#define PFUZE100_SWBSTCON1 0x66
> +#define PFUZE100_VREFDDRCON 0x6a
> +#define PFUZE100_VSNVSVOL0x6b
> +#define PFUZE100_VGEN1VOL0x6c
> +#define PFUZE100_VGEN2VOL0x6d
> +#define PFUZE100_VGEN3VOL0x6e
> +#define PFUZE100_VGEN4VOL0x6f
> +#define PFUZE100_VGEN5VOL0x70
> +#define PFUZE100_VGEN6VOL0x71
> +
> +#define PFUZE100_SWxMODE_MASK0xf
> +#define PFUZE100_SWxMODE_APS_APS 0x8
> +#define PFUZE100_SWxMODE_APS_OFF 0x4
> +
> +#define PFUZE100_VGENxLPWR BIT(6)
> +#define PFUZE100_VGENxSTBY BIT(5)
> +
> struct pfuze {
> struct device_d *dev;
> struct regmap *map;
> @@ -85,6 +128,46 @@ static int pfuze_i2c_reg_write(void *ctx, unsigned int
> reg, unsigned int val)
> return ret == 1 ? 0 : ret;
> }
>
> +static void pfuze_power_off_prepare(struct poweroff_handler *handler)
> +{
> + dev_info(pfuze_dev->dev, "Configure standy mode for power off");
> +
> + /* Switch from default mode: APS/APS to APS/Off */
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW1ABMODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW1CMODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW2MODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW3AMODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW3BMODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_SW4MODE,
> + PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
> +
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN1VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN2VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN3VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN4VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN5VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> + regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN6VOL,
> + PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
> + PFUZE100_VGENxSTBY);
> +
> + imx6_pm_s
[PATCH v1 3/3] regulator: pfuze: provide power over standby handler
This patch is providing an optional power off handler
which will configure standby state of the PMIC to disable all power lines.
In my power consumption test on RIoTBoard, I got the following results:
power off without this patch: 320 mA
power off with this patch: 2 mA
suspend to ram: 40 mA
Signed-off-by: Oleksij Rempel
---
drivers/regulator/pfuze.c | 87 +++
1 file changed, 87 insertions(+)
diff --git a/drivers/regulator/pfuze.c b/drivers/regulator/pfuze.c
index 2a5fb715ce..94fa03ff15 100644
--- a/drivers/regulator/pfuze.c
+++ b/drivers/regulator/pfuze.c
@@ -26,10 +26,53 @@
#include
+#include
+#include
+
#define DRIVERNAME "pfuze"
#define MC13XXX_NUMREGS0x3f
+#define PFUZE_NUMREGS 128
+#define PFUZE100_VOL_OFFSET0
+#define PFUZE100_STANDBY_OFFSET1
+#define PFUZE100_MODE_OFFSET 3
+#define PFUZE100_CONF_OFFSET 4
+
+#define PFUZE100_DEVICEID 0x0
+#define PFUZE100_REVID 0x3
+#define PFUZE100_FABID 0x4
+
+#define PFUZE100_COINVOL 0x1a
+#define PFUZE100_SW1ABVOL 0x20
+#define PFUZE100_SW1ABMODE 0x23
+#define PFUZE100_SW1CVOL 0x2e
+#define PFUZE100_SW1CMODE 0x31
+#define PFUZE100_SW2VOL0x35
+#define PFUZE100_SW2MODE 0x38
+#define PFUZE100_SW3AVOL 0x3c
+#define PFUZE100_SW3AMODE 0x3f
+#define PFUZE100_SW3BVOL 0x43
+#define PFUZE100_SW3BMODE 0x46
+#define PFUZE100_SW4VOL0x4a
+#define PFUZE100_SW4MODE 0x4d
+#define PFUZE100_SWBSTCON1 0x66
+#define PFUZE100_VREFDDRCON0x6a
+#define PFUZE100_VSNVSVOL 0x6b
+#define PFUZE100_VGEN1VOL 0x6c
+#define PFUZE100_VGEN2VOL 0x6d
+#define PFUZE100_VGEN3VOL 0x6e
+#define PFUZE100_VGEN4VOL 0x6f
+#define PFUZE100_VGEN5VOL 0x70
+#define PFUZE100_VGEN6VOL 0x71
+
+#define PFUZE100_SWxMODE_MASK 0xf
+#define PFUZE100_SWxMODE_APS_APS 0x8
+#define PFUZE100_SWxMODE_APS_OFF 0x4
+
+#define PFUZE100_VGENxLPWR BIT(6)
+#define PFUZE100_VGENxSTBY BIT(5)
+
struct pfuze {
struct device_d *dev;
struct regmap *map;
@@ -85,6 +128,46 @@ static int pfuze_i2c_reg_write(void *ctx, unsigned int reg,
unsigned int val)
return ret == 1 ? 0 : ret;
}
+static void pfuze_power_off_prepare(struct poweroff_handler *handler)
+{
+ dev_info(pfuze_dev->dev, "Configure standy mode for power off");
+
+ /* Switch from default mode: APS/APS to APS/Off */
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW1ABMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW1CMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW2MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW3AMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW3BMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_SW4MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN1VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN2VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN3VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN4VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN5VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_write_bits(pfuze_dev->map, PFUZE100_VGEN6VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+
+ imx6_pm_stby_poweroff();
+}
+
static struct regmap_bus regmap_pfuze_i2c_bus = {
.reg_write = pfuze_i2c_reg_write,
.reg_read = pfuze_i2c_reg_read,
@@ -122,6 +205,10 @@ static int __init pfuze_probe(struct device_d *dev)
if (pfuze_init_callback)
pfuze_init_callback(pfuze_dev->map);
+ if (of_property_read_bool(dev->device_node,
+ "fsl,pmic-stby-poweroff"))
+ return poweroff_handler_register_fn(pfuze_power_off_prepare);
+
return 0;
}
--
2.
[PATCH v1 2/3] ARM: i.MX: provide handler for power off over standby
One of the Freescale recommended sequences for power off with external
PMIC is the following:
...
3. SoC is programming PMIC for power off when standby is asserted.
4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
See:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
page 5083
This patch implements step 4. of this sequence.
Signed-off-by: Oleksij Rempel
---
arch/arm/mach-imx/imx6.c | 49 +++
arch/arm/mach-imx/include/mach/imx6.h | 1 +
2 files changed, 50 insertions(+)
diff --git a/arch/arm/mach-imx/imx6.c b/arch/arm/mach-imx/imx6.c
index 5afbf6b30f..96c1f64093 100644
--- a/arch/arm/mach-imx/imx6.c
+++ b/arch/arm/mach-imx/imx6.c
@@ -25,6 +25,19 @@
#include
#include
+#include
+#include
+#include
+
+#define CLPCR 0x54
+#define BP_CLPCR_LPM(mode) ((mode) & 0x3)
+#define BM_CLPCR_LPM (0x3 << 0)
+#define BM_CLPCR_SBYOS (0x1 << 6)
+#define BM_CLPCR_VSTBY (0x1 << 8)
+#define BP_CLPCR_STBY_COUNT9
+#define BM_CLPCR_COSC_PWRDOWN (0x1 << 11)
+#define BM_CLPCR_BYP_MMDC_CH1_LPM_HS (0x1 << 21)
+
void imx6_init_lowlevel(void)
{
void __iomem *aips1 = (void *)MX6_AIPS1_ON_BASE_ADDR;
@@ -296,3 +309,39 @@ static int imx6_fixup_cpus_register(void)
return of_register_fixup(imx6_fixup_cpus, NULL);
}
device_initcall(imx6_fixup_cpus_register);
+
+void __noreturn imx6_pm_stby_poweroff(void)
+{
+ void *ccm_base = IOMEM(MX6_CCM_BASE_ADDR);
+ void *gpc_base = IOMEM(MX6_GPC_BASE_ADDR);
+ u32 val;
+
+ /*
+* All this is done to get the PMIC_STBY_REQ line high which will
+* cause the PMIC to turn off the i.MX6.
+*/
+
+ /*
+* First mask all interrupts in the GPC. This is necessary for
+* unknown reasons
+*/
+ writel(0x, gpc_base + 0x8);
+ writel(0x, gpc_base + 0xc);
+ writel(0x, gpc_base + 0x10);
+ writel(0x, gpc_base + 0x14);
+
+ val = readl(ccm_base + CLPCR);
+
+ val &= ~BM_CLPCR_LPM;
+ val |= BP_CLPCR_LPM(2);
+ val |= 0x3 << BP_CLPCR_STBY_COUNT;
+ val |= BM_CLPCR_VSTBY;
+ val |= BM_CLPCR_SBYOS;
+ val |= BM_CLPCR_BYP_MMDC_CH1_LPM_HS;
+
+ writel(val, ccm_base + CLPCR);
+
+ asm("wfi");
+
+ while(1);
+}
diff --git a/arch/arm/mach-imx/include/mach/imx6.h
b/arch/arm/mach-imx/include/mach/imx6.h
index 6ad53433cb..e4633ed5f2 100644
--- a/arch/arm/mach-imx/include/mach/imx6.h
+++ b/arch/arm/mach-imx/include/mach/imx6.h
@@ -7,6 +7,7 @@
#include
void imx6_init_lowlevel(void);
+void __noreturn imx6_pm_stby_poweroff(void);
#define IMX6_ANATOP_SI_REV 0x260
#define IMX6SL_ANATOP_SI_REV 0x280
--
2.11.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v1 1/3] ARM: riotboard: provide standby on power off option
This board, as well as some other boards with i.MX6 and a PMIC, uses a
"PMIC_STBY_REQ" line to notify the PMIC about a state change.
The PMIC is programmed for a specific state change before triggering the
line.
In this case, PMIC_STBY_REQ can be used for stand by, sleep
and power off modes.
Signed-off-by: Oleksij Rempel
---
arch/arm/dts/imx6s-riotboard.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/imx6s-riotboard.dts b/arch/arm/dts/imx6s-riotboard.dts
index 575887267e..ddd0d5ba2d 100644
--- a/arch/arm/dts/imx6s-riotboard.dts
+++ b/arch/arm/dts/imx6s-riotboard.dts
@@ -42,3 +42,10 @@
barebox,provide-mac-address = <&fec 0x620>;
};
+&clks {
+ fsl,pmic-stby-poweroff;
+};
+
+&pmic {
+ fsl,pmic-stby-poweroff;
+};
--
2.11.0
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/3] gpio: fix null pointer exception when there is no oftree
Am Mittwoch, den 05.07.2017, 20:33 +0200 schrieb Sam Ravnborg:
> From d10f426e1b8cec7de257dabf59e7fe53a591b3c1 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg
> Date: Mon, 3 Jul 2017 22:07:41 +0200
> Subject: [PATCH 2/3] gpio: fix null pointer exception when there is no oftree
>
> In a system with oftree support enabled but with no oftree the
> of_gpiochip_scan_hogs() would fail due to device_node equals NULL.
>
> Check device_node and return with 0 in this situation, as this
> mirrors what would have happened before we added support for gpio-hogs.
>
> Use IS_ENABLED(CONFIG_OFDEVICE) to teach compiler to leave
> out the of_* specific functions if not needed.
>
> Fixes: 37e6bee7 ("gpiolib: Add support for GPIO "hog" nodes")
> Signed-off-by: Alexander Kurz
> Signed-off-by: Sam Ravnborg
> ---
> drivers/gpio/gpiolib.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a3e17ada0..2bd8ef2a8 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -379,6 +379,9 @@ static int of_gpiochip_scan_hogs(struct gpio_chip *chip)
> struct device_node *np;
> int ret, i;
>
> + if (!chip->dev->device_node)
> + return 0;
> +
> for_each_available_child_of_node(chip->dev->device_node, np) {
> if (!of_property_read_bool(np, "gpio-hog"))
> continue;
> @@ -416,7 +419,10 @@ int gpiochip_add(struct gpio_chip *chip)
> for (i = chip->base; i < chip->base + chip->ngpio; i++)
> gpio_desc[i].chip = chip;
>
> - return of_gpiochip_scan_hogs(chip);
> + if (IS_ENABLED(CONFIG_OFDEVICE))
> + return of_gpiochip_scan_hogs(chip);
> + else
> + return 0;
> }
>
> void gpiochip_remove(struct gpio_chip *chip)
I think this can be simplified to:
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a3e17ada0d39..1a373ef149a5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -379,6 +379,9 @@ static int of_gpiochip_scan_hogs(struct gpio_chip
*chip)
struct device_node *np;
int ret, i;
+ if (!IS_ENABLED(CONFIG_OFDEVICE) || !chip->dev->device_node)
+ return 0;
+
for_each_available_child_of_node(chip->dev->device_node, np) {
if (!of_property_read_bool(np, "gpio-hog"))
continue;
The optimizer should be able to work this out. Can you check that this
works for you? No need to resend, if it works I'll just commit this.
Regards,
Lucas
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v1 00/10] video: tc358767: fixes and improvements
Am Mittwoch, den 05.07.2017, 20:18 +0300 schrieb Andrey Gusakov: > Hi Barebox, > > This set of patches fixes several issues that was found during testing > tc358767 with desktop DisplayPort displays. > > Changes since v0: > - signed-off added > - 'fix AUXDATAn registers access' is broken into two > - ALIGN used > > Andrey Gusakov (10): > video: tc358767: fix EDID read for DP displays > video: tc358767: fix DP0_MISC register set > video: tc358767: fix timing calculation > video: tc358767: fix AUXDATAn registers access during write > video: tc358767: do not fail if sink supports more than 2 lanes > video: tc358767: support newer DPCD revisions and higher data rates > video: tc358767: optimize aux i2c bus checks > video: tc358767: optimize DPCD register write > video: tc358767: filter out modes with too high pixelclock > video: tc358767: accept any hsync and vsync polatiry > > drivers/video/tc358767.c | 229 > --- > 1 file changed, 179 insertions(+), 50 deletions(-) > Applied, thanks. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] ARM: imx: use register defines in imxcfg files instead of plain numbers
Am Donnerstag, den 06.07.2017, 12:11 +0200 schrieb Uwe Kleine-König: > On Thu, Jul 06, 2017 at 10:49:41AM +0200, Lucas Stach wrote: > > Am Mittwoch, den 05.07.2017, 21:23 +0200 schrieb Uwe Kleine-König: > > > This makes the imxcfg files more readable and also makes it possible to > > > share more assignments between machines that just differ by the used > > > SoC. (Though I have to admit that in the cases converted here it just > > > more easily allows to see that the RAM config differs more than probably > > > necessary.) > > > > > > This change is intended to have no effect on the built artifacts. > > > > Does the "intended" in the above sentence mean you didn't validate that > > the the generated flash headers are equal before and after the change in > > any way? As much as I like the patch otherwise, this sounds scary. > > I verified it for some of them. I created a .config that enables all > affected machine, but not for all of them a corresponding .dcd was > generated. The one that existed then however didn't change with my > patch. > > $ grep HIPER .config > CONFIG_MACH_ELTEC_HIPERCAM=y > > $ armmake > ... > > $ find -name \*.dcd | sort > ./arch/arm/boards/cm-fx6/flash-header-mx6-cm-fx6.dcd > ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-micron.dcd > ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-nanya.dcd > ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6s.dcd > ./arch/arm/boards/embedsky-e9/flash-header-e9.dcd > ./arch/arm/boards/embest-riotboard/flash-header-embest-riotboard.dcd > ./arch/arm/boards/freescale-mx6-sabrelite/flash-header-mx6-sabrelite.dcd > ./arch/arm/boards/freescale-mx6-sabresd/flash-header-mx6-sabresd.dcd > ./arch/arm/boards/gk802/flash-header.dcd > > ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-256.dcd > > ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-512.dcd > > ./arch/arm/boards/technexion-wandboard/flash-header-technexion-wandboard.dcd > ./arch/arm/boards/tqma6x/flash-header-tqma6dl.dcd > ./arch/arm/boards/tqma6x/flash-header-tqma6q.dcd > ./arch/arm/boards/udoo/flash-header-mx6-udoo.dcd > ./arch/arm/boards/variscite-mx6/flash-header-variscite.dcd Those aren't used anymore and are just the result of missing janitorial work to the board Makefiles. > > missing (and so unchecked) are: > > flash-header-eltec-hipercam.imxcfg > karo-tx6x/* What you need to look for is something like "arch/arm/boards/tqma6x/.flash-header-tqma6q.dcd.dcd.tmp" which is generated from the dependencies in images/Makefile.imx Regards, Lucas ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] ARM: imx: use register defines in imxcfg files instead of plain numbers
On Thu, Jul 06, 2017 at 10:49:41AM +0200, Lucas Stach wrote: > Am Mittwoch, den 05.07.2017, 21:23 +0200 schrieb Uwe Kleine-König: > > This makes the imxcfg files more readable and also makes it possible to > > share more assignments between machines that just differ by the used > > SoC. (Though I have to admit that in the cases converted here it just > > more easily allows to see that the RAM config differs more than probably > > necessary.) > > > > This change is intended to have no effect on the built artifacts. > > Does the "intended" in the above sentence mean you didn't validate that > the the generated flash headers are equal before and after the change in > any way? As much as I like the patch otherwise, this sounds scary. I verified it for some of them. I created a .config that enables all affected machine, but not for all of them a corresponding .dcd was generated. The one that existed then however didn't change with my patch. $ grep HIPER .config CONFIG_MACH_ELTEC_HIPERCAM=y $ armmake ... $ find -name \*.dcd | sort ./arch/arm/boards/cm-fx6/flash-header-mx6-cm-fx6.dcd ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-micron.dcd ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6q-nanya.dcd ./arch/arm/boards/dfi-fs700-m60/flash-header-fs700-m60-6s.dcd ./arch/arm/boards/embedsky-e9/flash-header-e9.dcd ./arch/arm/boards/embest-riotboard/flash-header-embest-riotboard.dcd ./arch/arm/boards/freescale-mx6-sabrelite/flash-header-mx6-sabrelite.dcd ./arch/arm/boards/freescale-mx6-sabresd/flash-header-mx6-sabresd.dcd ./arch/arm/boards/gk802/flash-header.dcd ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-256.dcd ./arch/arm/boards/technexion-pico-hobbit/flash-header-imx6ul-pico-hobbit-512.dcd ./arch/arm/boards/technexion-wandboard/flash-header-technexion-wandboard.dcd ./arch/arm/boards/tqma6x/flash-header-tqma6dl.dcd ./arch/arm/boards/tqma6x/flash-header-tqma6q.dcd ./arch/arm/boards/udoo/flash-header-mx6-udoo.dcd ./arch/arm/boards/variscite-mx6/flash-header-variscite.dcd missing (and so unchecked) are: flash-header-eltec-hipercam.imxcfg karo-tx6x/* phytec-som-imx6/* zii-imx6q-rdu2/* even though: $ grep -E 'HIPER|TX6|_SOM|RDU2' .config CONFIG_MACH_PHYTEC_SOM_IMX6=y CONFIG_MACH_ELTEC_HIPERCAM=y CONFIG_MACH_TX6X=y CONFIG_MACH_ZII_RDU2=y Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/8] common: efi: do not use undefined kconfig option
On Wed, Jul 05, 2017 at 01:05:25PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 05.07.2017, 12:56 +0200 schrieb Steffen Trumtrar:
> > Signed-off-by: Steffen Trumtrar
> > ---
> > common/efi/efi.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/common/efi/efi.c b/common/efi/efi.c
> > index 05c58250f4a7..f924385958e1 100644
> > --- a/common/efi/efi.c
> > +++ b/common/efi/efi.c
> > @@ -266,8 +266,7 @@ static int efi_console_init(void)
> >
> > add_generic_device("efi-stdio", DEVICE_ID_SINGLE, NULL, 0 , 0, 0, NULL);
> >
> > - if (IS_ENABLED(CONFIG_ARCH_EFI_REGISTER_COM1))
>
> It seems we lost this option when moving arch/efi to arch/x86. As
> unconditionally enabling the serial console may break some boards, the
> proper fix should be to bring back the Kconfig option.
I think that option is pretty much redundant. This is x86. There is no
device tree to enable devices.
There are only two possible scenarios: use ns16550 or not. Building the
driver and maybe use it does not exist. And we can use
CONFIG_DRIVER_SERIAL_NS16550 to choose.
Somewhat unrelated: I think this driver should be avoided if possible. I'm
quite certain, that the original use-case for this was a bug in barebox and
not a broken EFI serial driver.
Michael
> > - add_ns16550_device(0, 0x3f8, 0x10, IORESOURCE_IO |
> > IORESOURCE_MEM_8BIT,
> > + add_ns16550_device(0, 0x3f8, 0x10, IORESOURCE_IO | IORESOURCE_MEM_8BIT,
> > &ns16550_plat);
> >
> > return 0;
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
