Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-11 Thread Jagan Teki 
On 11 February 2016 at 02:30, Christophe Ricard
 wrote:
> Hi Jagan,
>
> My understanding is that some work are ongoing around spl in order to
> support correctly DM for all spi/i2c bus drivers.
> As a consequence patch 4 got differed.
>
> Hopefully Simon or Tom can comment.
>
> Are you ok in applying patch 1 and 2 only ? or should i send a new serie
> with only patch 1 and 2 ?

3/4 looks not good to me with so many ifdef, may we can do something
clear similar to kirkwood_spi does.

>
> On 10/02/2016 20:16, Jagan Teki wrote:
>>
>> On 8 February 2016 at 23:26, Jagan Teki  wrote:
>>>
>>> On 8 February 2016 at 23:10, Tom Rini  wrote:

 On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>
> Hi Simon, Tom,
>
> I assume the approach you are taking is also valuable for the i2c:
> omap24xx patch serie:
> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>
> What are your recommendation about the pending patches ?
> Should i send back only the one not taking care of the DM conversion
> and send another serie later ?
>
> I have seen some work ongoing on this topic on the u-boot-fdt tree
> on the spl-working branch.
> Is there a more accurate place to follow this work ?

 For i2c, aside from needing to defer removing the non-DM code for a
 while yet, there were some review comments to address in a v2 or answer
 as intentional.  For SPI, it's all looking good and I'm assuming Jagan
 will have a SPI PR soon.  Thanks!
>>>
>>> Yes, by this week-end.
>>
>> Any idea 4/4 got differed in patchwork [1], do we have next version
>> patches for these?
>>
>> [1] https://patchwork.ozlabs.org/patch/569241/
>>
> On 26/01/2016 02:55, Peng Fan wrote:
>>
>> Hi Simon,
>>
>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>>
>>> +Hans
>>>
>>> Hi Tom,
>>>
>>> On 21 January 2016 at 05:24, Tom Rini  wrote:

 On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>
> +Mugunthan, Tom
>
> On 17 January 2016 at 03:56, Christophe Ricard
>  wrote:
>>
>> Convert omap3_spi driver to DM and keep compatibility with
>> previous
>> mode.
>>
>> Signed-off-by: Christophe Ricard 
>> ---
>>
>>   drivers/spi/Kconfig |   6 +
>>   drivers/spi/omap3_spi.c | 439
>> ++--
>>   drivers/spi/omap3_spi.h |  14 +-
>>   3 files changed, 402 insertions(+), 57 deletions(-)
>
> This is a pretty painful conversion, with lots of #ifdefs. I think
> it
> would be possible to use a common pointer type and reduce this.
>
> But perhaps it does not matter - how long must we be in the state
> of
> supporting legacy SPI? Can we convert all TI boards to driver
> model?

 We _really_ need some way to support more than one board per binary
 before we can move everything to DM only.

 I think we can kind of do this today if we stick to using platform
 data
 for everything that's board-specific rather than SoC-defined.  What
 we
 talked about at ELCE was auto-generating the pdata from the device
 tree,
 I think.
>>>
>>> We discussed this on IRC but since that doesn't exist as far as the
>>> mailing list is concerned...
>>>
>>> The current plan is:
>>>
>>> - Adjust build system to optionally build a u-boot.img in FIT format
>>> that includes the U-Boot binary and >1 device tree files
>>> - Adjust SPL to load this
>>> - Add a way for SPL to determine which device tree to select (by
>>> calling a board-specific function)
>>> - Have SPL pass this selected device tree to U-Boot when it starts
>>
>> Can dtb be sperated from the final u-boot.img, if using SPL?
>> I mean let SPL load the u-boot.img and the dtb to correct DRAM
>> address.
>> And the dtb is shared with linux kernel.
>>
>> Regards,
>> Peng.
>>>
>>> Thus we should be able to support more than one board with a single
>>> U-Boot image. Of course this is not a perfect solution (e.g. it is
>>> inefficient since the DTs are likely to be largely the same) but it
>>> should be a good first step.
>>>
>>> I'm going to try this out with sunxi initially and plan to get some
>>> patches out by the end of the week.
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Jagan.
___
U-Boot mailing list

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-11 Thread Jagan Teki 
On 11 February 2016 at 20:31, Jagan Teki  wrote:
> On 11 February 2016 at 02:30, Christophe Ricard
>  wrote:
>> Hi Jagan,
>>
>> My understanding is that some work are ongoing around spl in order to
>> support correctly DM for all spi/i2c bus drivers.
>> As a consequence patch 4 got differed.
>>
>> Hopefully Simon or Tom can comment.
>>
>> Are you ok in applying patch 1 and 2 only ? or should i send a new serie
>> with only patch 1 and 2 ?
>
> 3/4 looks not good to me with so many ifdef, may we can do something
> clear similar to kirkwood_spi does.

I did some dm conversion on these long back which looks similar like
kirkwood_spi, will post them as well so-that we can discuss.

>
>>
>> On 10/02/2016 20:16, Jagan Teki wrote:
>>>
>>> On 8 February 2016 at 23:26, Jagan Teki  wrote:

 On 8 February 2016 at 23:10, Tom Rini  wrote:
>
> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>
>> Hi Simon, Tom,
>>
>> I assume the approach you are taking is also valuable for the i2c:
>> omap24xx patch serie:
>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>
>> What are your recommendation about the pending patches ?
>> Should i send back only the one not taking care of the DM conversion
>> and send another serie later ?
>>
>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>> on the spl-working branch.
>> Is there a more accurate place to follow this work ?
>
> For i2c, aside from needing to defer removing the non-DM code for a
> while yet, there were some review comments to address in a v2 or answer
> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> will have a SPI PR soon.  Thanks!

 Yes, by this week-end.
>>>
>>> Any idea 4/4 got differed in patchwork [1], do we have next version
>>> patches for these?
>>>
>>> [1] https://patchwork.ozlabs.org/patch/569241/
>>>
>> On 26/01/2016 02:55, Peng Fan wrote:
>>>
>>> Hi Simon,
>>>
>>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:

 +Hans

 Hi Tom,

 On 21 January 2016 at 05:24, Tom Rini  wrote:
>
> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>
>> +Mugunthan, Tom
>>
>> On 17 January 2016 at 03:56, Christophe Ricard
>>  wrote:
>>>
>>> Convert omap3_spi driver to DM and keep compatibility with
>>> previous
>>> mode.
>>>
>>> Signed-off-by: Christophe Ricard 
>>> ---
>>>
>>>   drivers/spi/Kconfig |   6 +
>>>   drivers/spi/omap3_spi.c | 439
>>> ++--
>>>   drivers/spi/omap3_spi.h |  14 +-
>>>   3 files changed, 402 insertions(+), 57 deletions(-)
>>
>> This is a pretty painful conversion, with lots of #ifdefs. I think
>> it
>> would be possible to use a common pointer type and reduce this.
>>
>> But perhaps it does not matter - how long must we be in the state
>> of
>> supporting legacy SPI? Can we convert all TI boards to driver
>> model?
>
> We _really_ need some way to support more than one board per binary
> before we can move everything to DM only.
>
> I think we can kind of do this today if we stick to using platform
> data
> for everything that's board-specific rather than SoC-defined.  What
> we
> talked about at ELCE was auto-generating the pdata from the device
> tree,
> I think.

 We discussed this on IRC but since that doesn't exist as far as the
 mailing list is concerned...

 The current plan is:

 - Adjust build system to optionally build a u-boot.img in FIT format
 that includes the U-Boot binary and >1 device tree files
 - Adjust SPL to load this
 - Add a way for SPL to determine which device tree to select (by
 calling a board-specific function)
 - Have SPL pass this selected device tree to U-Boot when it starts
>>>
>>> Can dtb be sperated from the final u-boot.img, if using SPL?
>>> I mean let SPL load the u-boot.img and the dtb to correct DRAM
>>> address.
>>> And the dtb is shared with linux kernel.
>>>
>>> Regards,
>>> Peng.

 Thus we should be able to support more than one board with a single
 U-Boot image. Of course this is not a perfect solution (e.g. it is
 inefficient since the DTs are likely to be largely the same) but it
 should be a good first step.

 I'm going to try this

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-10 Thread Jagan Teki 
On 8 February 2016 at 23:26, Jagan Teki  wrote:
> On 8 February 2016 at 23:10, Tom Rini  wrote:
>> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>>> Hi Simon, Tom,
>>>
>>> I assume the approach you are taking is also valuable for the i2c:
>>> omap24xx patch serie:
>>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>>
>>> What are your recommendation about the pending patches ?
>>> Should i send back only the one not taking care of the DM conversion
>>> and send another serie later ?
>>>
>>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>>> on the spl-working branch.
>>> Is there a more accurate place to follow this work ?
>>
>> For i2c, aside from needing to defer removing the non-DM code for a
>> while yet, there were some review comments to address in a v2 or answer
>> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
>> will have a SPI PR soon.  Thanks!
>
> Yes, by this week-end.

Any idea 4/4 got differed in patchwork [1], do we have next version
patches for these?

[1] https://patchwork.ozlabs.org/patch/569241/

>
>>>
>>> On 26/01/2016 02:55, Peng Fan wrote:
>>> >Hi Simon,
>>> >
>>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>> >>+Hans
>>> >>
>>> >>Hi Tom,
>>> >>
>>> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
>>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>> +Mugunthan, Tom
>>> 
>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>  wrote:
>>> >Convert omap3_spi driver to DM and keep compatibility with previous
>>> >mode.
>>> >
>>> >Signed-off-by: Christophe Ricard 
>>> >---
>>> >
>>> >  drivers/spi/Kconfig |   6 +
>>> >  drivers/spi/omap3_spi.c | 439 
>>> > ++--
>>> >  drivers/spi/omap3_spi.h |  14 +-
>>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>> would be possible to use a common pointer type and reduce this.
>>> 
>>> But perhaps it does not matter - how long must we be in the state of
>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>> >>>We _really_ need some way to support more than one board per binary
>>> >>>before we can move everything to DM only.
>>> >>>
>>> >>>I think we can kind of do this today if we stick to using platform data
>>> >>>for everything that's board-specific rather than SoC-defined.  What we
>>> >>>talked about at ELCE was auto-generating the pdata from the device tree,
>>> >>>I think.
>>> >>We discussed this on IRC but since that doesn't exist as far as the
>>> >>mailing list is concerned...
>>> >>
>>> >>The current plan is:
>>> >>
>>> >>- Adjust build system to optionally build a u-boot.img in FIT format
>>> >>that includes the U-Boot binary and >1 device tree files
>>> >>- Adjust SPL to load this
>>> >>- Add a way for SPL to determine which device tree to select (by
>>> >>calling a board-specific function)
>>> >>- Have SPL pass this selected device tree to U-Boot when it starts
>>> >Can dtb be sperated from the final u-boot.img, if using SPL?
>>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>>> >And the dtb is shared with linux kernel.
>>> >
>>> >Regards,
>>> >Peng.
>>> >>Thus we should be able to support more than one board with a single
>>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
>>> >>inefficient since the DTs are likely to be largely the same) but it
>>> >>should be a good first step.
>>> >>
>>> >>I'm going to try this out with sunxi initially and plan to get some
>>> >>patches out by the end of the week.

-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-10 Thread Christophe Ricard 

Hi Jagan,

My understanding is that some work are ongoing around spl in order to 
support correctly DM for all spi/i2c bus drivers.

As a consequence patch 4 got differed.

Hopefully Simon or Tom can comment.

Are you ok in applying patch 1 and 2 only ? or should i send a new serie 
with only patch 1 and 2 ?


Best Regards
Christophe

On 10/02/2016 20:16, Jagan Teki wrote:

On 8 February 2016 at 23:26, Jagan Teki  wrote:

On 8 February 2016 at 23:10, Tom Rini  wrote:

On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:

Hi Simon, Tom,

I assume the approach you are taking is also valuable for the i2c:
omap24xx patch serie:
http://lists.denx.de/pipermail/u-boot/2016-January/241676.html

What are your recommendation about the pending patches ?
Should i send back only the one not taking care of the DM conversion
and send another serie later ?

I have seen some work ongoing on this topic on the u-boot-fdt tree
on the spl-working branch.
Is there a more accurate place to follow this work ?

For i2c, aside from needing to defer removing the non-DM code for a
while yet, there were some review comments to address in a v2 or answer
as intentional.  For SPI, it's all looking good and I'm assuming Jagan
will have a SPI PR soon.  Thanks!

Yes, by this week-end.

Any idea 4/4 got differed in patchwork [1], do we have next version
patches for these?

[1] https://patchwork.ozlabs.org/patch/569241/


On 26/01/2016 02:55, Peng Fan wrote:

Hi Simon,

On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:

+Hans

Hi Tom,

On 21 January 2016 at 05:24, Tom Rini  wrote:

On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:

+Mugunthan, Tom

On 17 January 2016 at 03:56, Christophe Ricard
 wrote:

Convert omap3_spi driver to DM and keep compatibility with previous
mode.

Signed-off-by: Christophe Ricard 
---

  drivers/spi/Kconfig |   6 +
  drivers/spi/omap3_spi.c | 439 ++--
  drivers/spi/omap3_spi.h |  14 +-
  3 files changed, 402 insertions(+), 57 deletions(-)

This is a pretty painful conversion, with lots of #ifdefs. I think it
would be possible to use a common pointer type and reduce this.

But perhaps it does not matter - how long must we be in the state of
supporting legacy SPI? Can we convert all TI boards to driver model?

We _really_ need some way to support more than one board per binary
before we can move everything to DM only.

I think we can kind of do this today if we stick to using platform data
for everything that's board-specific rather than SoC-defined.  What we
talked about at ELCE was auto-generating the pdata from the device tree,
I think.

We discussed this on IRC but since that doesn't exist as far as the
mailing list is concerned...

The current plan is:

- Adjust build system to optionally build a u-boot.img in FIT format
that includes the U-Boot binary and >1 device tree files
- Adjust SPL to load this
- Add a way for SPL to determine which device tree to select (by
calling a board-specific function)
- Have SPL pass this selected device tree to U-Boot when it starts

Can dtb be sperated from the final u-boot.img, if using SPL?
I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
And the dtb is shared with linux kernel.

Regards,
Peng.

Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.

I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-10 Thread Tom Rini 
On Wed, Feb 10, 2016 at 10:00:55PM +0100, Christophe Ricard wrote:

> Hi Jagan,
> 
> My understanding is that some work are ongoing around spl in order
> to support correctly DM for all spi/i2c bus drivers.
> As a consequence patch 4 got differed.
>
> Hopefully Simon or Tom can comment.

Yes, I deferred 4/4 because until we convert all of the platforms to DM
(and Simon is making progress on what's required there).

> Are you ok in applying patch 1 and 2 only ? or should i send a new
> serie with only patch 1 and 2 ?

1, 2 and 3? should be fine to go now and you shouldn't need to re-send
them.

> 
> Best Regards
> Christophe
> 
> On 10/02/2016 20:16, Jagan Teki wrote:
> >On 8 February 2016 at 23:26, Jagan Teki  wrote:
> >>On 8 February 2016 at 23:10, Tom Rini  wrote:
> >>>On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> Hi Simon, Tom,
> 
> I assume the approach you are taking is also valuable for the i2c:
> omap24xx patch serie:
> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> 
> What are your recommendation about the pending patches ?
> Should i send back only the one not taking care of the DM conversion
> and send another serie later ?
> 
> I have seen some work ongoing on this topic on the u-boot-fdt tree
> on the spl-working branch.
> Is there a more accurate place to follow this work ?
> >>>For i2c, aside from needing to defer removing the non-DM code for a
> >>>while yet, there were some review comments to address in a v2 or answer
> >>>as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> >>>will have a SPI PR soon.  Thanks!
> >>Yes, by this week-end.
> >Any idea 4/4 got differed in patchwork [1], do we have next version
> >patches for these?
> >
> >[1] https://patchwork.ozlabs.org/patch/569241/
> >
> On 26/01/2016 02:55, Peng Fan wrote:
> >Hi Simon,
> >
> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >>+Hans
> >>
> >>Hi Tom,
> >>
> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> +Mugunthan, Tom
> 
> On 17 January 2016 at 03:56, Christophe Ricard
>  wrote:
> >Convert omap3_spi driver to DM and keep compatibility with previous
> >mode.
> >
> >Signed-off-by: Christophe Ricard 
> >---
> >
> >  drivers/spi/Kconfig |   6 +
> >  drivers/spi/omap3_spi.c | 439 
> > ++--
> >  drivers/spi/omap3_spi.h |  14 +-
> >  3 files changed, 402 insertions(+), 57 deletions(-)
> This is a pretty painful conversion, with lots of #ifdefs. I think it
> would be possible to use a common pointer type and reduce this.
> 
> But perhaps it does not matter - how long must we be in the state of
> supporting legacy SPI? Can we convert all TI boards to driver model?
> >>>We _really_ need some way to support more than one board per binary
> >>>before we can move everything to DM only.
> >>>
> >>>I think we can kind of do this today if we stick to using platform data
> >>>for everything that's board-specific rather than SoC-defined.  What we
> >>>talked about at ELCE was auto-generating the pdata from the device 
> >>>tree,
> >>>I think.
> >>We discussed this on IRC but since that doesn't exist as far as the
> >>mailing list is concerned...
> >>
> >>The current plan is:
> >>
> >>- Adjust build system to optionally build a u-boot.img in FIT format
> >>that includes the U-Boot binary and >1 device tree files
> >>- Adjust SPL to load this
> >>- Add a way for SPL to determine which device tree to select (by
> >>calling a board-specific function)
> >>- Have SPL pass this selected device tree to U-Boot when it starts
> >Can dtb be sperated from the final u-boot.img, if using SPL?
> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >And the dtb is shared with linux kernel.
> >
> >Regards,
> >Peng.
> >>Thus we should be able to support more than one board with a single
> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
> >>inefficient since the DTs are likely to be largely the same) but it
> >>should be a good first step.
> >>
> >>I'm going to try this out with sunxi initially and plan to get some
> >>patches out by the end of the week.
> 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-08 Thread Tom Rini 
On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
> Hi Simon, Tom,
> 
> I assume the approach you are taking is also valuable for the i2c:
> omap24xx patch serie:
> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
> 
> What are your recommendation about the pending patches ?
> Should i send back only the one not taking care of the DM conversion
> and send another serie later ?
> 
> I have seen some work ongoing on this topic on the u-boot-fdt tree
> on the spl-working branch.
> Is there a more accurate place to follow this work ?

For i2c, aside from needing to defer removing the non-DM code for a
while yet, there were some review comments to address in a v2 or answer
as intentional.  For SPI, it's all looking good and I'm assuming Jagan
will have a SPI PR soon.  Thanks!

> 
> Best Regards
> Christophe
> 
> On 26/01/2016 02:55, Peng Fan wrote:
> >Hi Simon,
> >
> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >>+Hans
> >>
> >>Hi Tom,
> >>
> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> +Mugunthan, Tom
> 
> On 17 January 2016 at 03:56, Christophe Ricard
>  wrote:
> >Convert omap3_spi driver to DM and keep compatibility with previous
> >mode.
> >
> >Signed-off-by: Christophe Ricard 
> >---
> >
> >  drivers/spi/Kconfig |   6 +
> >  drivers/spi/omap3_spi.c | 439 
> > ++--
> >  drivers/spi/omap3_spi.h |  14 +-
> >  3 files changed, 402 insertions(+), 57 deletions(-)
> This is a pretty painful conversion, with lots of #ifdefs. I think it
> would be possible to use a common pointer type and reduce this.
> 
> But perhaps it does not matter - how long must we be in the state of
> supporting legacy SPI? Can we convert all TI boards to driver model?
> >>>We _really_ need some way to support more than one board per binary
> >>>before we can move everything to DM only.
> >>>
> >>>I think we can kind of do this today if we stick to using platform data
> >>>for everything that's board-specific rather than SoC-defined.  What we
> >>>talked about at ELCE was auto-generating the pdata from the device tree,
> >>>I think.
> >>We discussed this on IRC but since that doesn't exist as far as the
> >>mailing list is concerned...
> >>
> >>The current plan is:
> >>
> >>- Adjust build system to optionally build a u-boot.img in FIT format
> >>that includes the U-Boot binary and >1 device tree files
> >>- Adjust SPL to load this
> >>- Add a way for SPL to determine which device tree to select (by
> >>calling a board-specific function)
> >>- Have SPL pass this selected device tree to U-Boot when it starts
> >Can dtb be sperated from the final u-boot.img, if using SPL?
> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >And the dtb is shared with linux kernel.
> >
> >Regards,
> >Peng.
> >>Thus we should be able to support more than one board with a single
> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
> >>inefficient since the DTs are likely to be largely the same) but it
> >>should be a good first step.
> >>
> >>I'm going to try this out with sunxi initially and plan to get some
> >>patches out by the end of the week.
> >>
> >>Regards,
> >>Simon
> >>___
> >>U-Boot mailing list
> >>U-Boot@lists.denx.de
> >>http://lists.denx.de/mailman/listinfo/u-boot
> 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-08 Thread Jagan Teki 
On 8 February 2016 at 23:10, Tom Rini  wrote:
> On Sat, Feb 06, 2016 at 11:27:21PM +0100, Christophe Ricard wrote:
>> Hi Simon, Tom,
>>
>> I assume the approach you are taking is also valuable for the i2c:
>> omap24xx patch serie:
>> http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
>>
>> What are your recommendation about the pending patches ?
>> Should i send back only the one not taking care of the DM conversion
>> and send another serie later ?
>>
>> I have seen some work ongoing on this topic on the u-boot-fdt tree
>> on the spl-working branch.
>> Is there a more accurate place to follow this work ?
>
> For i2c, aside from needing to defer removing the non-DM code for a
> while yet, there were some review comments to address in a v2 or answer
> as intentional.  For SPI, it's all looking good and I'm assuming Jagan
> will have a SPI PR soon.  Thanks!

Yes, by this week-end.

>>
>> On 26/01/2016 02:55, Peng Fan wrote:
>> >Hi Simon,
>> >
>> >On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >>+Hans
>> >>
>> >>Hi Tom,
>> >>
>> >>On 21 January 2016 at 05:24, Tom Rini  wrote:
>> >>>On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> +Mugunthan, Tom
>> 
>> On 17 January 2016 at 03:56, Christophe Ricard
>>  wrote:
>> >Convert omap3_spi driver to DM and keep compatibility with previous
>> >mode.
>> >
>> >Signed-off-by: Christophe Ricard 
>> >---
>> >
>> >  drivers/spi/Kconfig |   6 +
>> >  drivers/spi/omap3_spi.c | 439 
>> > ++--
>> >  drivers/spi/omap3_spi.h |  14 +-
>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> would be possible to use a common pointer type and reduce this.
>> 
>> But perhaps it does not matter - how long must we be in the state of
>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >>>We _really_ need some way to support more than one board per binary
>> >>>before we can move everything to DM only.
>> >>>
>> >>>I think we can kind of do this today if we stick to using platform data
>> >>>for everything that's board-specific rather than SoC-defined.  What we
>> >>>talked about at ELCE was auto-generating the pdata from the device tree,
>> >>>I think.
>> >>We discussed this on IRC but since that doesn't exist as far as the
>> >>mailing list is concerned...
>> >>
>> >>The current plan is:
>> >>
>> >>- Adjust build system to optionally build a u-boot.img in FIT format
>> >>that includes the U-Boot binary and >1 device tree files
>> >>- Adjust SPL to load this
>> >>- Add a way for SPL to determine which device tree to select (by
>> >>calling a board-specific function)
>> >>- Have SPL pass this selected device tree to U-Boot when it starts
>> >Can dtb be sperated from the final u-boot.img, if using SPL?
>> >I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> >And the dtb is shared with linux kernel.
>> >
>> >Regards,
>> >Peng.
>> >>Thus we should be able to support more than one board with a single
>> >>U-Boot image. Of course this is not a perfect solution (e.g. it is
>> >>inefficient since the DTs are likely to be largely the same) but it
>> >>should be a good first step.
>> >>
>> >>I'm going to try this out with sunxi initially and plan to get some
>> >>patches out by the end of the week.

-- 
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-02-06 Thread Christophe Ricard 

Hi Simon, Tom,

I assume the approach you are taking is also valuable for the i2c: 
omap24xx patch serie:

http://lists.denx.de/pipermail/u-boot/2016-January/241676.html

What are your recommendation about the pending patches ?
Should i send back only the one not taking care of the DM conversion and 
send another serie later ?


I have seen some work ongoing on this topic on the u-boot-fdt tree on 
the spl-working branch.

Is there a more accurate place to follow this work ?

Best Regards
Christophe

On 26/01/2016 02:55, Peng Fan wrote:

Hi Simon,

On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:

+Hans

Hi Tom,

On 21 January 2016 at 05:24, Tom Rini  wrote:

On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:

+Mugunthan, Tom

On 17 January 2016 at 03:56, Christophe Ricard
 wrote:

Convert omap3_spi driver to DM and keep compatibility with previous
mode.

Signed-off-by: Christophe Ricard 
---

  drivers/spi/Kconfig |   6 +
  drivers/spi/omap3_spi.c | 439 ++--
  drivers/spi/omap3_spi.h |  14 +-
  3 files changed, 402 insertions(+), 57 deletions(-)

This is a pretty painful conversion, with lots of #ifdefs. I think it
would be possible to use a common pointer type and reduce this.

But perhaps it does not matter - how long must we be in the state of
supporting legacy SPI? Can we convert all TI boards to driver model?

We _really_ need some way to support more than one board per binary
before we can move everything to DM only.

I think we can kind of do this today if we stick to using platform data
for everything that's board-specific rather than SoC-defined.  What we
talked about at ELCE was auto-generating the pdata from the device tree,
I think.

We discussed this on IRC but since that doesn't exist as far as the
mailing list is concerned...

The current plan is:

- Adjust build system to optionally build a u-boot.img in FIT format
that includes the U-Boot binary and >1 device tree files
- Adjust SPL to load this
- Add a way for SPL to determine which device tree to select (by
calling a board-specific function)
- Have SPL pass this selected device tree to U-Boot when it starts

Can dtb be sperated from the final u-boot.img, if using SPL?
I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
And the dtb is shared with linux kernel.

Regards,
Peng.

Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.

I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-26 Thread Tom Rini 
On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote:
> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
> >> Hi Simon,
> >> 
> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >> >+Hans
> >> >
> >> >Hi Tom,
> >> >
> >> >On 21 January 2016 at 05:24, Tom Rini  wrote:
> >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >> >>> +Mugunthan, Tom
> >> >>>
> >> >>> On 17 January 2016 at 03:56, Christophe Ricard
> >> >>>  wrote:
> >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
> >> >>> > mode.
> >> >>> >
> >> >>> > Signed-off-by: Christophe Ricard 
> >> >>> > ---
> >> >>> >
> >> >>> >  drivers/spi/Kconfig |   6 +
> >> >>> >  drivers/spi/omap3_spi.c | 439 
> >> >>> > ++--
> >> >>> >  drivers/spi/omap3_spi.h |  14 +-
> >> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
> >> >>>
> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
> >> >>> would be possible to use a common pointer type and reduce this.
> >> >>>
> >> >>> But perhaps it does not matter - how long must we be in the state of
> >> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
> >> >>
> >> >> We _really_ need some way to support more than one board per binary
> >> >> before we can move everything to DM only.
> >> >>
> >> >> I think we can kind of do this today if we stick to using platform data
> >> >> for everything that's board-specific rather than SoC-defined.  What we
> >> >> talked about at ELCE was auto-generating the pdata from the device tree,
> >> >> I think.
> >> >
> >> >We discussed this on IRC but since that doesn't exist as far as the
> >> >mailing list is concerned...
> >> >
> >> >The current plan is:
> >> >
> >> >- Adjust build system to optionally build a u-boot.img in FIT format
> >> >that includes the U-Boot binary and >1 device tree files
> >> >- Adjust SPL to load this
> >> >- Add a way for SPL to determine which device tree to select (by
> >> >calling a board-specific function)
> >> >- Have SPL pass this selected device tree to U-Boot when it starts
> >> 
> >> Can dtb be sperated from the final u-boot.img, if using SPL?
> >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> >> And the dtb is shared with linux kernel.
> >
> >This sounds similar, but different.  The problem I'm asking to be solved
> >is that at the starting point, there are no DTBs on the hardware.  But
> 
> Oh. Thanks for explanation.
> 
> >we can in software easily and reliable tell which of say 3 boards we are
> >on.  At that point, we need to make sure that both SPL and then U-Boot
> >know which board they are on.  And if in U-Boot we use the DT to pass in
> >all data, it has to be correct.  It sounds to me like you're describing
> >the case where the HW has the dtb stored at a known location and you
> >just don't need it embedded within SPL/U-Boot.
> 
> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.

Can you explain how this would work, or the use case for it?  We can't
always assume we're reading u-boot.img off FAT for example.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-26 Thread Peng Fan 
On Tue, Jan 26, 2016 at 10:12:10AM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote:
>> On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
>> >On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
>> >> Hi Simon,
>> >> 
>> >> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >> >+Hans
>> >> >
>> >> >Hi Tom,
>> >> >
>> >> >On 21 January 2016 at 05:24, Tom Rini  wrote:
>> >> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> >> >>> +Mugunthan, Tom
>> >> >>>
>> >> >>> On 17 January 2016 at 03:56, Christophe Ricard
>> >> >>>  wrote:
>> >> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> >> >>> > mode.
>> >> >>> >
>> >> >>> > Signed-off-by: Christophe Ricard 
>> >> >>> > ---
>> >> >>> >
>> >> >>> >  drivers/spi/Kconfig |   6 +
>> >> >>> >  drivers/spi/omap3_spi.c | 439 
>> >> >>> > ++--
>> >> >>> >  drivers/spi/omap3_spi.h |  14 +-
>> >> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> >> >>>
>> >> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> >> >>> would be possible to use a common pointer type and reduce this.
>> >> >>>
>> >> >>> But perhaps it does not matter - how long must we be in the state of
>> >> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >> >>
>> >> >> We _really_ need some way to support more than one board per binary
>> >> >> before we can move everything to DM only.
>> >> >>
>> >> >> I think we can kind of do this today if we stick to using platform data
>> >> >> for everything that's board-specific rather than SoC-defined.  What we
>> >> >> talked about at ELCE was auto-generating the pdata from the device 
>> >> >> tree,
>> >> >> I think.
>> >> >
>> >> >We discussed this on IRC but since that doesn't exist as far as the
>> >> >mailing list is concerned...
>> >> >
>> >> >The current plan is:
>> >> >
>> >> >- Adjust build system to optionally build a u-boot.img in FIT format
>> >> >that includes the U-Boot binary and >1 device tree files
>> >> >- Adjust SPL to load this
>> >> >- Add a way for SPL to determine which device tree to select (by
>> >> >calling a board-specific function)
>> >> >- Have SPL pass this selected device tree to U-Boot when it starts
>> >> 
>> >> Can dtb be sperated from the final u-boot.img, if using SPL?
>> >> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> >> And the dtb is shared with linux kernel.
>> >
>> >This sounds similar, but different.  The problem I'm asking to be solved
>> >is that at the starting point, there are no DTBs on the hardware.  But
>> 
>> Oh. Thanks for explanation.
>> 
>> >we can in software easily and reliable tell which of say 3 boards we are
>> >on.  At that point, we need to make sure that both SPL and then U-Boot
>> >know which board they are on.  And if in U-Boot we use the DT to pass in
>> >all data, it has to be correct.  It sounds to me like you're describing
>> >the case where the HW has the dtb stored at a known location and you
>> >just don't need it embedded within SPL/U-Boot.
>> 
>> Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.
>
>Can you explain how this would work, or the use case for it?  We can't
>always assume we're reading u-boot.img off FAT for example.

I have no idea on this for now (:.

Regards,
Peng.

>
>-- 
>Tom


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-25 Thread Peng Fan 
Hi Simon,

On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>+Hans
>
>Hi Tom,
>
>On 21 January 2016 at 05:24, Tom Rini  wrote:
>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>>> +Mugunthan, Tom
>>>
>>> On 17 January 2016 at 03:56, Christophe Ricard
>>>  wrote:
>>> > Convert omap3_spi driver to DM and keep compatibility with previous
>>> > mode.
>>> >
>>> > Signed-off-by: Christophe Ricard 
>>> > ---
>>> >
>>> >  drivers/spi/Kconfig |   6 +
>>> >  drivers/spi/omap3_spi.c | 439 
>>> > ++--
>>> >  drivers/spi/omap3_spi.h |  14 +-
>>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>>
>>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>>> would be possible to use a common pointer type and reduce this.
>>>
>>> But perhaps it does not matter - how long must we be in the state of
>>> supporting legacy SPI? Can we convert all TI boards to driver model?
>>
>> We _really_ need some way to support more than one board per binary
>> before we can move everything to DM only.
>>
>> I think we can kind of do this today if we stick to using platform data
>> for everything that's board-specific rather than SoC-defined.  What we
>> talked about at ELCE was auto-generating the pdata from the device tree,
>> I think.
>
>We discussed this on IRC but since that doesn't exist as far as the
>mailing list is concerned...
>
>The current plan is:
>
>- Adjust build system to optionally build a u-boot.img in FIT format
>that includes the U-Boot binary and >1 device tree files
>- Adjust SPL to load this
>- Add a way for SPL to determine which device tree to select (by
>calling a board-specific function)
>- Have SPL pass this selected device tree to U-Boot when it starts

Can dtb be sperated from the final u-boot.img, if using SPL?
I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
And the dtb is shared with linux kernel.

Regards,
Peng.
>
>Thus we should be able to support more than one board with a single
>U-Boot image. Of course this is not a perfect solution (e.g. it is
>inefficient since the DTs are likely to be largely the same) but it
>should be a good first step.
>
>I'm going to try this out with sunxi initially and plan to get some
>patches out by the end of the week.
>
>Regards,
>Simon
>___
>U-Boot mailing list
>U-Boot@lists.denx.de
>http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-25 Thread Simon Glass 
+Hans

Hi Tom,

On 21 January 2016 at 05:24, Tom Rini  wrote:
> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> +Mugunthan, Tom
>>
>> On 17 January 2016 at 03:56, Christophe Ricard
>>  wrote:
>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> > mode.
>> >
>> > Signed-off-by: Christophe Ricard 
>> > ---
>> >
>> >  drivers/spi/Kconfig |   6 +
>> >  drivers/spi/omap3_spi.c | 439 
>> > ++--
>> >  drivers/spi/omap3_spi.h |  14 +-
>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>>
>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> would be possible to use a common pointer type and reduce this.
>>
>> But perhaps it does not matter - how long must we be in the state of
>> supporting legacy SPI? Can we convert all TI boards to driver model?
>
> We _really_ need some way to support more than one board per binary
> before we can move everything to DM only.
>
> I think we can kind of do this today if we stick to using platform data
> for everything that's board-specific rather than SoC-defined.  What we
> talked about at ELCE was auto-generating the pdata from the device tree,
> I think.

We discussed this on IRC but since that doesn't exist as far as the
mailing list is concerned...

The current plan is:

- Adjust build system to optionally build a u-boot.img in FIT format
that includes the U-Boot binary and >1 device tree files
- Adjust SPL to load this
- Add a way for SPL to determine which device tree to select (by
calling a board-specific function)
- Have SPL pass this selected device tree to U-Boot when it starts

Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.

I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-25 Thread Simon Glass 
Hi Peng,

On 25 January 2016 at 18:55, Peng Fan  wrote:
> Hi Simon,
>
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>>+Hans
>>
>>Hi Tom,
>>
>>On 21 January 2016 at 05:24, Tom Rini  wrote:
>>> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
 +Mugunthan, Tom

 On 17 January 2016 at 03:56, Christophe Ricard
  wrote:
 > Convert omap3_spi driver to DM and keep compatibility with previous
 > mode.
 >
 > Signed-off-by: Christophe Ricard 
 > ---
 >
 >  drivers/spi/Kconfig |   6 +
 >  drivers/spi/omap3_spi.c | 439 
 > ++--
 >  drivers/spi/omap3_spi.h |  14 +-
 >  3 files changed, 402 insertions(+), 57 deletions(-)

 This is a pretty painful conversion, with lots of #ifdefs. I think it
 would be possible to use a common pointer type and reduce this.

 But perhaps it does not matter - how long must we be in the state of
 supporting legacy SPI? Can we convert all TI boards to driver model?
>>>
>>> We _really_ need some way to support more than one board per binary
>>> before we can move everything to DM only.
>>>
>>> I think we can kind of do this today if we stick to using platform data
>>> for everything that's board-specific rather than SoC-defined.  What we
>>> talked about at ELCE was auto-generating the pdata from the device tree,
>>> I think.
>>
>>We discussed this on IRC but since that doesn't exist as far as the
>>mailing list is concerned...
>>
>>The current plan is:
>>
>>- Adjust build system to optionally build a u-boot.img in FIT format
>>that includes the U-Boot binary and >1 device tree files
>>- Adjust SPL to load this
>>- Add a way for SPL to determine which device tree to select (by
>>calling a board-specific function)
>>- Have SPL pass this selected device tree to U-Boot when it starts
>
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.

The way I have it is that u-boot.img include U-Boot and multiple .dtb
files. Then SPL selects the correct one and passes it to U-Boot.

It could be passed to the kernel also, but then you would need to
upgrade your firmware to upgrade your kernel. If that's what you want,
it would not be hard to implement. But I am not planning that for this
work - it seems like a separate feature to me.

>
> Regards,
> Peng.
>>
>>Thus we should be able to support more than one board with a single
>>U-Boot image. Of course this is not a perfect solution (e.g. it is
>>inefficient since the DTs are likely to be largely the same) but it
>>should be a good first step.
>>
>>I'm going to try this out with sunxi initially and plan to get some
>>patches out by the end of the week.
>>
>>Regards,
>>Simon

Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-25 Thread Tom Rini 
On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
> Hi Simon,
> 
> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
> >+Hans
> >
> >Hi Tom,
> >
> >On 21 January 2016 at 05:24, Tom Rini  wrote:
> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> >>> +Mugunthan, Tom
> >>>
> >>> On 17 January 2016 at 03:56, Christophe Ricard
> >>>  wrote:
> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
> >>> > mode.
> >>> >
> >>> > Signed-off-by: Christophe Ricard 
> >>> > ---
> >>> >
> >>> >  drivers/spi/Kconfig |   6 +
> >>> >  drivers/spi/omap3_spi.c | 439 
> >>> > ++--
> >>> >  drivers/spi/omap3_spi.h |  14 +-
> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
> >>>
> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
> >>> would be possible to use a common pointer type and reduce this.
> >>>
> >>> But perhaps it does not matter - how long must we be in the state of
> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
> >>
> >> We _really_ need some way to support more than one board per binary
> >> before we can move everything to DM only.
> >>
> >> I think we can kind of do this today if we stick to using platform data
> >> for everything that's board-specific rather than SoC-defined.  What we
> >> talked about at ELCE was auto-generating the pdata from the device tree,
> >> I think.
> >
> >We discussed this on IRC but since that doesn't exist as far as the
> >mailing list is concerned...
> >
> >The current plan is:
> >
> >- Adjust build system to optionally build a u-boot.img in FIT format
> >that includes the U-Boot binary and >1 device tree files
> >- Adjust SPL to load this
> >- Add a way for SPL to determine which device tree to select (by
> >calling a board-specific function)
> >- Have SPL pass this selected device tree to U-Boot when it starts
> 
> Can dtb be sperated from the final u-boot.img, if using SPL?
> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
> And the dtb is shared with linux kernel.

This sounds similar, but different.  The problem I'm asking to be solved
is that at the starting point, there are no DTBs on the hardware.  But
we can in software easily and reliable tell which of say 3 boards we are
on.  At that point, we need to make sure that both SPL and then U-Boot
know which board they are on.  And if in U-Boot we use the DT to pass in
all data, it has to be correct.  It sounds to me like you're describing
the case where the HW has the dtb stored at a known location and you
just don't need it embedded within SPL/U-Boot.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-25 Thread Peng Fan 
On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote:
>On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote:
>> Hi Simon,
>> 
>> On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote:
>> >+Hans
>> >
>> >Hi Tom,
>> >
>> >On 21 January 2016 at 05:24, Tom Rini  wrote:
>> >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
>> >>> +Mugunthan, Tom
>> >>>
>> >>> On 17 January 2016 at 03:56, Christophe Ricard
>> >>>  wrote:
>> >>> > Convert omap3_spi driver to DM and keep compatibility with previous
>> >>> > mode.
>> >>> >
>> >>> > Signed-off-by: Christophe Ricard 
>> >>> > ---
>> >>> >
>> >>> >  drivers/spi/Kconfig |   6 +
>> >>> >  drivers/spi/omap3_spi.c | 439 
>> >>> > ++--
>> >>> >  drivers/spi/omap3_spi.h |  14 +-
>> >>> >  3 files changed, 402 insertions(+), 57 deletions(-)
>> >>>
>> >>> This is a pretty painful conversion, with lots of #ifdefs. I think it
>> >>> would be possible to use a common pointer type and reduce this.
>> >>>
>> >>> But perhaps it does not matter - how long must we be in the state of
>> >>> supporting legacy SPI? Can we convert all TI boards to driver model?
>> >>
>> >> We _really_ need some way to support more than one board per binary
>> >> before we can move everything to DM only.
>> >>
>> >> I think we can kind of do this today if we stick to using platform data
>> >> for everything that's board-specific rather than SoC-defined.  What we
>> >> talked about at ELCE was auto-generating the pdata from the device tree,
>> >> I think.
>> >
>> >We discussed this on IRC but since that doesn't exist as far as the
>> >mailing list is concerned...
>> >
>> >The current plan is:
>> >
>> >- Adjust build system to optionally build a u-boot.img in FIT format
>> >that includes the U-Boot binary and >1 device tree files
>> >- Adjust SPL to load this
>> >- Add a way for SPL to determine which device tree to select (by
>> >calling a board-specific function)
>> >- Have SPL pass this selected device tree to U-Boot when it starts
>> 
>> Can dtb be sperated from the final u-boot.img, if using SPL?
>> I mean let SPL load the u-boot.img and the dtb to correct DRAM address.
>> And the dtb is shared with linux kernel.
>
>This sounds similar, but different.  The problem I'm asking to be solved
>is that at the starting point, there are no DTBs on the hardware.  But

Oh. Thanks for explanation.

>we can in software easily and reliable tell which of say 3 boards we are
>on.  At that point, we need to make sure that both SPL and then U-Boot
>know which board they are on.  And if in U-Boot we use the DT to pass in
>all data, it has to be correct.  It sounds to me like you're describing
>the case where the HW has the dtb stored at a known location and you
>just don't need it embedded within SPL/U-Boot.

Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.

Thanks,
Peng.
>
>-- 
>Tom


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-21 Thread Tom Rini 
On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote:
> +Mugunthan, Tom
> 
> On 17 January 2016 at 03:56, Christophe Ricard
>  wrote:
> > Convert omap3_spi driver to DM and keep compatibility with previous
> > mode.
> >
> > Signed-off-by: Christophe Ricard 
> > ---
> >
> >  drivers/spi/Kconfig |   6 +
> >  drivers/spi/omap3_spi.c | 439 
> > ++--
> >  drivers/spi/omap3_spi.h |  14 +-
> >  3 files changed, 402 insertions(+), 57 deletions(-)
> 
> This is a pretty painful conversion, with lots of #ifdefs. I think it
> would be possible to use a common pointer type and reduce this.
> 
> But perhaps it does not matter - how long must we be in the state of
> supporting legacy SPI? Can we convert all TI boards to driver model?

We _really_ need some way to support more than one board per binary
before we can move everything to DM only.

I think we can kind of do this today if we stick to using platform data
for everything that's board-specific rather than SoC-defined.  What we
talked about at ELCE was auto-generating the pdata from the device tree,
I think.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-20 Thread Simon Glass 
+Mugunthan, Tom

On 17 January 2016 at 03:56, Christophe Ricard
 wrote:
> Convert omap3_spi driver to DM and keep compatibility with previous
> mode.
>
> Signed-off-by: Christophe Ricard 
> ---
>
>  drivers/spi/Kconfig |   6 +
>  drivers/spi/omap3_spi.c | 439 
> ++--
>  drivers/spi/omap3_spi.h |  14 +-
>  3 files changed, 402 insertions(+), 57 deletions(-)

This is a pretty painful conversion, with lots of #ifdefs. I think it
would be possible to use a common pointer type and reduce this.

But perhaps it does not matter - how long must we be in the state of
supporting legacy SPI? Can we convert all TI boards to driver model?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] spi: omap3: Convert to DM

2016-01-17 Thread Christophe Ricard 
Convert omap3_spi driver to DM and keep compatibility with previous
mode.

Signed-off-by: Christophe Ricard 
---

 drivers/spi/Kconfig |   6 +
 drivers/spi/omap3_spi.c | 439 ++--
 drivers/spi/omap3_spi.h |  14 +-
 3 files changed, 402 insertions(+), 57 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2cdb110..b8c2498 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,12 @@ config ZYNQ_QSPI
  Zynq QSPI IP core. This IP is used to connect the flash in
  4-bit qspi, 8-bit dual stacked and shared 4-bit dual parallel.
 
+config OMAP3_SPI
+   bool "McSPI driver for OMAP"
+   help
+ SPI master controller for OMAP24XX and later Multichannel SPI
+ (McSPI) modules.
+
 endif # if DM_SPI
 
 config FSL_ESPI
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 95cdfa3..09fb1ef 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -11,10 +11,14 @@
  *
  * Modified by Ruslan Araslanov 
  *
+ * Copyright (c) 2016 Christophe Ricard 
+ * - Added support for DM_SPI
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,9 +26,17 @@
 
 #define SPI_WAIT_TIMEOUT 10
 
+#ifdef CONFIG_DM_SPI
+static void spi_reset(struct udevice *dev)
+#else
 static void spi_reset(struct omap3_spi_slave *ds)
+#endif
 {
unsigned int tmp;
+#ifdef CONFIG_DM_SPI
+   struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+#endif
 
writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, >regs->sysconfig);
do {
@@ -39,20 +51,50 @@ static void spi_reset(struct omap3_spi_slave *ds)
writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, >regs->wakeupenable);
 }
 
+#ifdef CONFIG_DM_SPI
+static void omap3_spi_write_chconf(struct udevice *dev, int val)
+#else
 static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val)
+#endif
 {
-   writel(val, >regs->channel[ds->slave.cs].chconf);
+   unsigned int cs;
+#ifdef CONFIG_DM_SPI
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+   struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+
+   cs = platdata->cs;
+#else
+   cs = ds->slave.cs;
+#endif
+
+   writel(val, >regs->channel[cs].chconf);
/* Flash post writes to make immediate effect */
-   readl(>regs->channel[ds->slave.cs].chconf);
+   readl(>regs->channel[cs].chconf);
 }
 
+#ifdef CONFIG_DM_SPI
+static void omap3_spi_set_enable(struct udevice *dev, int enable)
+#else
 static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable)
+#endif
 {
-   writel(enable, >regs->channel[ds->slave.cs].chctrl);
+   unsigned int cs;
+#ifdef CONFIG_DM_SPI
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+   struct omap3_spi_slave *ds = dev_get_priv(dev->parent);
+
+   cs = platdata->cs;
+#else
+   cs = ds->slave.cs;
+#endif
+
+   writel(enable, >regs->channel[cs].chctrl);
/* Flash post writes to make immediate effect */
-   readl(>regs->channel[ds->slave.cs].chctrl);
+   readl(>regs->channel[cs].chctrl);
 }
 
+#ifndef CONFIG_DM_SPI
 void spi_init()
 {
/* do nothing */
@@ -138,10 +180,32 @@ void spi_free_slave(struct spi_slave *slave)
free(ds);
 }
 
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+#endif
+
+#ifdef CONFIG_DM_SPI
+static int omap3_spi_claim_bus(struct udevice *dev)
+#else
 int spi_claim_bus(struct spi_slave *slave)
+#endif
 {
-   struct omap3_spi_slave *ds = to_omap3_spi(slave);
+   unsigned int cs;
+   struct omap3_spi_slave *ds;
unsigned int conf, div = 0;
+#ifdef CONFIG_DM_SPI
+   struct dm_spi_slave_platdata *platdata = dev_get_parent_platdata(dev);
+   struct spi_slave *slave = dev_get_parent_priv(dev);
+
+   ds = dev_get_priv(dev->parent);
+   cs = platdata->cs;
+   ds->freq = slave->max_hz;
+#else
+   ds = to_omap3_spi(slave);
+   cs = ds->slave.cs;
+#endif
 
/* McSPI global module configuration */
 
@@ -149,7 +213,11 @@ int spi_claim_bus(struct spi_slave *slave)
 * setup when switching from (reset default) slave mode
 * to single-channel master mode
 */
+#ifdef CONFIG_DM_SPI
+   spi_reset(dev);
+#else
spi_reset(ds);
+#endif
conf = readl(>regs->modulctrl);
conf &= ~(OMAP3_MCSPI_MODULCTRL_STEST | OMAP3_MCSPI_MODULCTRL_MS);
conf |= OMAP3_MCSPI_MODULCTRL_SINGLE;
@@ -165,8 +233,7 @@ int spi_claim_bus(struct spi_slave *slave)
} else
div = 0xC;
 
-   conf = readl(>regs->channel[ds->slave.cs].chconf);
-
+   conf = readl(>regs->channel[cs].chconf);
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
 * REVISIT: this controller could support SPI_3WIRE mode.
 */
@@