From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lokesh Vutla <lokeshvutla@ti.com>
Date: Wed, 26 Apr 2017 09:59:32 +0530
Subject: [U-Boot] [PATCH 4/6] am33xx: Provide platform data for mmc
In-Reply-To: <CAHCN7xKDQrwexgs3oDcEq90EPPujGHtJnCHxcGwSWd4Bt6Tw2A@mail.gmail.com>
References: <20170422065048.8617-1-lokeshvutla@ti.com>
 <20170422065048.8617-5-lokeshvutla@ti.com>
 <20170425211039.GN12511@bill-the-cat>
 <CAHCN7xKDQrwexgs3oDcEq90EPPujGHtJnCHxcGwSWd4Bt6Tw2A@mail.gmail.com>
Message-ID: <55e4186a-430d-066f-89d5-22569b386951@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Adam,

On Wednesday 26 April 2017 05:35 AM, Adam Ford wrote:
> On Tue, Apr 25, 2017 at 4:10 PM, Tom Rini <trini@konsulko.com> wrote:
>> On Sat, Apr 22, 2017 at 12:20:46PM +0530, Lokesh Vutla wrote:
>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>> ---
>>>  board/ti/am335x/board.c | 32 ++++++++++++++++++++++++++++++++
>>>  1 file changed, 32 insertions(+)
>>>
>>> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
>>> index 3e842d3187..566183e669 100644
>>> --- a/board/ti/am335x/board.c
>>> +++ b/board/ti/am335x/board.c
>>> @@ -9,6 +9,7 @@
>>>   */
>>>
>>>  #include <common.h>
>>> +#include <dm.h>
>>>  #include <errno.h>
>>>  #include <spl.h>
>>>  #include <serial.h>
>>> @@ -26,6 +27,7 @@
>>>  #include <asm/emif.h>
>>>  #include <asm/gpio.h>
>>>  #include <asm/omap_sec_common.h>
>>> +#include <asm/omap_mmc.h>
>>>  #include <i2c.h>
>>>  #include <miiphy.h>
>>>  #include <cpsw.h>
>>> @@ -892,3 +894,33 @@ void board_fit_image_post_process(void **p_image, size_t *p_size)
>>>       secure_boot_verify_image(p_image, p_size);
>>>  }
>>>  #endif
>>> +
>>> +#if !CONFIG_IS_ENABLED(OF_CONTROL)
>>> +static const struct omap_hsmmc_plat am335x_mmc0_platdata = {
>>> +     .base_addr = (struct hsmmc *)0x48060000,
>>
>> OK.  So, off the top of my head, from Adam's series about converting
>> omap3, OMAP_HSMMC1_BASE and company aren't defined correctly?  Or we're
>> playing games with that 0x100 offset?  I bring this up as since we have
>> defines for these base addresses already, we should make use of them,
>> but in this case first we'll have to do... something, yes?
>>
> 
> The base address for the AM335xx he has listed is correct at 0x480600,
> however the offset is 0x100.  Without without my patch I would expect
> this to correctly.  SYSCONFIG is at offset 0x110 and for OMAP3 the
> offset would be 0x10.  His patch looks like it supports the condition
> without OF_CONTROL, so maybe using a #define here would be
> appropriate, however without OF_CONFIG, I am guessing my patch would
> break stuff.

Your patch[1] definitely make sense and this is how it is handled in
kernel as well. Please keep it as is. Ill re-base this series on top of
your series and send a v2.

[1] http://patchwork.ozlabs.org/patch/751300/

Thanks and regards,
Lokesh