| Message ID | 1328032330-20883-1-git-send-email-eric.nelson@boundarydevices.com |
|---|---|
| State | Accepted |
| Commit | 4b3a30e9ae304f1350d7dc17b3e0d2ef90e2b668 |
| Delegated to: | Stefano Babic |
| Headers | show |
Patch 1 modifies the 'sf' command to allow a default bus and chip-select
to be specified by board headers. This allows a bare 'sf' probe command:
U-Boot> sf probe
instead of the more cumbersome usage when a GPIO is tacked onto
the chip-select. Otherwise, this command-line would be needed
to specify GP3:19 on SabreLite:
U-Boot> sf probe 0x5300
Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF.
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: > Patch 1 modifies the 'sf' command to allow a default bus and chip-select > to be specified by board headers. This allows a bare 'sf' probe command: > U-Boot> sf probe > instead of the more cumbersome usage when a GPIO is tacked onto > the chip-select. Otherwise, this command-line would be needed > to specify GP3:19 on SabreLite: > U-Boot> sf probe 0x5300 > > Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF. you can drop these two SF patches from your mx6q series. i don't want to keep checking to see if you've updated them :p. -mike
On 01/31/2012 11:11 AM, Mike Frysinger wrote: > On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: >> Patch 1 modifies the 'sf' command to allow a default bus and chip-select >> to be specified by board headers. This allows a bare 'sf' probe command: >> U-Boot> sf probe >> instead of the more cumbersome usage when a GPIO is tacked onto >> the chip-select. Otherwise, this command-line would be needed >> to specify GP3:19 on SabreLite: >> U-Boot> sf probe 0x5300 >> >> Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF. > > you can drop these two SF patches from your mx6q series. i don't want to keep > checking to see if you've updated them :p. > -mike I figured as much, but I can't really test them without the rest of the series...
On 31/01/2012 20:14, Eric Nelson wrote: > On 01/31/2012 11:11 AM, Mike Frysinger wrote: >> On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: >>> Patch 1 modifies the 'sf' command to allow a default bus and chip-select >>> to be specified by board headers. This allows a bare 'sf' probe command: >>> U-Boot> sf probe >>> instead of the more cumbersome usage when a GPIO is tacked onto >>> the chip-select. Otherwise, this command-line would be needed >>> to specify GP3:19 on SabreLite: >>> U-Boot> sf probe 0x5300 >>> >>> Patch 2 provides a description of usage and configuration of >>> CONFIG_CMD_SF. >> >> you can drop these two SF patches from your mx6q series. i don't want >> to keep >> checking to see if you've updated them :p. >> -mike > > I figured as much, but I can't really test them without the rest of the > series... It does not matter - Mike, what do you think if I merge the whole patchset into u-boot-imx ? Else the mx6qsabrelite board cannot be built until all patches will be merged by Wolfgang. Stefano
On 01.02.2012 12:30, Stefano Babic wrote: > On 31/01/2012 20:14, Eric Nelson wrote: >> On 01/31/2012 11:11 AM, Mike Frysinger wrote: >>> On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: >>>> Patch 1 modifies the 'sf' command to allow a default bus and chip-select >>>> to be specified by board headers. This allows a bare 'sf' probe command: >>>> U-Boot> sf probe >>>> instead of the more cumbersome usage when a GPIO is tacked onto >>>> the chip-select. Otherwise, this command-line would be needed >>>> to specify GP3:19 on SabreLite: >>>> U-Boot> sf probe 0x5300 >>>> >>>> Patch 2 provides a description of usage and configuration of >>>> CONFIG_CMD_SF. >>> you can drop these two SF patches from your mx6q series. i don't want >>> to keep >>> checking to see if you've updated them :p. >>> -mike >> I figured as much, but I can't really test them without the rest of the >> series... > > It does not matter - Mike, what do you think if I merge the whole > patchset into u-boot-imx ? Else the mx6qsabrelite board cannot be built > until all patches will be merged by Wolfgang. +1 Thanks Dirk
On Wednesday 01 February 2012 06:30:04 Stefano Babic wrote: > On 31/01/2012 20:14, Eric Nelson wrote: > > On 01/31/2012 11:11 AM, Mike Frysinger wrote: > >> On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: > >>> Patch 1 modifies the 'sf' command to allow a default bus and > >>> chip-select > >>> > >>> to be specified by board headers. This allows a bare 'sf' probe command: > >>> U-Boot> sf probe > >>> > >>> instead of the more cumbersome usage when a GPIO is tacked onto > >>> the chip-select. Otherwise, this command-line would be needed > >>> > >>> to specify GP3:19 on SabreLite: > >>> U-Boot> sf probe 0x5300 > >>> > >>> Patch 2 provides a description of usage and configuration of > >>> CONFIG_CMD_SF. > >> > >> you can drop these two SF patches from your mx6q series. i don't want > >> to keep > >> checking to see if you've updated them :p. > > > > I figured as much, but I can't really test them without the rest of the > > series... > > It does not matter - Mike, what do you think if I merge the whole > patchset into u-boot-imx ? Else the mx6qsabrelite board cannot be built > until all patches will be merged by Wolfgang. i don't see why this series depends on the two spi flash patches. they were both "nice to have" patches which only change the default `sf` behavior. the boards will compile & run perfectly fine without them. -mike
On 02/01/2012 10:00 AM, Mike Frysinger wrote: > On Wednesday 01 February 2012 06:30:04 Stefano Babic wrote: >> On 31/01/2012 20:14, Eric Nelson wrote: >>> On 01/31/2012 11:11 AM, Mike Frysinger wrote: >>>> On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: >>>>> Patch 1 modifies the 'sf' command to allow a default bus and >>>>> chip-select >>>>> >>>>> to be specified by board headers. This allows a bare 'sf' probe command: >>>>> U-Boot> sf probe >>>>> >>>>> instead of the more cumbersome usage when a GPIO is tacked onto >>>>> the chip-select. Otherwise, this command-line would be needed >>>>> >>>>> to specify GP3:19 on SabreLite: >>>>> U-Boot> sf probe 0x5300 >>>>> >>>>> Patch 2 provides a description of usage and configuration of >>>>> CONFIG_CMD_SF. >>>> >>>> you can drop these two SF patches from your mx6q series. i don't want >>>> to keep >>>> checking to see if you've updated them :p. >>> >>> I figured as much, but I can't really test them without the rest of the >>> series... >> >> It does not matter - Mike, what do you think if I merge the whole >> patchset into u-boot-imx ? Else the mx6qsabrelite board cannot be built >> until all patches will be merged by Wolfgang. > > i don't see why this series depends on the two spi flash patches. they were > both "nice to have" patches which only change the default `sf` behavior. the > boards will compile& run perfectly fine without them. > -mike Hi Mike, My comment was the inverse: I can't test just the 'sf probe' updates unless I have the core SPI flash support for mx6qsabrelite. AFAIK, the update to cmd_sf doesn't have any dependencies and of course the README update doesn't.
On Wednesday 01 February 2012 14:31:39 Eric Nelson wrote: > On 02/01/2012 10:00 AM, Mike Frysinger wrote: > > On Wednesday 01 February 2012 06:30:04 Stefano Babic wrote: > >> On 31/01/2012 20:14, Eric Nelson wrote: > >>> On 01/31/2012 11:11 AM, Mike Frysinger wrote: > >>>> On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: > >>>>> Patch 1 modifies the 'sf' command to allow a default bus and > >>>>> chip-select > >>>>> > >>>>> Patch 2 provides a description of usage and configuration of > >>>>> CONFIG_CMD_SF. > >>>> > >>>> you can drop these two SF patches from your mx6q series. i don't want > >>>> to keep checking to see if you've updated them :p. > >>> > >>> I figured as much, but I can't really test them without the rest of the > >>> series... > >> > >> It does not matter - Mike, what do you think if I merge the whole > >> patchset into u-boot-imx ? Else the mx6qsabrelite board cannot be built > >> until all patches will be merged by Wolfgang. > > > > i don't see why this series depends on the two spi flash patches. they > > were both "nice to have" patches which only change the default `sf` > > behavior. the boards will compile& run perfectly fine without them. > > My comment was the inverse: I can't test just the 'sf probe' updates unless > I have the core SPI flash support for mx6qsabrelite. > > AFAIK, the update to cmd_sf doesn't have any dependencies and of course the > README update doesn't. i don't see any dependencies in either direction. i can push the sf updates before or after your board patchset. in either case, the build will produce a u-boot that's just as usable. -mike
On 01/02/2012 20:31, Eric Nelson wrote: > Hi Mike, > > My comment was the inverse: I can't test just the 'sf probe' updates > unless I > have the core SPI flash support for mx6qsabrelite. > > AFAIK, the update to cmd_sf doesn't have any dependencies and of course > the README update doesn't. Then I think the best way is to proceed is as suggested by Mike - the patches are orthogonal, and they can applied to different trees - and merged together at the end by Wolfgang. Stefano
On 02/02/2012 02:18 AM, Stefano Babic wrote: > On 01/02/2012 20:31, Eric Nelson wrote: > >> Hi Mike, >> >> My comment was the inverse: I can't test just the 'sf probe' updates >> unless I >> have the core SPI flash support for mx6qsabrelite. >> >> AFAIK, the update to cmd_sf doesn't have any dependencies and of course >> the README update doesn't. > > Then I think the best way is to proceed is as suggested by Mike - the > patches are orthogonal, and they can applied to different trees - and > merged together at the end by Wolfgang. > > Stefano > Okay. I'll leave the process stuff in your capable hands. Mine is just to code... (or so I like to think)
On Thursday 02 February 2012 04:18:45 Stefano Babic wrote: > On 01/02/2012 20:31, Eric Nelson wrote: > > My comment was the inverse: I can't test just the 'sf probe' updates > > unless I have the core SPI flash support for mx6qsabrelite. > > > > AFAIK, the update to cmd_sf doesn't have any dependencies and of course > > the README update doesn't. > > Then I think the best way is to proceed is as suggested by Mike - the > patches are orthogonal, and they can applied to different trees - and > merged together at the end by Wolfgang. to be clear, i'm not trying to "hoard" patches or anything ... i just can't see there being a hard requirement here between the two sets. if people *really* want to merge patches for me, i don't mind ;). -mike
On 02/02/2012 17:32, Mike Frysinger wrote: > to be clear, i'm not trying to "hoard" patches or anything ... Do not worry, I have never thought this... ;-) > i just can't see there being a hard requirement here between the > two sets. Agree, and the patches should be merged by the maintainer responsible for the changes, as general rule - or IMHO as exception by a single maintainer if the patches break some boards. But agree we should stick with the general rule when there is no issues, as in this case. Stefano
On 31/01/2012 18:52, Eric Nelson wrote: > The interface to the mxc_gpio driver uses integer (ordinal) values to > refer to all GPIOs on the i.MX processors. The registers themselves > and much of the i.MX documentation are banked in groups of 32, and these > macros allow the use of the port:index numbering for clarity. > > GPIO_NUMBER() converts to ordinal value from port:index > GPIO_PORT() returns the port of an ordinal value > GPIO_INDEX() returns the index or offset of the ordinal. > > Discussion on the mailing list at > http://lists.denx.de/pipermail/u-boot/2012-January/116927.html > > Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> > --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic
On 31.01.2012 19:11, Mike Frysinger wrote: > On Tuesday 31 January 2012 12:52:06 Eric Nelson wrote: >> Patch 1 modifies the 'sf' command to allow a default bus and chip-select >> to be specified by board headers. This allows a bare 'sf' probe command: >> U-Boot> sf probe >> instead of the more cumbersome usage when a GPIO is tacked onto >> the chip-select. Otherwise, this command-line would be needed >> to specify GP3:19 on SabreLite: >> U-Boot> sf probe 0x5300 >> >> Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF. > > you can drop these two SF patches from your mx6q series. i don't want to keep > checking to see if you've updated them :p. Now that part 1, 2, 4 and 5 are merged by Stefano to u-boot-imx.git, could we get the two part 3 patches merged, too? Many thanks and best regards Dirk
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h b/arch/arm/include/asm/arch-mx6/imx-regs.h index 5227b44..8a9eeb4 100644 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h @@ -164,6 +164,10 @@ #define IRAM_SIZE 0x00040000 #define IMX_IIM_BASE OCOTP_BASE_ADDR +#define GPIO_NUMBER(port, index) ((((port)-1)*32)+((index)&31)) +#define GPIO_TO_PORT(number) (((number)/32)+1) +#define GPIO_TO_INDEX(number) ((number)&31) + #if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__)) #include <asm/types.h>
The interface to the mxc_gpio driver uses integer (ordinal) values to refer to all GPIOs on the i.MX processors. The registers themselves and much of the i.MX documentation are banked in groups of 32, and these macros allow the use of the port:index numbering for clarity. GPIO_NUMBER() converts to ordinal value from port:index GPIO_PORT() returns the port of an ordinal value GPIO_INDEX() returns the index or offset of the ordinal. Discussion on the mailing list at http://lists.denx.de/pipermail/u-boot/2012-January/116927.html Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> --- arch/arm/include/asm/arch-mx6/imx-regs.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)