On Tue, Apr 9, 2019 at 12:47 PM Heiko Stübner <he...@sntech.de> wrote:
>
> Hi Kever,
>
> Am Dienstag, 2. April 2019, 10:46:54 CEST schrieb Kever Yang:
> > Rockchip SOC's mmc controller does not support read data
> > from mmc to sram, we need a bounce buffer(in sdram), and then
> > copy to sram.
> >
> > Signed-off-by: Kever Yang <kever.y...@rock-chips.com>
> > ---
> >
> > common/bouncebuf.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/common/bouncebuf.c b/common/bouncebuf.c
> > index a7098e2caf..364fb17c96 100644
> > --- a/common/bouncebuf.c
> > +++ b/common/bouncebuf.c
> > @@ -26,6 +26,18 @@ static int addr_aligned(struct bounce_buffer *state)
> > return 0;
> > }
> >
> > +#ifdef CONFIG_ARCH_ROCKCHIP
> > + /*
> > + * Rockchip SOC's mmc controller does not support read data
> > + * from mmc to sram, we need a bounce buffer(in sdram), and then
> > + * copy to sram.
> > + */
> > + if (((ulong)state->user_buffer & 0xfff80000) ==
> > + CONFIG_ROCKCHIP_IRAM_BASE) {
> > + debug("Unsupport IRAM space %p\n", state->user_buffer);
> > + return 0;
> > + }
>
> wouldn't it be easier to just check for "in-ddr-region"?
> Rockchip SoCs may have multiple sram areas one might want to use.
>
> Also I get the feeling this should not live in an ARCH_ROCKCHIP ifdef.
> Instead maybe define some sort of kconfig settings to describe the
> directly usable memory areas, that the bounce_buffer then could use?
Indeed this still looks like a hack and should not be applied. My comments
to [1] still apply to this patch: arch-specific defines should not be located
in generic files if we can avoid it.
[1] https://patchwork.ozlabs.org/patch/1069730/
Regards,
Simon
>
>
> Heiko
>
> > +#endif
> > /* Aligned */
> > return 1;
> > }
> >
>
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
