| Message ID | 1411545673-5591-11-git-send-email-wens@csie.org |
|---|---|
| State | Superseded |
| Headers | show |
On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > The Colombus board is an A31 evaluation board from WITS Technology. > > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > --- > configs/Colombus_defconfig | 4 ++++ > 1 file changed, 4 insertions(+) > create mode 100644 configs/Colombus_defconfig > > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > new file mode 100644 > index 0000000..16800de > --- /dev/null > +++ b/configs/Colombus_defconfig > @@ -0,0 +1,4 @@ > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" Does this do anything other than define an unused #define? Ah, I suppose eventually it will cause the inclusion of a suitable dram file. Really ought to start moving things out of SYS_EXTRA though, but I don't think you need to shave that yakk just to get this patch in, so: Acked-by: Ian Campbell <ijc@hellion.org.uk>
On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > > The Colombus board is an A31 evaluation board from WITS Technology. > > > > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > > > --- > > configs/Colombus_defconfig | 4 ++++ > > 1 file changed, 4 insertions(+) > > create mode 100644 configs/Colombus_defconfig > > > > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > > new file mode 100644 > > index 0000000..16800de > > --- /dev/null > > +++ b/configs/Colombus_defconfig > > @@ -0,0 +1,4 @@ > > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > > Does this do anything other than define an unused #define? > > Ah, I suppose eventually it will cause the inclusion of a suitable dram > file. Really ought to start moving things out of SYS_EXTRA though, but I > don't think you need to shave that yakk just to get this patch in, so: > > Acked-by: Ian Campbell <ijc@hellion.org.uk> Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. I think there is no need to resend the whole series, just this one patch. With this minor tweak I think it's time add this to u-boot-sunxi#next. Ian.
On Sun, Sep 28, 2014 at 11:33 PM, Ian Campbell <ijc@hellion.org.uk> wrote: > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: >> > The Colombus board is an A31 evaluation board from WITS Technology. >> > >> > Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> >> > --- >> > configs/Colombus_defconfig | 4 ++++ >> > 1 file changed, 4 insertions(+) >> > create mode 100644 configs/Colombus_defconfig >> > >> > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig >> > new file mode 100644 >> > index 0000000..16800de >> > --- /dev/null >> > +++ b/configs/Colombus_defconfig >> > @@ -0,0 +1,4 @@ >> > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" >> >> Does this do anything other than define an unused #define? >> >> Ah, I suppose eventually it will cause the inclusion of a suitable dram >> file. Really ought to start moving things out of SYS_EXTRA though, but I >> don't think you need to shave that yakk just to get this patch in, so: >> >> Acked-by: Ian Campbell <ijc@hellion.org.uk> > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > I think there is no need to resend the whole series, just this one > patch. With this minor tweak I think it's time add this to > u-boot-sunxi#next. Actually I don't have this board. I think Maxime has one. Not sure if anyone else does. It was kind of a placeholder for all A31 boards. I suppose you could just drop this patch. I can send another one for the A31 Hummingbird, which I do have and can maintain. ChenYu
Hi Ian, On 09/28/2014 05:33 PM, Ian Campbell wrote: > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: >>> The Colombus board is an A31 evaluation board from WITS Technology. >>> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> >>> --- >>> configs/Colombus_defconfig | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> create mode 100644 configs/Colombus_defconfig >>> >>> diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig >>> new file mode 100644 >>> index 0000000..16800de >>> --- /dev/null >>> +++ b/configs/Colombus_defconfig >>> @@ -0,0 +1,4 @@ >>> +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" >> >> Does this do anything other than define an unused #define? >> >> Ah, I suppose eventually it will cause the inclusion of a suitable dram >> file. Really ought to start moving things out of SYS_EXTRA though, but I >> don't think you need to shave that yakk just to get this patch in, so: >> >> Acked-by: Ian Campbell <ijc@hellion.org.uk> > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > I think there is no need to resend the whole series, just this one > patch. With this minor tweak I think it's time add this to > u-boot-sunxi#next. Before you do that, note that I've just added 2 patches there, which I would like to get into v2014.10. Specifically I'm hoping that I can get some positive testing feedback on the bananapi gmac patch I've send (off-list), and I believe we really should try to get the bananapi fix into v2014.10, and if we're going todo a pull-req for v2014.10, we might as well include the 2 patches I've just added to next. Do you agree ? Still feel free to merge the sun6i series into next, I can just cherry pick the 3 patches in question directly into master when I'm ready to send the pull-req. Regards, Hans
On Sun, 2014-09-28 at 23:37 +0800, Chen-Yu Tsai wrote: > On Sun, Sep 28, 2014 at 11:33 PM, Ian Campbell <ijc@hellion.org.uk> wrote: > > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > >> > The Colombus board is an A31 evaluation board from WITS Technology. > >> > > >> > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > >> > >> > --- > >> > configs/Colombus_defconfig | 4 ++++ > >> > 1 file changed, 4 insertions(+) > >> > create mode 100644 configs/Colombus_defconfig > >> > > >> > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > >> > new file mode 100644 > >> > index 0000000..16800de > >> > --- /dev/null > >> > +++ b/configs/Colombus_defconfig > >> > @@ -0,0 +1,4 @@ > >> > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > >> > >> Does this do anything other than define an unused #define? > >> > >> Ah, I suppose eventually it will cause the inclusion of a suitable dram > >> file. Really ought to start moving things out of SYS_EXTRA though, but I > >> don't think you need to shave that yakk just to get this patch in, so: > >> > >> Acked-by: Ian Campbell <ijc@hellion.org.uk> > > > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > > > I think there is no need to resend the whole series, just this one > > patch. With this minor tweak I think it's time add this to > > u-boot-sunxi#next. > > Actually I don't have this board. I think Maxime has one. Not sure > if anyone else does. It was kind of a placeholder for all A31 boards. > > I suppose you could just drop this patch. I can send another one > for the A31 Hummingbird, which I do have and can maintain. Unless Maxime agrees to having his name in the MAINTAINERS file I think that would be best, actually if he does agree I see no reason not to have both ;-) Ian.
On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: > Hi Ian, > > On 09/28/2014 05:33 PM, Ian Campbell wrote: > > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > >>> The Colombus board is an A31 evaluation board from WITS Technology. > >>> > >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> > >> > >>> --- > >>> configs/Colombus_defconfig | 4 ++++ > >>> 1 file changed, 4 insertions(+) > >>> create mode 100644 configs/Colombus_defconfig > >>> > >>> diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > >>> new file mode 100644 > >>> index 0000000..16800de > >>> --- /dev/null > >>> +++ b/configs/Colombus_defconfig > >>> @@ -0,0 +1,4 @@ > >>> +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > >> > >> Does this do anything other than define an unused #define? > >> > >> Ah, I suppose eventually it will cause the inclusion of a suitable dram > >> file. Really ought to start moving things out of SYS_EXTRA though, but I > >> don't think you need to shave that yakk just to get this patch in, so: > >> > >> Acked-by: Ian Campbell <ijc@hellion.org.uk> > > > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > > > I think there is no need to resend the whole series, just this one > > patch. With this minor tweak I think it's time add this to > > u-boot-sunxi#next. > > Before you do that, note that I've just added 2 patches there, which I would > like to get into v2014.10. Specifically I'm hoping that I can get some > positive testing feedback on the bananapi gmac patch I've send (off-list), > and I believe we really should try to get the bananapi fix into v2014.10, > and if we're going todo a pull-req for v2014.10, we might as well include > the 2 patches I've just added to next. Do you agree ? You mean these two? sun7i: Add support for Olimex A20-OLinuXino-LIME2 mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i The latter seems like a feature to me, or at least the changelog doesn't give any rationale why it should go in now rather than waiting for the next merge window (i.e. why it's a bugfix, what the upside is to justify its inclusion now). How much testing has it had and what are the potential downsides? WRT the new board (and new boards generally), I'm in two minds. On the one hand they are pretty low risk (can't regress anything else, at least not in this case), on the other we are 6 weeks past the close of the merge window and 2 from the release date, so we are pretty far along. Where do we draw the line? The gmac fix is a clear bug fix and once it is properly posted publicly I will ack and then I agree it should go in. > Still feel free to merge the sun6i series into next, I can just cherry pick > the 3 patches in question directly into master when I'm ready to send the > pull-req. Ack, that's what I expected to happen. Ian.
On Sun, Sep 28, 2014 at 04:43:30PM +0100, Ian Campbell wrote: > > Actually I don't have this board. I think Maxime has one. Not sure > > if anyone else does. It was kind of a placeholder for all A31 boards. > > > > I suppose you could just drop this patch. I can send another one > > for the A31 Hummingbird, which I do have and can maintain. > > Unless Maxime agrees to having his name in the MAINTAINERS file I think > that would be best, actually if he does agree I see no reason not to > have both ;-) That's something I could live with :) Maxime
On 28/09/14 17:20, Ian Campbell wrote: > You mean these two? > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i > > The latter seems like a feature to me, or at least the changelog doesn't > give any rationale why it should go in now rather than waiting for the > next merge window (i.e. why it's a bugfix, what the upside is to justify > its inclusion now). How much testing has it had and what are the > potential downsides? > > WRT the new board (and new boards generally), I'm in two minds. On the > one hand they are pretty low risk (can't regress anything else, at least > not in this case), on the other we are 6 weeks past the close of the > merge window and 2 from the release date, so we are pretty far along. > Where do we draw the line? FWIW, the Lime2 is very new, I had no expectations it would make it into 2014.10 - although I'd not complain if it does! Seems unlikely the dts will make it into 3.17 either, so there's probably no rush. Anyone needing either can pick up the patches themselves until next release.
Hi, On 09/28/2014 06:20 PM, Ian Campbell wrote: > On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: >> Hi Ian, >> >> On 09/28/2014 05:33 PM, Ian Campbell wrote: >>> On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: >>>> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: >>>>> The Colombus board is an A31 evaluation board from WITS Technology. >>>>> >>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >>>> >>>>> --- >>>>> configs/Colombus_defconfig | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> create mode 100644 configs/Colombus_defconfig >>>>> >>>>> diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig >>>>> new file mode 100644 >>>>> index 0000000..16800de >>>>> --- /dev/null >>>>> +++ b/configs/Colombus_defconfig >>>>> @@ -0,0 +1,4 @@ >>>>> +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" >>>> >>>> Does this do anything other than define an unused #define? >>>> >>>> Ah, I suppose eventually it will cause the inclusion of a suitable dram >>>> file. Really ought to start moving things out of SYS_EXTRA though, but I >>>> don't think you need to shave that yakk just to get this patch in, so: >>>> >>>> Acked-by: Ian Campbell <ijc@hellion.org.uk> >>> >>> Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. >>> >>> I think there is no need to resend the whole series, just this one >>> patch. With this minor tweak I think it's time add this to >>> u-boot-sunxi#next. >> >> Before you do that, note that I've just added 2 patches there, which I would >> like to get into v2014.10. Specifically I'm hoping that I can get some >> positive testing feedback on the bananapi gmac patch I've send (off-list), >> and I believe we really should try to get the bananapi fix into v2014.10, >> and if we're going todo a pull-req for v2014.10, we might as well include >> the 2 patches I've just added to next. Do you agree ? > > You mean these two? > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i Yes. > The latter seems like a feature to me, or at least the changelog doesn't > give any rationale why it should go in now rather than waiting for the > next merge window (i.e. why it's a bugfix, what the upside is to justify > its inclusion now). How much testing has it had and what are the > potential downsides? AFAIK the downside is that High Capacity cards will not work without it. Looking at the code if this bit is set, then for some commands drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're right that this may cause some undesirable side effects, so lets delay this one. > WRT the new board (and new boards generally), I'm in two minds. On the > one hand they are pretty low risk (can't regress anything else, at least > not in this case), on the other we are 6 weeks past the close of the > merge window and 2 from the release date, so we are pretty far along. > Where do we draw the line? Normally I would not include new boards at this moment in the cycle, but since we need to do a pull-req for the gmac anyways I thought it would be nice to have it included, esp. since many distros only spin things like sdcard boot images once, so if we do not include it now, many distros will not get it for a significant amount of time. Either way let me know how you want to proceed, if you think we should not include this, then I'll send a pull-req with only the gmac fix. > The gmac fix is a clear bug fix and once it is properly posted publicly > I will ack and then I agree it should go in. I was hoping for Stephen to get around to testing it today, and then I wanted to send it out with his Tested-by. I'll just go and send it as is for now. >> Still feel free to merge the sun6i series into next, I can just cherry pick >> the 3 patches in question directly into master when I'm ready to send the >> pull-req. > > Ack, that's what I expected to happen. Regards, Hans
On Sun, 2014-09-28 at 20:10 +0200, Hans de Goede wrote: > On 09/28/2014 06:20 PM, Ian Campbell wrote: > > On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: > >> Before you do that, note that I've just added 2 patches there, which I would > >> like to get into v2014.10. Specifically I'm hoping that I can get some > >> positive testing feedback on the bananapi gmac patch I've send (off-list), > >> and I believe we really should try to get the bananapi fix into v2014.10, > >> and if we're going todo a pull-req for v2014.10, we might as well include > >> the 2 patches I've just added to next. Do you agree ? > > > > You mean these two? > > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i > > Yes. > > > The latter seems like a feature to me, or at least the changelog doesn't > > give any rationale why it should go in now rather than waiting for the > > next merge window (i.e. why it's a bugfix, what the upside is to justify > > its inclusion now). How much testing has it had and what are the > > potential downsides? > > AFAIK the downside is that High Capacity cards will not work without it. > > Looking at the code if this bit is set, then for some commands > drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're > right that this may cause some undesirable side effects, so lets delay > this one. OK. > > WRT the new board (and new boards generally), I'm in two minds. On the > > one hand they are pretty low risk (can't regress anything else, at least > > not in this case), on the other we are 6 weeks past the close of the > > merge window and 2 from the release date, so we are pretty far along. > > Where do we draw the line? > > Normally I would not include new boards at this moment in the cycle, but > since we need to do a pull-req for the gmac anyways I thought it would > be nice to have it included, esp. since many distros only spin things > like sdcard boot images once, so if we do not include it now, many distros > will not get it for a significant amount of time. There's always Just One More Board(tm) ;-) > Either way let me know how you want to proceed, if you think we should not > include this, then I'll send a pull-req with only the gmac fix. As I say I'm in two minds. I'm not really sure what the u-boot norm is on this, I was hoping someone might chime in (although it's not been very long and the thread topic doesn't exactly scream for attention). Maybe run it by Albert/Tom and see how they feel about such things in general? Where run it by might be two alternate PRs? Or a PR structured so the new board can trivially be dropped? > > The gmac fix is a clear bug fix and once it is properly posted publicly > > I will ack and then I agree it should go in. > > I was hoping for Stephen to get around to testing it today, and then I wanted > to send it out with his Tested-by. I'll just go and send it as is for now. s/Stephen/Karsten/? Ian.
Hi, On 09/28/2014 11:36 PM, Ian Campbell wrote: > On Sun, 2014-09-28 at 20:10 +0200, Hans de Goede wrote: >> On 09/28/2014 06:20 PM, Ian Campbell wrote: >>> On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: > >>>> Before you do that, note that I've just added 2 patches there, which I would >>>> like to get into v2014.10. Specifically I'm hoping that I can get some >>>> positive testing feedback on the bananapi gmac patch I've send (off-list), >>>> and I believe we really should try to get the bananapi fix into v2014.10, >>>> and if we're going todo a pull-req for v2014.10, we might as well include >>>> the 2 patches I've just added to next. Do you agree ? >>> >>> You mean these two? >>> sun7i: Add support for Olimex A20-OLinuXino-LIME2 >>> mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i >> >> Yes. >> >>> The latter seems like a feature to me, or at least the changelog doesn't >>> give any rationale why it should go in now rather than waiting for the >>> next merge window (i.e. why it's a bugfix, what the upside is to justify >>> its inclusion now). How much testing has it had and what are the >>> potential downsides? >> >> AFAIK the downside is that High Capacity cards will not work without it. >> >> Looking at the code if this bit is set, then for some commands >> drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're >> right that this may cause some undesirable side effects, so lets delay >> this one. > > OK. > >>> WRT the new board (and new boards generally), I'm in two minds. On the >>> one hand they are pretty low risk (can't regress anything else, at least >>> not in this case), on the other we are 6 weeks past the close of the >>> merge window and 2 from the release date, so we are pretty far along. >>> Where do we draw the line? >> >> Normally I would not include new boards at this moment in the cycle, but >> since we need to do a pull-req for the gmac anyways I thought it would >> be nice to have it included, esp. since many distros only spin things >> like sdcard boot images once, so if we do not include it now, many distros >> will not get it for a significant amount of time. > > There's always Just One More Board(tm) ;-) Right, so lets just drop the board and I'll do a pull-req with only the bananapi gmac fix, can I have your Reviewed-by for that one please? >> Either way let me know how you want to proceed, if you think we should not >> include this, then I'll send a pull-req with only the gmac fix. > > As I say I'm in two minds. I'm not really sure what the u-boot norm is > on this, I was hoping someone might chime in (although it's not been > very long and the thread topic doesn't exactly scream for attention). > Maybe run it by Albert/Tom and see how they feel about such things in > general? > > Where run it by might be two alternate PRs? Or a PR structured so the > new board can trivially be dropped? > >>> The gmac fix is a clear bug fix and once it is properly posted publicly >>> I will ack and then I agree it should go in. >> >> I was hoping for Stephen to get around to testing it today, and then I wanted >> to send it out with his Tested-by. I'll just go and send it as is for now. > > s/Stephen/Karsten/? Yes, my bad. Regards, Hans
On Mon, 2014-09-29 at 20:08 +0200, Hans de Goede wrote: > > Right, so lets just drop the board and I'll do a pull-req with only > the > bananapi gmac fix, can I have your Reviewed-by for that one please? Done.
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig new file mode 100644 index 0000000..16800de --- /dev/null +++ b/configs/Colombus_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" +CONFIG_ARM=y +CONFIG_TARGET_SUN6I=y +CONFIG_FDTFILE="sun6i-a31-colombus.dtb"
The Colombus board is an A31 evaluation board from WITS Technology. Signed-off-by: Chen-Yu Tsai <wens@csie.org> --- configs/Colombus_defconfig | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 configs/Colombus_defconfig