[GIT PULL 1/2] SOCFPGA updates for 3.18

[GIT PULL 1/2] SOCFPGA updates for 3.18

[dinguyen at opensource.altera.com]

Hi Arnd, Kevin and Olof,

Please consider pulling in these patches for v3.18. 5 of the 6 patches are
DTS updates and the 1 patch is updating the MAINTAINERS entry with my new
email address.

Thanks,
Dinh

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

are available in the git repository at:

  git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_update_for_v3.18

for you to fetch changes up to 75a41826e2c5dc1dc0fd5195fc29b031c97337af:

  arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries. (2014-09-04 10:15:52 -0500)

----------------------------------------------------------------
arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

----------------------------------------------------------------
Dinh Nguyen (4):
      MAINTAINERS: update entries for ARM/SOCFPGA platform
      ARM: dts: socfpga: remove extra alias in the ArriaV devkit
      ARM: dts: socfpga: Add SD card detect
      ARM: dts: socfpga: memreserve first 4KB for future system use

Jaehoon Chung (1):
      ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

Thor Thayer (1):
      arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.

 .../devicetree/bindings/arm/altera/socfpga-sdram-edac.txt | 15 +++++++++++++++
 MAINTAINERS                                               |  7 +++++--
 arch/arm/boot/dts/socfpga.dtsi                            | 11 +++++++++++
 arch/arm/boot/dts/socfpga_arria5.dtsi                     | 11 +++++------
 arch/arm/boot/dts/socfpga_arria5_socdk.dts                |  7 -------
 arch/arm/boot/dts/socfpga_cyclone5.dtsi                   | 13 ++++++-------
 arch/arm/boot/dts/socfpga_cyclone5_socdk.dts              |  4 ++++
 arch/arm/boot/dts/socfpga_vt.dts                          |  9 +++------
 8 files changed, 49 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt

[GIT PULL 2/2] SOCFPGA driver updates for 3.18

[dinguyen at opensource.altera.com]

Hi Arnd, Kevin and Olof,

Please consider pulling this patch for v3.18. Boris had given me permission to
take this patch together with it's DTS component. The DTS portion was in the
previous pull request.

Thanks,
Dinh

The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:

  Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)

are available in the git repository at:

  git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_driver_for_v3.18

for you to fetch changes up to 0730c4a52ef777a3098e00363e56858f14d6d323:

  edac: altera: Add Altera SDRAM EDAC support (2014-09-04 11:05:23 -0500)

----------------------------------------------------------------
SOCFPGA driver update for v3.18

----------------------------------------------------------------
Thor Thayer (1):
      edac: altera: Add Altera SDRAM EDAC support

 MAINTAINERS                |   5 +
 drivers/edac/Kconfig       |   9 +
 drivers/edac/Makefile      |   2 +
 drivers/edac/altera_edac.c | 410 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 426 insertions(+)
 create mode 100644 drivers/edac/altera_edac.c

[GIT PULL 2/2] SOCFPGA driver updates for 3.18

[Arnd Bergmann]

On Thursday 04 September 2014 11:11:45 dinguyen at opensource.altera.com wrote:
> Hi Arnd, Kevin and Olof,
> 
> Please consider pulling this patch for v3.18. Boris had given me permission to
> take this patch together with it's DTS component. The DTS portion was in the
> previous pull request.

I have no objections to the code, but I don't understand what you gain
from merging it through arm-soc. There is no dependency between the
driver and the dts entries in any way, you just need to have both in order
for things to work.

We can always pull in drivers with permission from the maintainer when there
is a good reason to do that, but I don't see that reason for this patch,
so I'd prefer to have Boris merge it through his tree, unless I'm missing
something.

	Arnd

[GIT PULL 2/2] SOCFPGA driver updates for 3.18

[Borislav Petkov]

On Tue, Sep 09, 2014 at 04:59:07PM +0200, Arnd Bergmann wrote:
> On Thursday 04 September 2014 11:11:45 dinguyen at opensource.altera.com wrote:
> > Hi Arnd, Kevin and Olof,
> > 
> > Please consider pulling this patch for v3.18. Boris had given me permission to
> > take this patch together with it's DTS component. The DTS portion was in the
> > previous pull request.
> 
> I have no objections to the code, but I don't understand what you gain
> from merging it through arm-soc. There is no dependency between the
> driver and the dts entries in any way, you just need to have both in order
> for things to work.

This is why I wanted them to go together, for completeness...

> We can always pull in drivers with permission from the maintainer when there
> is a good reason to do that, but I don't see that reason for this patch,
> so I'd prefer to have Boris merge it through his tree, unless I'm missing
> something.

... but then Dinh suggested he takes it so... In any case, I don't care
who takes it. Normally I'd take them without much ado but I'd suggest
we make an exception this one time since I'm on vacation with flaky
interwebs connection and doing pull requests and merging patches doesn't
work as smoothly.

So Arnd, if you take it this one time only, I'd appreciate it. Otherwise
it'll have to wait until I get back.

Thanks.

-- 
Regards/Gruss,
    Boris.
--

[GIT PULL 2/2] SOCFPGA driver updates for 3.18

[Arnd Bergmann]

On Tuesday 09 September 2014 17:45:25 Borislav Petkov wrote:
> 
> > We can always pull in drivers with permission from the maintainer when there
> > is a good reason to do that, but I don't see that reason for this patch,
> > so I'd prefer to have Boris merge it through his tree, unless I'm missing
> > something.
> 
> ... but then Dinh suggested he takes it so... In any case, I don't care
> who takes it. Normally I'd take them without much ado but I'd suggest
> we make an exception this one time since I'm on vacation with flaky
> interwebs connection and doing pull requests and merging patches doesn't
> work as smoothly.
> 
> So Arnd, if you take it this one time only, I'd appreciate it. Otherwise
> it'll have to wait until I get back.

Sure, no problem. Pulled into next/driver in arm-soc now.

Thanks for the quick reply, enjoy your vacation!

	Arnd

[GIT PULL 2/2] SOCFPGA driver updates for 3.18

[Borislav Petkov]

On Tue, Sep 09, 2014 at 05:53:40PM +0200, Arnd Bergmann wrote:
> Sure, no problem. Pulled into next/driver in arm-soc now.
> 
> Thanks for the quick reply, enjoy your vacation!

Thanks Arnd, much appreciated!

-- 
Regards/Gruss,
    Boris.
--

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Pavel Machek]

> Jaehoon Chung (1):
>       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
> 

This patch is a bad idea. It removes support for two mmc cards on a
single controller -- configuration hardware supports and configuration
that allows using u-SD card on mcvevk board.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Arnd Bergmann]

On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
> > Jaehoon Chung (1):
> >       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
> > 
> 
> This patch is a bad idea. It removes support for two mmc cards on a
> single controller -- configuration hardware supports and configuration
> that allows using u-SD card on mcvevk board.
> 

Your objection comes too late, and to the wrong patch, since the
driver and all other users have already been changed. We had a long
discussion about this when the issue first came up, and we could
not find any example of dw-mmc actually being used in a scenario
with one controller that has multiple devices attached.

Apparently every user out there instead uses multiple controller
instances instead. Are you sure that the socfpga implementation
is an exception from this?

	Arnd

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Pavel Machek]

On Tue 2014-09-09 17:02:34, Arnd Bergmann wrote:
> On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
> > > Jaehoon Chung (1):
> > >       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
> > > 
> > 
> > This patch is a bad idea. It removes support for two mmc cards on a
> > single controller -- configuration hardware supports and configuration
> > that allows using u-SD card on mcvevk board.
> > 
> 
> Your objection comes too late, and to the wrong patch, since the
> driver and all other users have already been changed. We had a long
> discussion about this when the issue first came up, and we could
> not find any example of dw-mmc actually being used in a scenario
> with one controller that has multiple devices attached.

Well, this is not first time I raised this. 3.17 is not yet out, so we
still have chance to fix regressions without major fuss.

> Apparently every user out there instead uses multiple controller
> instances instead. Are you sure that the socfpga implementation
> is an exception from this?

Marek Vasut has the hardware. His board apprently has uSD and eMMC,
and I believe it has just one controller. I'll try to get details.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Ulf Hansson]

On 9 September 2014 23:02, Pavel Machek <pavel@denx.de> wrote:
> On Tue 2014-09-09 17:02:34, Arnd Bergmann wrote:
>> On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
>> > > Jaehoon Chung (1):
>> > >       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
>> > >
>> >
>> > This patch is a bad idea. It removes support for two mmc cards on a
>> > single controller -- configuration hardware supports and configuration
>> > that allows using u-SD card on mcvevk board.
>> >
>>
>> Your objection comes too late, and to the wrong patch, since the
>> driver and all other users have already been changed. We had a long
>> discussion about this when the issue first came up, and we could
>> not find any example of dw-mmc actually being used in a scenario
>> with one controller that has multiple devices attached.
>
> Well, this is not first time I raised this. 3.17 is not yet out, so we
> still have chance to fix regressions without major fuss.
>
>> Apparently every user out there instead uses multiple controller
>> instances instead. Are you sure that the socfpga implementation
>> is an exception from this?
>
> Marek Vasut has the hardware. His board apprently has uSD and eMMC,
> and I believe it has just one controller. I'll try to get details.
>

Just wanted to highlight some of the reasons to why the earlier
discussion we have had, came to the conclusion to remove the slot
node.

1) The mmc core don't support multiple cards attached to the same
host, it never has. Also, I am not aware of any requests that
suggested us to add it. Due to obvious reasons from performance
perspective it's simply a really bad idea, that's likely also why
there haven't been any requests for it.

2) On the host level, the support for handle multiple slots in DT for
dw-mmc has been broken. While dw-mmc parsed the DT nodes for slots, it
screwed up configurations. Thus the support for slots have never
worked as expected from DT point of view.

Kind regards
Uffe

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Pavel Machek]

On Wed 2014-09-10 09:13:27, Ulf Hansson wrote:
> On 9 September 2014 23:02, Pavel Machek <pavel@denx.de> wrote:
> > On Tue 2014-09-09 17:02:34, Arnd Bergmann wrote:
> >> On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
> >> > > Jaehoon Chung (1):
> >> > >       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
> >> > >
> >> >
> >> > This patch is a bad idea. It removes support for two mmc cards on a
> >> > single controller -- configuration hardware supports and configuration
> >> > that allows using u-SD card on mcvevk board.
> >> >
> >>
> >> Your objection comes too late, and to the wrong patch, since the
> >> driver and all other users have already been changed. We had a long
> >> discussion about this when the issue first came up, and we could
> >> not find any example of dw-mmc actually being used in a scenario
> >> with one controller that has multiple devices attached.
> >
> > Well, this is not first time I raised this. 3.17 is not yet out, so we
> > still have chance to fix regressions without major fuss.
> >
> >> Apparently every user out there instead uses multiple controller
> >> instances instead. Are you sure that the socfpga implementation
> >> is an exception from this?
> >
> > Marek Vasut has the hardware. His board apprently has uSD and eMMC,
> > and I believe it has just one controller. I'll try to get details.
> >
> 
> Just wanted to highlight some of the reasons to why the earlier
> discussion we have had, came to the conclusion to remove the slot
> node.
> 
> 1) The mmc core don't support multiple cards attached to the same
> host, it never has. Also, I am not aware of any requests that
> suggested us to add it. Due to obvious reasons from performance
> perspective it's simply a really bad idea, that's likely also why
> there haven't been any requests for it.

Well, that's Linux problem, right? (And why is it bad idea, btw? The
bandwidth will be shared between the controllers, ok, that does not
sound too bad.)

> 2) On the host level, the support for handle multiple slots in DT for
> dw-mmc has been broken. While dw-mmc parsed the DT nodes for slots, it
> screwed up configurations. Thus the support for slots have never
> worked as expected from DT point of view.

Well, DT is supposed to describe the hardware. From your description,
it seems that linux does not support two slots on one controller and
DT parsing code basically ignores the slots. (Logical, if it can't
support two slots).

So now we are breaking DT description due to Linux limitations. Which

a) makes it hard for any other os not having same limitation

b) makes it hard for people to fix the limitation

c) does not really solve anything

d) breaks backward compatibility with old dts

If nothing, d) should be argument not to do this.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Ulf Hansson]

On 10 September 2014 10:33, Pavel Machek <pavel@denx.de> wrote:
> On Wed 2014-09-10 09:13:27, Ulf Hansson wrote:
>> On 9 September 2014 23:02, Pavel Machek <pavel@denx.de> wrote:
>> > On Tue 2014-09-09 17:02:34, Arnd Bergmann wrote:
>> >> On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
>> >> > > Jaehoon Chung (1):
>> >> > >       ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc
>> >> > >
>> >> >
>> >> > This patch is a bad idea. It removes support for two mmc cards on a
>> >> > single controller -- configuration hardware supports and configuration
>> >> > that allows using u-SD card on mcvevk board.
>> >> >
>> >>
>> >> Your objection comes too late, and to the wrong patch, since the
>> >> driver and all other users have already been changed. We had a long
>> >> discussion about this when the issue first came up, and we could
>> >> not find any example of dw-mmc actually being used in a scenario
>> >> with one controller that has multiple devices attached.
>> >
>> > Well, this is not first time I raised this. 3.17 is not yet out, so we
>> > still have chance to fix regressions without major fuss.
>> >
>> >> Apparently every user out there instead uses multiple controller
>> >> instances instead. Are you sure that the socfpga implementation
>> >> is an exception from this?
>> >
>> > Marek Vasut has the hardware. His board apprently has uSD and eMMC,
>> > and I believe it has just one controller. I'll try to get details.
>> >
>>
>> Just wanted to highlight some of the reasons to why the earlier
>> discussion we have had, came to the conclusion to remove the slot
>> node.
>>
>> 1) The mmc core don't support multiple cards attached to the same
>> host, it never has. Also, I am not aware of any requests that
>> suggested us to add it. Due to obvious reasons from performance
>> perspective it's simply a really bad idea, that's likely also why
>> there haven't been any requests for it.
>
> Well, that's Linux problem, right? (And why is it bad idea, btw? The
> bandwidth will be shared between the controllers, ok, that does not
> sound too bad.)

Bandwidth is just one issue. Latency is yet another, which is probably
far worse to handle than bandwidth.

>
>> 2) On the host level, the support for handle multiple slots in DT for
>> dw-mmc has been broken. While dw-mmc parsed the DT nodes for slots, it
>> screwed up configurations. Thus the support for slots have never
>> worked as expected from DT point of view.
>
> Well, DT is supposed to describe the hardware. From your description,
> it seems that linux does not support two slots on one controller and
> DT parsing code basically ignores the slots. (Logical, if it can't
> support two slots).
>
> So now we are breaking DT description due to Linux limitations. Which
>
> a) makes it hard for any other os not having same limitation
>
> b) makes it hard for people to fix the limitation
>
> c) does not really solve anything

Yes it does, the problem in 2) gets fixed.

>
> d) breaks backward compatibility with old dts

According to 2), it has never worked - so we don't break anything.

>
> If nothing, d) should be argument not to do this.
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Kind regards
Uffe

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Pavel Machek]

Hi!

> >> 2) On the host level, the support for handle multiple slots in DT for
> >> dw-mmc has been broken. While dw-mmc parsed the DT nodes for slots, it
> >> screwed up configurations. Thus the support for slots have never
> >> worked as expected from DT point of view.
> >
> > Well, DT is supposed to describe the hardware. From your description,
> > it seems that linux does not support two slots on one controller and
> > DT parsing code basically ignores the slots. (Logical, if it can't
> > support two slots).
> >
> > So now we are breaking DT description due to Linux limitations. Which
> >
> > a) makes it hard for any other os not having same limitation
> >
> > b) makes it hard for people to fix the limitation
> >
> > c) does not really solve anything
> 
> Yes it does, the problem in 2) gets fixed.
> 
> >
> > d) breaks backward compatibility with old dts
> 
> According to 2), it has never worked - so we don't break anything.

Umm? u-SD worked for me in 3.14, 3.15 and 3.16 with the device tree,
and with single-slot described in the device tree. Now I have to
change dtb-s to keep working configuration, which is something device
tree should never ever do.

Is it so hard to just fix the multiple slot parsing?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Dinh Nguyen]

On 9/10/14, 6:00 AM, Pavel Machek wrote:
> Hi!
> 
>>>> 2) On the host level, the support for handle multiple slots in DT for
>>>> dw-mmc has been broken. While dw-mmc parsed the DT nodes for slots, it
>>>> screwed up configurations. Thus the support for slots have never
>>>> worked as expected from DT point of view.
>>>
>>> Well, DT is supposed to describe the hardware. From your description,
>>> it seems that linux does not support two slots on one controller and
>>> DT parsing code basically ignores the slots. (Logical, if it can't
>>> support two slots).
>>>
>>> So now we are breaking DT description due to Linux limitations. Which
>>>
>>> a) makes it hard for any other os not having same limitation
>>>
>>> b) makes it hard for people to fix the limitation
>>>
>>> c) does not really solve anything
>>
>> Yes it does, the problem in 2) gets fixed.
>>
>>>
>>> d) breaks backward compatibility with old dts
>>
>> According to 2), it has never worked - so we don't break anything.
> 
> Umm? u-SD worked for me in 3.14, 3.15 and 3.16 with the device tree,
> and with single-slot described in the device tree. Now I have to
> change dtb-s to keep working configuration, which is something device
> tree should never ever do.

I tested the DTB with and without the patch, and it all works fine.

Dinh
> 
> Is it so hard to just fix the multiple slot parsing?
> 
> 									Pavel
> 

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Marek Vasut]

On Tuesday, September 09, 2014 at 11:02:32 PM, Pavel Machek wrote:
> On Tue 2014-09-09 17:02:34, Arnd Bergmann wrote:
> > On Tuesday 09 September 2014 16:17:56 Pavel Machek wrote:
> > > > Jaehoon Chung (1):
> > > >       ARM: dts: socfpga: unuse the slot-node and deprecate the
> > > >       supports-highspeed for dw-mmc
> > > 
> > > This patch is a bad idea. It removes support for two mmc cards on a
> > > single controller -- configuration hardware supports and configuration
> > > that allows using u-SD card on mcvevk board.

This is not true, the MCVEVK does _NOT_ have two cards on a single controller.

> > Your objection comes too late, and to the wrong patch, since the
> > driver and all other users have already been changed. We had a long
> > discussion about this when the issue first came up, and we could
> > not find any example of dw-mmc actually being used in a scenario
> > with one controller that has multiple devices attached.
> 
> Well, this is not first time I raised this. 3.17 is not yet out, so we
> still have chance to fix regressions without major fuss.
> 
> > Apparently every user out there instead uses multiple controller
> > instances instead. Are you sure that the socfpga implementation
> > is an exception from this?
> 
> Marek Vasut has the hardware. His board apprently has uSD and eMMC,
> and I believe it has just one controller. I'll try to get details.

So please go ahead with this PR, sorry for blocking it.

Best regards,
Marek Vasut

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Arnd Bergmann]

On Thursday 04 September 2014 11:11:44 dinguyen at opensource.altera.com wrote:
> Hi Arnd, Kevin and Olof,
> 
> Please consider pulling in these patches for v3.18. 5 of the 6 patches are
> DTS updates and the 1 patch is updating the MAINTAINERS entry with my new
> email address.

Pulled into next/dt. It would be nice if you could in the future
separate the DT updates from the other changes more, even if that means
sending a separate patch or pull request for something as trivial as
the MAINTAINERS update.

For some reason your pull request ended up in my spam folder, where
I only found it today when looking for something else. I don't know
why this happened, but you might want to watch out for this happening
again, and ping us if a future pull request doesn't get merged within
a couple of days. 

> 
> The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:
> 
>   Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)
> 
> are available in the git repository at:
> 
>   git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_update_for_v3.18
> 
> for you to fetch changes up to 75a41826e2c5dc1dc0fd5195fc29b031c97337af:
> 
>   arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries. (2014-09-04 10:15:52 -0500)
> 
> ----------------------------------------------------------------
> arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.
> 

Please try to be a little more verbose with the changelog, as this
is what ends up in the git history for the merge commit.


Thanks,

	Arnd

[GIT PULL 1/2] SOCFPGA updates for 3.18

[Dinh Nguyen]

On 09/09/2014 09:55 AM, Arnd Bergmann wrote:
> On Thursday 04 September 2014 11:11:44 dinguyen at opensource.altera.com wrote:
>> Hi Arnd, Kevin and Olof,
>>
>> Please consider pulling in these patches for v3.18. 5 of the 6 patches are
>> DTS updates and the 1 patch is updating the MAINTAINERS entry with my new
>> email address.
> 
> Pulled into next/dt. It would be nice if you could in the future
> separate the DT updates from the other changes more, even if that means
> sending a separate patch or pull request for something as trivial as
> the MAINTAINERS update.

Will keep this in mind in the future.
> 
> For some reason your pull request ended up in my spam folder, where
> I only found it today when looking for something else. I don't know
> why this happened, but you might want to watch out for this happening
> again, and ping us if a future pull request doesn't get merged within
> a couple of days. 
> 

I was going to give it a week.

>>
>> The following changes since commit 52addcf9d6669fa439387610bc65c92fa0980cef:
>>
>>   Linux 3.17-rc2 (2014-08-25 15:36:20 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga_update_for_v3.18
>>
>> for you to fetch changes up to 75a41826e2c5dc1dc0fd5195fc29b031c97337af:
>>
>>   arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries. (2014-09-04 10:15:52 -0500)
>>
>> ----------------------------------------------------------------
>> arm: dts: Add Altera SDRAM EDAC bindings & devicetree entries.
>>
> 
> Please try to be a little more verbose with the changelog, as this
> is what ends up in the git history for the merge commit.
> 

Will do...

Thanks,
Dinh