[U-Boot] omap3 spi registers

[Vignesh R <vigneshr@ti.com>]

Hi,

On 05/12/2016 06:14 PM, Martin Hejnfelt wrote:
> Hi,
> 
> I am working with a board based off the am335x CPU and I am going to
> use SPI through u-boot. I've therefore been fiddling with u-boot and
> enabling spi0 through devicetree and all, which works fine (at least
> probing and so on). I am using CONFIG_DM_SPI for this, and
> u-boot-2016.05-rc3.
> However when I try to access the SPI peripheral, u-boot hanged.
> 
> Debugging through this showed that the culprit lies within the
> spi_reset call inside omap3_spi.c when the SPI bus is being claimed.
> The function tries to write to the sysconfig register, based 0x110 off
> the BASE. Problem is that the base defined in device tree include I am
> basing myself off (am335x.dtsi) is 0x48030000, and the offset is
> defined to 0x10, which means the register being written to is
> 0x48030010 and not 0x48030110 as it is supposed to, again resulting in
> the hang due to the endless do-while loop in spi_reset. This I guess
> is due to this part priv->regs = (struct mcspi *)dev_get_addr(dev); of
> omap3_spi_probe as it reads the reg property off the device tree.
> 
> OK, so for my question, what is really the correct way to fix this?
> 0x48030000 is the "real" base of McSPI0, although the first 0x100 part
> is revision stuff according to the technical datasheet of the am335x.
> If I change the reg value of the device tree to 0x48030100 then it
> does not hang, reset seems to work fine, however I have no idea of the
> influences this will have (the device tree is also used in the kernel
> and so on), I would guess its not the "right" way.
> 
> Any input/output is appreciated.
> 

I think, the right to handle this is based on compatible as done in
kernel driver (drivers/spi/spi-omap2-mcspi.c)
Something like, if compatible is "ti,omap4-mcspi" then add offset 0x100
to regs property


-- 
Regards
Vignesh