From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wg0-f49.google.com ([74.125.82.49]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TM31d-00010q-Q2 for barebox@lists.infradead.org; Wed, 10 Oct 2012 20:37:07 +0000 Received: by mail-wg0-f49.google.com with SMTP id gg4so551369wgb.18 for ; Wed, 10 Oct 2012 13:37:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carlo Caione In-Reply-To: <20121009113142.GD26553@game.jcrosoft.org> Date: Wed, 10 Oct 2012 22:36:59 +0200 Message-Id: <19A97966-0AF1-4D37-BC6F-CA6D47F59B50@gmail.com> References: <1349734061-32339-1-git-send-email-carlo.caione@gmail.com> <1349734061-32339-6-git-send-email-carlo.caione@gmail.com> <20121009113142.GD26553@game.jcrosoft.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635057970399778205==" Sender: barebox-bounces@lists.infradead.org Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: [PATCH 5/5] Add support for GPIO (BCM2835/Raspberry-Pi) To: Jean-Christophe PLAGNIOL-VILLARD Cc: barebox@lists.infradead.org --===============0635057970399778205== Content-Type: multipart/alternative; boundary="Apple-Mail=_95BC2904-7E51-4323-9618-9050CE27EBD6" --Apple-Mail=_95BC2904-7E51-4323-9618-9050CE27EBD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 9, 2012, at 1:31 PM, Jean-Christophe PLAGNIOL-VILLARD = wrote: [cut] >>=20 >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define GPIOFSEL(x) (0x00+(x)*4) >> +#define GPIOSET(x) (0x1c+(x)*4) >> +#define GPIOCLR(x) (0x28+(x)*4) >> +#define GPIOLEV(x) (0x34+(x)*4) >> +#define GPIOEDS(x) (0x40+(x)*4) >> +#define GPIOREN(x) (0x4c+(x)*4) >> +#define GPIOFEN(x) (0x58+(x)*4) >> +#define GPIOHEN(x) (0x64+(x)*4) >> +#define GPIOLEN(x) (0x70+(x)*4) >> +#define GPIOAREN(x) (0x7c+(x)*4) >> +#define GPIOAFEN(x) (0x88+(x)*4) >> +#define GPIOUD(x) (0x94+(x)*4) >> +#define GPIOUDCLK(x) (0x98+(x)*4) >=20 >> + >> +enum { >> + GPIO_FSEL_INPUT, GPIO_FSEL_OUTPUT, >> + GPIO_FSEL_ALT5, GPIO_FSEL_ALT_4, >> + GPIO_FSEL_ALT0, GPIO_FSEL_ALT1, >> + GPIO_FSEL_ALT2, GPIO_FSEL_ALT3, >> +}; >> + >> +struct bcm2835_gpio_chip { >> + void __iomem *base; >> + struct gpio_chip chip; >> +}; >> + >> +static int bcm2835_set_function(struct gpio_chip *chip, unsigned = gpio, int function) >> +{ > you should add one bank pre gpio_chip=20 >> + struct bcm2835_gpio_chip *bcmgpio =3D container_of(chip, struct = bcm2835_gpio_chip, chip); >> + void __iomem *base =3D bcmgpio->base; >> + unsigned gpiodir; >> + unsigned gpio_bank =3D gpio / 10; >> + unsigned gpio_field_offset =3D (gpio - 10 * gpio_bank) * 3; > so this will be dropped >> + >> + gpiodir =3D readl(base + GPIOFSEL(gpio_bank)); >> + gpiodir &=3D ~(7 << gpio_field_offset); >> + gpiodir |=3D function << gpio_field_offset; >> + writel(gpiodir, base + GPIOFSEL(gpio_bank)); >> + gpiodir =3D readl(base + GPIOFSEL(gpio_bank)); >> + >> + return 0; >> +} >> + Uhm, this could be not convenient since the two banks in BCM2835 are not = really separated, there are not exclusive registers for one bank or for = the other. The registers used for GPIOs configuration manage both the = two banks (see for example GPFSELx). If I add one bank I can avoid calculating the bank offset for GPCLRx and = GPSETx but not for GPFSELx and viceversa (in fact in the code I select = the bank for GPCLRx and GPSETx with gpio_bank =3D gpio / 32 whereas for = GPIOFSEL with gpio_bank =3D gpio / 10). Yay, confusing =85 Best, -- Carlo Caione= --Apple-Mail=_95BC2904-7E51-4323-9618-9050CE27EBD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 plagnioj@jcrosoft.com> = wrote:[cut

+
+#include <common.h>
+#include = <errno.h>
+#include <malloc.h>
+#include = <io.h>
+#include <gpio.h>
+#include = <init.h>
+#include <mach/platform.h>
+
+#define = GPIOFSEL(x) (0x00+(x)*4)
+#define GPIOSET(x) =   (0x1c+(x)*4)
+#define GPIOCLR(x) =   (0x28+(x)*4)
+#define GPIOLEV(x) =   (0x34+(x)*4)
+#define GPIOEDS(x) =   (0x40+(x)*4)
+#define GPIOREN(x) =   (0x4c+(x)*4)
+#define GPIOFEN(x) =   (0x58+(x)*4)
+#define GPIOHEN(x) =   (0x64+(x)*4)
+#define GPIOLEN(x) =   (0x70+(x)*4)
+#define GPIOAREN(x) = (0x7c+(x)*4)
+#define GPIOAFEN(x) = (0x88+(x)*4)
+#define GPIOUD(x) =    (0x94+(x)*4)
+#define GPIOUDCLK(x) = (0x98+(x)*4)

+
+enum = {
+ = GPIO_FSEL_INPUT, GPIO_FSEL_OUTPUT,
+ = GPIO_FSEL_ALT5, GPIO_FSEL_ALT_4,
+ GPIO_FSEL_ALT0, = GPIO_FSEL_ALT1,
+ GPIO_FSEL_ALT2, = GPIO_FSEL_ALT3,
+};
+
+struct bcm2835_gpio_chip {
+ void = __iomem *base;
+ struct gpio_chip = chip;
+};
+
+static int bcm2835_set_function(struct gpio_chip = *chip, unsigned gpio, int function)
+{
you should add = one bank pre gpio_chip
+ struct = bcm2835_gpio_chip *bcmgpio =3D container_of(chip, struct = bcm2835_gpio_chip, chip);
+ void __iomem *base =3D = bcmgpio->base;
+ unsigned gpiodir;
+ unsigned = gpio_bank =3D gpio / 10;
+ unsigned gpio_field_offset =3D = (gpio - 10 * gpio_bank) * 3;
so this will be = dropped
+
+ gpiodir =3D readl(base + = GPIOFSEL(gpio_bank));
+ gpiodir &=3D ~(7 << = gpio_field_offset);
+ gpiodir |=3D function << = gpio_field_offset;
+ writel(gpiodir, base + = GPIOFSEL(gpio_bank));
+ gpiodir =3D readl(base + = GPIOFSEL(gpio_bank));
+
+ return = 0;
+}
+

Uhm, this = could be not convenient since the two banks in BCM2835 are not really = separated, there are not exclusive registers for one bank = or for the other. The registers used for GPIOs configuration manage both = the two banks (see for example GPFSELx).

If I add one bank I = can avoid calculating the bank offset for GPCLRx and GPSETx but not for = GPFSELx and viceversa (in fact in the code I select the bank for GPCLRx = and GPSETx with gpio_bank =3D gpio / 32 whereas for GPIOFSEL = with gpio_bank =3D gpio / 10). Yay, confusing = =85

Best,

C= arlo Caione

= --Apple-Mail=_95BC2904-7E51-4323-9618-9050CE27EBD6-- --===============0635057970399778205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox --===============0635057970399778205==--