[U-Boot,v2] serial: sh: Add support for R7S72100 (RZ/A1)

Add support for RZ/A1 series SoCs.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

---
v2:
 * Rebased against current tree
---
 drivers/serial/serial_sh.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

On 01/17/2018 02:52 AM, Chris Brandt wrote:
> Add support for RZ/A1 series SoCs.
> 
> Signed-off-by: Chris Brandt <chris.brandt@renesas.com>

Applied, thanks !

btw. are you planning to do DT/DM conversion of the RZ/A1 ?

> 
> ---
> v2:
>  * Rebased against current tree
> ---
>  drivers/serial/serial_sh.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/serial/serial_sh.h b/drivers/serial/serial_sh.h
> index 1b8d742f1c..1ea95509d7 100644
> --- a/drivers/serial/serial_sh.h
> +++ b/drivers/serial/serial_sh.h
> @@ -226,7 +226,8 @@ struct uart_port {
>  # define SCSCR_INIT(port)	0x38	/* TIE=0,RIE=0,TE=1,RE=1,REIE=1 */
>  #elif defined(CONFIG_R8A7790) || defined(CONFIG_R8A7791) || \
>  	defined(CONFIG_R8A7792) || defined(CONFIG_R8A7793) || \
> -	defined(CONFIG_R8A7794) || defined(CONFIG_RCAR_GEN3)
> +	defined(CONFIG_R8A7794) || defined(CONFIG_RCAR_GEN3) || \
> +	defined(CONFIG_R7S72100)
>  # if defined(CONFIG_SCIF_A)
>  #  define SCIF_ORER	0x0200
>  # else
>

On Friday, January 19, 2018 1, Marek Vasut wrote:
> Applied, thanks !


Thank you!


> btw. are you planning to do DT/DM conversion of the RZ/A1 ?


DM, yes.
DT, no

We're working on adding DM to RZ/A's I2C and timer drivers now. Then 
we'll try submitting it.

But as for DT, I think that's still a bit overkill for RZ/A series.


Chris

On 01/19/2018 06:56 PM, Chris Brandt wrote:
> On Friday, January 19, 2018 1, Marek Vasut wrote:
>> Applied, thanks !
> 
> Thank you!
> 
> 
>> btw. are you planning to do DT/DM conversion of the RZ/A1 ?
> 
> DM, yes.
> DT, no
> 
> We're working on adding DM to RZ/A's I2C and timer drivers now. Then 
> we'll try submitting it.

Cool!

> But as for DT, I think that's still a bit overkill for RZ/A series.

Why so?

On Friday, January 19, 2018, Marek Vasut wrote:
> > But as for DT, I think that's still a bit overkill for RZ/A series.

> 

> Why so?


Honestly, I don't see the value in it for small embedded systems.

u-boot has a specific job and is compiled for a specific board. There is
no need for multi board booting.

I think moving things DM is OK, but that's because it's all done in the 
same code that gets compiled today (no separate build steps).

And...then you have 3 things to customize:
1. config file (legacy .h file)  because not everything is moved into 
   Kconfig
2. menuconfig (for the stuff that has been moved)
3. DT (for a few things)


Chris

On 01/19/2018 07:26 PM, Chris Brandt wrote:
> On Friday, January 19, 2018, Marek Vasut wrote:
>>> But as for DT, I think that's still a bit overkill for RZ/A series.
>>
>> Why so?
> 
> Honestly, I don't see the value in it for small embedded systems.
> 
> u-boot has a specific job and is compiled for a specific board. There is
> no need for multi board booting.

For now at least, it'd be real neat to have one u-boot build for generic
rz/a1 , concatenate DT to it and be done with a board port.

> I think moving things DM is OK, but that's because it's all done in the 
> same code that gets compiled today (no separate build steps).
> 
> And...then you have 3 things to customize:
> 1. config file (legacy .h file)  because not everything is moved into 
>    Kconfig
> 2. menuconfig (for the stuff that has been moved)
> 3. DT (for a few things)
> 
> 
> Chris
>

On Friday, January 19, 2018, Marek Vasut wrote:
> > u-boot has a specific job and is compiled for a specific board. There is

> > no need for multi board booting.

> 

> For now at least, it'd be real neat to have one u-boot build for generic

> rz/a1 , concatenate DT to it and be done with a board port.


I think there is always going to be 'low level weird stuff' specific for
each board, so you'll never be able to do it all with a DT (for an 
actual product that is).

Even in our Linux BSP, I still always have a board-xxx.c file for 
anything not easily handled in DT.


Chris

On 01/20/2018 03:46 AM, Chris Brandt wrote:
> On Friday, January 19, 2018, Marek Vasut wrote:
>>> u-boot has a specific job and is compiled for a specific board. There is
>>> no need for multi board booting.
>>
>> For now at least, it'd be real neat to have one u-boot build for generic
>> rz/a1 , concatenate DT to it and be done with a board port.
> 
> I think there is always going to be 'low level weird stuff' specific for
> each board, so you'll never be able to do it all with a DT (for an 
> actual product that is).
> 
> Even in our Linux BSP, I still always have a board-xxx.c file for 
> anything not easily handled in DT.

I wonder if we really cannot get to the point where we can have a
universal build, add DT to it and be done with a board port. That'd be
real cool and it'd make things easy for people using the chip ... :)

On Friday, January 19, 2018 1, Marek Vasut wrote:
> I wonder if we really cannot get to the point where we can have a

> universal build, add DT to it and be done with a board port. That'd be

> real cool and it'd make things easy for people using the chip ... :)


Then I'd be out of a job!

;)

On 01/20/2018 04:15 PM, Chris Brandt wrote:
> On Friday, January 19, 2018 1, Marek Vasut wrote:
>> I wonder if we really cannot get to the point where we can have a
>> universal build, add DT to it and be done with a board port. That'd be
>> real cool and it'd make things easy for people using the chip ... :)
> 
> Then I'd be out of a job!
> 
> ;)
> 

You can still write the DTs ;-)