[U-Boot] [PATCH 4/6] am33xx: Provide platform data for mmc

[Lokesh Vutla <lokeshvutla@ti.com>]

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