On Thu, 16 Feb 2017 10:12:33 +0800, Chris Zhong wrote:
> On 02/15/2017 08:39 PM, John Keeping wrote:
> > On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:
> >
> >> On 01/29/2017 09:24 PM, John Keeping wrote:
> >>> In order to fully reset the state of the MIPI controller we must assert
>
Hi John
On 02/15/2017 08:39 PM, John Keeping wrote:
On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:
On 01/29/2017 09:24 PM, John Keeping wrote:
In order to fully reset the state of the MIPI controller we must assert
this reset.
This is slightly more complicated than it could be in
On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:
> On 01/29/2017 09:24 PM, John Keeping wrote:
> > In order to fully reset the state of the MIPI controller we must assert
> > this reset.
> >
> > This is slightly more complicated than it could be in order to maintain
> > compatibility with
Hi John
On 01/29/2017 09:24 PM, John Keeping wrote:
In order to fully reset the state of the MIPI controller we must assert
this reset.
This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.
On Sun, Jan 29, 2017 at 01:24:43PM +, John Keeping wrote:
> In order to fully reset the state of the MIPI controller we must assert
> this reset.
>
> This is slightly more complicated than it could be in order to maintain
> compatibility with device trees that do not specify the reset
In order to fully reset the state of the MIPI controller we must assert
this reset.
This is slightly more complicated than it could be in order to maintain
compatibility with device trees that do not specify the reset property.
Signed-off-by: John Keeping
Reviewed-by: Chris