Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Peter Robinson]

Hi,

> This series adds initial support for RK3368 SoC and GeekBox.
> For more details see the commit message.
>
> Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.

Did you ever get a chance to rebase these? Wouldn't mind playing with
my geekbox with an upstream u-boot.

Regards,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Simon Glass]

Hi Tom, Andreas,

On 7 August 2016 at 14:07, Tom Rini  wrote:
> On Sun, Aug 07, 2016 at 06:46:37PM +0200, Andreas Färber wrote:
>> Am 07.08.2016 um 15:31 schrieb Tom Rini:
>> > On Sat, Aug 06, 2016 at 06:05:29PM +0200, Andreas Färber wrote:
>> >> Hi Simon,
>> >>
>> >> Am 06.08.2016 um 06:30 schrieb Simon Glass:
>> >>> Hi Andreas,
>> >>>
>> >>> On 17 July 2016 at 19:06, Andreas Färber  wrote:
>>  Hi,
>> 
>>  This series adds initial support for RK3368 SoC and GeekBox.
>>  For more details see the commit message.
>> 
>>  Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
>> 
>>  Regards,
>>  Andreas
>> 
>>  Cc: Simon Glass 
>>  Cc: Kever Yang 
>>  Cc: Heiko Stübner 
>> 
>>  Andreas Färber (2):
>>    dts: Import rk3368-geekbox.dts
>>    ARM64: rockchip: Add initial support for RK3368 based GeekBox
>> 
>> >>>
>> >>> Are you planning to respin these patches?
>> >>
>> >> Eventually...?
>> >>
>> >>> I'd like to get them applied soon.
>> >>
>> >> And I'd like to get my work recognized! However, despite our previous
>> >> IRC chat, I had to find out _while_ replying to the rk3399 mails that
>> >> you had once again not just applied all patches (twenty minutes after
>> >> ack'ing them on a Saturday) but already sent a pull on Tuesday my
>> >> nighttime that I was not CC'ed on and that Tom has merged the night
>> >> after. So it feels like I'm wasting my time here and consequently I
>> >> stopped my review and rebase.
>> >
>> > In the U-Boot community, we are not in the habit of cc'ing everyone with
>> > a change in a given pull request.  Is there a tool the kernel folks use
>> > here that makes this easy?
>>
>> Not that I'm aware of.
>>
>> But that is besides the point, as my very complaint is that I'm not
>> credited in the patches that got merged, so no tool could've extracted
>> my name for CC'ing.
>
> Alright.
>
>> It's about Simon having mismerged those patches and having overlooked
>> unresolved review comments of mine for those patches before and me
>> specifically having complained to him about not waiting for my
>> Reviewed-by before applying them. So him seeing that I did not reply to
>> his Saturday mails, I feel it would've been fair in this particular case
>> a) to ping me again after the weekend and b) to let me know that he is
>> no longer waiting for my review comments or that I really need to hurry
>> up with an objection until X. He did not say so in a reply that reached
>> my inbox, and I was not CC'ed on the pull request itself, thus a pull
>> request behind my back.
>>
>> I'm not too deep into U-Boot, so maybe there was a reason for this
>> hush-hush workflow, but then at least the communication was fairly bad.
>>
>> Had I known that the pull is already on the list, I wouldn't have
>> replied with a Reviewed-by for 1/4 that same day (which surely Simon was
>> CC'ed on) or I could've asked Tom to hold off merging it until I'm done
>> reviewing the next day.
>>
>> > And the rule of thumb that I use, and I try and get everyone else to use
>> > as well is that a patch should be out for a week before it gets picked
>> > up and merged as that should give everyone time to review, comment and
>> > test.  Did that not happen with the patches Simon picked up?
>>
>> Slightly less than a week. For some other projects it's ~two weeks.
>> Also again note that this is not about some random patch but one where
>> Simon specifically said he would be away, that he would exchange the
>> patches on his branch where necessary and where he asked me to "sing".
>> It leaves a bad taste that Simon was absent himself the week the patches
>> were posted but apparently expects me to be available whenever he is. I
>> don't work on U-Boot as a job, and for rebasing rk3368 patches - which
>> many of my review comments resulted from - I need access to the hardware
>> for testing.
>>
>> Note that I was similarly surprised how quickly two patches of mine went
>> into his tree, with just one day in between and despite conflicts
>> between my rk3368 and Kever's rk3399 preparations. I can see that having
>> patches in a tree facilitates testing, but it also prevents serious peer
>> review when not just staging but also merging them.
>
> I want to treat all of the above at once.  First, sorry.  We don't have
> an intentionally "hush-hush" workflow, but every custodian does decide
> how many emails to send when moving a patch forward.  And unless I'm
> testing multiple PRs (or they come in while I'm already testing one) the
> time between getting a PR and applying it is usually the same (US, east
> coast) day if it passes my testing.  But we are trying to include more
> crediting, not less, so it is not intentional to have left things
> out[1].  So this was a mistake in our part, sorry.  Sometimes review
> comments are missed.  But this too 

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Tom Rini]

On Sun, Aug 07, 2016 at 06:46:37PM +0200, Andreas Färber wrote:
> Am 07.08.2016 um 15:31 schrieb Tom Rini:
> > On Sat, Aug 06, 2016 at 06:05:29PM +0200, Andreas Färber wrote:
> >> Hi Simon,
> >>
> >> Am 06.08.2016 um 06:30 schrieb Simon Glass:
> >>> Hi Andreas,
> >>>
> >>> On 17 July 2016 at 19:06, Andreas Färber  wrote:
>  Hi,
> 
>  This series adds initial support for RK3368 SoC and GeekBox.
>  For more details see the commit message.
> 
>  Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
> 
>  Regards,
>  Andreas
> 
>  Cc: Simon Glass 
>  Cc: Kever Yang 
>  Cc: Heiko Stübner 
> 
>  Andreas Färber (2):
>    dts: Import rk3368-geekbox.dts
>    ARM64: rockchip: Add initial support for RK3368 based GeekBox
> 
> >>>
> >>> Are you planning to respin these patches?
> >>
> >> Eventually...?
> >>
> >>> I'd like to get them applied soon.
> >>
> >> And I'd like to get my work recognized! However, despite our previous
> >> IRC chat, I had to find out _while_ replying to the rk3399 mails that
> >> you had once again not just applied all patches (twenty minutes after
> >> ack'ing them on a Saturday) but already sent a pull on Tuesday my
> >> nighttime that I was not CC'ed on and that Tom has merged the night
> >> after. So it feels like I'm wasting my time here and consequently I
> >> stopped my review and rebase.
> > 
> > In the U-Boot community, we are not in the habit of cc'ing everyone with
> > a change in a given pull request.  Is there a tool the kernel folks use
> > here that makes this easy?
> 
> Not that I'm aware of.
> 
> But that is besides the point, as my very complaint is that I'm not
> credited in the patches that got merged, so no tool could've extracted
> my name for CC'ing.

Alright.

> It's about Simon having mismerged those patches and having overlooked
> unresolved review comments of mine for those patches before and me
> specifically having complained to him about not waiting for my
> Reviewed-by before applying them. So him seeing that I did not reply to
> his Saturday mails, I feel it would've been fair in this particular case
> a) to ping me again after the weekend and b) to let me know that he is
> no longer waiting for my review comments or that I really need to hurry
> up with an objection until X. He did not say so in a reply that reached
> my inbox, and I was not CC'ed on the pull request itself, thus a pull
> request behind my back.
> 
> I'm not too deep into U-Boot, so maybe there was a reason for this
> hush-hush workflow, but then at least the communication was fairly bad.
> 
> Had I known that the pull is already on the list, I wouldn't have
> replied with a Reviewed-by for 1/4 that same day (which surely Simon was
> CC'ed on) or I could've asked Tom to hold off merging it until I'm done
> reviewing the next day.
> 
> > And the rule of thumb that I use, and I try and get everyone else to use
> > as well is that a patch should be out for a week before it gets picked
> > up and merged as that should give everyone time to review, comment and
> > test.  Did that not happen with the patches Simon picked up?
> 
> Slightly less than a week. For some other projects it's ~two weeks.
> Also again note that this is not about some random patch but one where
> Simon specifically said he would be away, that he would exchange the
> patches on his branch where necessary and where he asked me to "sing".
> It leaves a bad taste that Simon was absent himself the week the patches
> were posted but apparently expects me to be available whenever he is. I
> don't work on U-Boot as a job, and for rebasing rk3368 patches - which
> many of my review comments resulted from - I need access to the hardware
> for testing.
> 
> Note that I was similarly surprised how quickly two patches of mine went
> into his tree, with just one day in between and despite conflicts
> between my rk3368 and Kever's rk3399 preparations. I can see that having
> patches in a tree facilitates testing, but it also prevents serious peer
> review when not just staging but also merging them.

I want to treat all of the above at once.  First, sorry.  We don't have
an intentionally "hush-hush" workflow, but every custodian does decide
how many emails to send when moving a patch forward.  And unless I'm
testing multiple PRs (or they come in while I'm already testing one) the
time between getting a PR and applying it is usually the same (US, east
coast) day if it passes my testing.  But we are trying to include more
crediting, not less, so it is not intentional to have left things
out[1].  So this was a mistake in our part, sorry.  Sometimes review
comments are missed.  But this too is not usually intentional unless
it's small things that can be addressed in a follow-up in order to get
things otherwise in and unblocking other work.  In the end however,
Simon, please 

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Andreas Färber]

Am 07.08.2016 um 15:31 schrieb Tom Rini:
> On Sat, Aug 06, 2016 at 06:05:29PM +0200, Andreas Färber wrote:
>> Hi Simon,
>>
>> Am 06.08.2016 um 06:30 schrieb Simon Glass:
>>> Hi Andreas,
>>>
>>> On 17 July 2016 at 19:06, Andreas Färber  wrote:
 Hi,

 This series adds initial support for RK3368 SoC and GeekBox.
 For more details see the commit message.

 Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.

 Regards,
 Andreas

 Cc: Simon Glass 
 Cc: Kever Yang 
 Cc: Heiko Stübner 

 Andreas Färber (2):
   dts: Import rk3368-geekbox.dts
   ARM64: rockchip: Add initial support for RK3368 based GeekBox

>>>
>>> Are you planning to respin these patches?
>>
>> Eventually...?
>>
>>> I'd like to get them applied soon.
>>
>> And I'd like to get my work recognized! However, despite our previous
>> IRC chat, I had to find out _while_ replying to the rk3399 mails that
>> you had once again not just applied all patches (twenty minutes after
>> ack'ing them on a Saturday) but already sent a pull on Tuesday my
>> nighttime that I was not CC'ed on and that Tom has merged the night
>> after. So it feels like I'm wasting my time here and consequently I
>> stopped my review and rebase.
> 
> In the U-Boot community, we are not in the habit of cc'ing everyone with
> a change in a given pull request.  Is there a tool the kernel folks use
> here that makes this easy?

Not that I'm aware of.

But that is besides the point, as my very complaint is that I'm not
credited in the patches that got merged, so no tool could've extracted
my name for CC'ing.

It's about Simon having mismerged those patches and having overlooked
unresolved review comments of mine for those patches before and me
specifically having complained to him about not waiting for my
Reviewed-by before applying them. So him seeing that I did not reply to
his Saturday mails, I feel it would've been fair in this particular case
a) to ping me again after the weekend and b) to let me know that he is
no longer waiting for my review comments or that I really need to hurry
up with an objection until X. He did not say so in a reply that reached
my inbox, and I was not CC'ed on the pull request itself, thus a pull
request behind my back.

I'm not too deep into U-Boot, so maybe there was a reason for this
hush-hush workflow, but then at least the communication was fairly bad.

Had I known that the pull is already on the list, I wouldn't have
replied with a Reviewed-by for 1/4 that same day (which surely Simon was
CC'ed on) or I could've asked Tom to hold off merging it until I'm done
reviewing the next day.

> And the rule of thumb that I use, and I try and get everyone else to use
> as well is that a patch should be out for a week before it gets picked
> up and merged as that should give everyone time to review, comment and
> test.  Did that not happen with the patches Simon picked up?

Slightly less than a week. For some other projects it's ~two weeks.
Also again note that this is not about some random patch but one where
Simon specifically said he would be away, that he would exchange the
patches on his branch where necessary and where he asked me to "sing".
It leaves a bad taste that Simon was absent himself the week the patches
were posted but apparently expects me to be available whenever he is. I
don't work on U-Boot as a job, and for rebasing rk3368 patches - which
many of my review comments resulted from - I need access to the hardware
for testing.

Note that I was similarly surprised how quickly two patches of mine went
into his tree, with just one day in between and despite conflicts
between my rk3368 and Kever's rk3399 preparations. I can see that having
patches in a tree facilitates testing, but it also prevents serious peer
review when not just staging but also merging them.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Tom Rini]

On Sat, Aug 06, 2016 at 06:05:29PM +0200, Andreas Färber wrote:
> Hi Simon,
> 
> Am 06.08.2016 um 06:30 schrieb Simon Glass:
> > Hi Andreas,
> > 
> > On 17 July 2016 at 19:06, Andreas Färber  wrote:
> >> Hi,
> >>
> >> This series adds initial support for RK3368 SoC and GeekBox.
> >> For more details see the commit message.
> >>
> >> Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
> >>
> >> Regards,
> >> Andreas
> >>
> >> Cc: Simon Glass 
> >> Cc: Kever Yang 
> >> Cc: Heiko Stübner 
> >>
> >> Andreas Färber (2):
> >>   dts: Import rk3368-geekbox.dts
> >>   ARM64: rockchip: Add initial support for RK3368 based GeekBox
> >>
> > 
> > Are you planning to respin these patches?
> 
> Eventually...?
> 
> > I'd like to get them applied soon.
> 
> And I'd like to get my work recognized! However, despite our previous
> IRC chat, I had to find out _while_ replying to the rk3399 mails that
> you had once again not just applied all patches (twenty minutes after
> ack'ing them on a Saturday) but already sent a pull on Tuesday my
> nighttime that I was not CC'ed on and that Tom has merged the night
> after. So it feels like I'm wasting my time here and consequently I
> stopped my review and rebase.

In the U-Boot community, we are not in the habit of cc'ing everyone with
a change in a given pull request.  Is there a tool the kernel folks use
here that makes this easy?

And the rule of thumb that I use, and I try and get everyone else to use
as well is that a patch should be out for a week before it gets picked
up and merged as that should give everyone time to review, comment and
test.  Did that not happen with the patches Simon picked up?

Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Simon Glass]

+Tom for comment

Hi Andreas,

On 6 August 2016 at 10:05, Andreas Färber  wrote:
> Hi Simon,
>
> Am 06.08.2016 um 06:30 schrieb Simon Glass:
>> Hi Andreas,
>>
>> On 17 July 2016 at 19:06, Andreas Färber  wrote:
>>> Hi,
>>>
>>> This series adds initial support for RK3368 SoC and GeekBox.
>>> For more details see the commit message.
>>>
>>> Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
>>>
>>> Regards,
>>> Andreas
>>>
>>> Cc: Simon Glass 
>>> Cc: Kever Yang 
>>> Cc: Heiko Stübner 
>>>
>>> Andreas Färber (2):
>>>   dts: Import rk3368-geekbox.dts
>>>   ARM64: rockchip: Add initial support for RK3368 based GeekBox
>>>
>>
>> Are you planning to respin these patches?
>
> Eventually...?

If it is soon then I can get this in for the upcoming release.
Otherwise I'll need to wait. Also can you please add a README with a
bit more detail on how to test it? Your cover letter suggests that it
requires shorting two pins (which pins?) after flashing U-Boot. Is
there another way for me to try it?

>
>> I'd like to get them applied soon.
>
> And I'd like to get my work recognized! However, despite our previous
> IRC chat, I had to find out _while_ replying to the rk3399 mails that
> you had once again not just applied all patches (twenty minutes after
> ack'ing them on a Saturday) but already sent a pull on Tuesday my
> nighttime that I was not CC'ed on and that Tom has merged the night
> after. So it feels like I'm wasting my time here and consequently I
> stopped my review and rebase.
>
> Not only that it's too late for the patches themselves, but Wolfgang
> also publishes statistics of Reviewed-bys, which we can't add to commits
> after merging. If you as maintainer don't give people who spent time
> providing serious review comments sufficient chance to add their
> Reviewed-by - and a weekend of absence is certainly something to cope
> with since you said you were away end of that week as well - it becomes
> a distorted, non-telling statistic. So I am kindly suggesting that
> Wolfgang drops the Reviewed-by statistics if maintainers don't care for
> them and instead we just all do ugly fix-ups so that we can at least get
> recognition in the Signed-off-by statistics.
>
> While we're only talking about 4 tags here, it's a matter of principle
> and respect.

What do you mean by respect?

I normally expect a follow-up review to come through fairly quickly.
The last review I saw from you was 10 days ago. I tend to want to move
things forward fairly quickly in general for Rockchip, but
particularly at this point where the merge window is closed and
pending patches really need to get in for testing.

So a few questions:
- How long do you expect a patch to sit on the list before I pick it up?
- Similarly for a follow-up v2, etc. patch?
- How long between my Ack and applying?
- Anything else you are looking for?

I seldom copy people on the pull requests - is that something we
should be doing?

I'm happy to adjust the rules for Rockchip if it will encourage more
participation. This is very new in mainline so there is a lot to do.

>
> Thanks,
> Andreas

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Andreas Färber]

Hi Simon,

Am 06.08.2016 um 06:30 schrieb Simon Glass:
> Hi Andreas,
> 
> On 17 July 2016 at 19:06, Andreas Färber  wrote:
>> Hi,
>>
>> This series adds initial support for RK3368 SoC and GeekBox.
>> For more details see the commit message.
>>
>> Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
>>
>> Regards,
>> Andreas
>>
>> Cc: Simon Glass 
>> Cc: Kever Yang 
>> Cc: Heiko Stübner 
>>
>> Andreas Färber (2):
>>   dts: Import rk3368-geekbox.dts
>>   ARM64: rockchip: Add initial support for RK3368 based GeekBox
>>
> 
> Are you planning to respin these patches?

Eventually...?

> I'd like to get them applied soon.

And I'd like to get my work recognized! However, despite our previous
IRC chat, I had to find out _while_ replying to the rk3399 mails that
you had once again not just applied all patches (twenty minutes after
ack'ing them on a Saturday) but already sent a pull on Tuesday my
nighttime that I was not CC'ed on and that Tom has merged the night
after. So it feels like I'm wasting my time here and consequently I
stopped my review and rebase.

Not only that it's too late for the patches themselves, but Wolfgang
also publishes statistics of Reviewed-bys, which we can't add to commits
after merging. If you as maintainer don't give people who spent time
providing serious review comments sufficient chance to add their
Reviewed-by - and a weekend of absence is certainly something to cope
with since you said you were away end of that week as well - it becomes
a distorted, non-telling statistic. So I am kindly suggesting that
Wolfgang drops the Reviewed-by statistics if maintainers don't care for
them and instead we just all do ugly fix-ups so that we can at least get
recognition in the Signed-off-by statistics.

While we're only talking about 4 tags here, it's a matter of principle
and respect.

Thanks,
Andreas

> 
> Thanks,
> Simon
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Simon Glass]

Hi Andreas,

On 17 July 2016 at 19:06, Andreas Färber  wrote:
> Hi,
>
> This series adds initial support for RK3368 SoC and GeekBox.
> For more details see the commit message.
>
> Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.
>
> Regards,
> Andreas
>
> Cc: Simon Glass 
> Cc: Kever Yang 
> Cc: Heiko Stübner 
>
> Andreas Färber (2):
>   dts: Import rk3368-geekbox.dts
>   ARM64: rockchip: Add initial support for RK3368 based GeekBox
>

Are you planning to respin these patches? I'd like to get them applied soon.

Thanks,
Simon


>  arch/arm/Kconfig   |4 -
>  arch/arm/dts/Makefile  |3 +-
>  arch/arm/dts/rk3368-geekbox.dts|  319 ++
>  arch/arm/dts/rk3368.dtsi   | 1082 
> 
>  arch/arm/mach-rockchip/Kconfig |   14 +
>  arch/arm/mach-rockchip/Makefile|1 +
>  arch/arm/mach-rockchip/rk3368/Kconfig  |   14 +
>  arch/arm/mach-rockchip/rk3368/Makefile |7 +
>  arch/arm/mach-rockchip/rk3368/rk3368.c |   28 +
>  board/geekbuying/geekbox/Kconfig   |   15 +
>  board/geekbuying/geekbox/Makefile  |7 +
>  board/geekbuying/geekbox/geekbox.c |   26 +
>  configs/geekbox_defconfig  |   20 +
>  include/configs/geekbox.h  |   19 +
>  include/configs/rk3368_common.h|   47 ++
>  include/dt-bindings/clock/rk3368-cru.h |  384 
>  16 files changed, 1985 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/dts/rk3368-geekbox.dts
>  create mode 100644 arch/arm/dts/rk3368.dtsi
>  create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig
>  create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile
>  create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c
>  create mode 100644 board/geekbuying/geekbox/Kconfig
>  create mode 100644 board/geekbuying/geekbox/Makefile
>  create mode 100644 board/geekbuying/geekbox/geekbox.c
>  create mode 100644 configs/geekbox_defconfig
>  create mode 100644 include/configs/geekbox.h
>  create mode 100644 include/configs/rk3368_common.h
>  create mode 100644 include/dt-bindings/clock/rk3368-cru.h
>
> --
> 2.6.6
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] rockchip: Initial RK3368 and GeekBox support

[Andreas Färber]

Hi,

This series adds initial support for RK3368 SoC and GeekBox.
For more details see the commit message.

Will need to be rebased onto Heiko's cleanups and Kever's RK3399 series.

Regards,
Andreas

Cc: Simon Glass 
Cc: Kever Yang 
Cc: Heiko Stübner 

Andreas Färber (2):
  dts: Import rk3368-geekbox.dts
  ARM64: rockchip: Add initial support for RK3368 based GeekBox

 arch/arm/Kconfig   |4 -
 arch/arm/dts/Makefile  |3 +-
 arch/arm/dts/rk3368-geekbox.dts|  319 ++
 arch/arm/dts/rk3368.dtsi   | 1082 
 arch/arm/mach-rockchip/Kconfig |   14 +
 arch/arm/mach-rockchip/Makefile|1 +
 arch/arm/mach-rockchip/rk3368/Kconfig  |   14 +
 arch/arm/mach-rockchip/rk3368/Makefile |7 +
 arch/arm/mach-rockchip/rk3368/rk3368.c |   28 +
 board/geekbuying/geekbox/Kconfig   |   15 +
 board/geekbuying/geekbox/Makefile  |7 +
 board/geekbuying/geekbox/geekbox.c |   26 +
 configs/geekbox_defconfig  |   20 +
 include/configs/geekbox.h  |   19 +
 include/configs/rk3368_common.h|   47 ++
 include/dt-bindings/clock/rk3368-cru.h |  384 
 16 files changed, 1985 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/dts/rk3368-geekbox.dts
 create mode 100644 arch/arm/dts/rk3368.dtsi
 create mode 100644 arch/arm/mach-rockchip/rk3368/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3368/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3368/rk3368.c
 create mode 100644 board/geekbuying/geekbox/Kconfig
 create mode 100644 board/geekbuying/geekbox/Makefile
 create mode 100644 board/geekbuying/geekbox/geekbox.c
 create mode 100644 configs/geekbox_defconfig
 create mode 100644 include/configs/geekbox.h
 create mode 100644 include/configs/rk3368_common.h
 create mode 100644 include/dt-bindings/clock/rk3368-cru.h

-- 
2.6.6

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot