All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"open list:OPEN FIRMWARE AND..."
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	srv_heupstream
	<srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date: Thu, 1 Oct 2015 14:58:52 +0800	[thread overview]
Message-ID: <1443682732.1714.11.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCXMRf4bxWancSJSq2a1pc38TYYY46Os9ASWWCRp95_ig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Daniel,

Thanks for your help to explain the patch.

On Tue, 2015-09-29 at 18:25 +0800, Daniel Kurtz wrote:
> On Sun, Sep 27, 2015 at 7:25 PM, Matthias Brugger
> <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> But then we at least need a corresponding change to the binding documentation.

I'll send a new patch with changing binding document.

> If the existing bindings are not used anywhere yet (*), it seems like
> unnecessary overhead to enforce backwards compatibility at this stage.
> 
> (*) I don't actually know if this is true, perhaps only Mediatek can
> answer this.

What does the meaning of existing bindings are used anywhere? Do you
mean this binding is used by other SoCs ?

Currently scpsys driver can't be shared between different Mediatek SoCs
because the power domains are different from each other. So I think it
should no need to maintain backward compatibility on scpsys's binding.

> > Apart from that, please send the dtsi part as a seperate patch.

OK.


Best regards,

James

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: jamesjj.liao@mediatek.com (James Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date: Thu, 1 Oct 2015 14:58:52 +0800	[thread overview]
Message-ID: <1443682732.1714.11.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCXMRf4bxWancSJSq2a1pc38TYYY46Os9ASWWCRp95_ig@mail.gmail.com>

Hi Daniel,

Thanks for your help to explain the patch.

On Tue, 2015-09-29 at 18:25 +0800, Daniel Kurtz wrote:
> On Sun, Sep 27, 2015 at 7:25 PM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
> >> But then we at least need a corresponding change to the binding documentation.

I'll send a new patch with changing binding document.

> If the existing bindings are not used anywhere yet (*), it seems like
> unnecessary overhead to enforce backwards compatibility at this stage.
> 
> (*) I don't actually know if this is true, perhaps only Mediatek can
> answer this.

What does the meaning of existing bindings are used anywhere? Do you
mean this binding is used by other SoCs ?

Currently scpsys driver can't be shared between different Mediatek SoCs
because the power domains are different from each other. So I think it
should no need to maintain backward compatibility on scpsys's binding.

> > Apart from that, please send the dtsi part as a seperate patch.

OK.


Best regards,

James

WARNING: multiple messages have this Message-ID (diff)
From: James Liao <jamesjj.liao@mediatek.com>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Sascha Hauer <kernel@pengutronix.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	Kevin Hilman <khilman@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date: Thu, 1 Oct 2015 14:58:52 +0800	[thread overview]
Message-ID: <1443682732.1714.11.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCXMRf4bxWancSJSq2a1pc38TYYY46Os9ASWWCRp95_ig@mail.gmail.com>

Hi Daniel,

Thanks for your help to explain the patch.

On Tue, 2015-09-29 at 18:25 +0800, Daniel Kurtz wrote:
> On Sun, Sep 27, 2015 at 7:25 PM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
> >> But then we at least need a corresponding change to the binding documentation.

I'll send a new patch with changing binding document.

> If the existing bindings are not used anywhere yet (*), it seems like
> unnecessary overhead to enforce backwards compatibility at this stage.
> 
> (*) I don't actually know if this is true, perhaps only Mediatek can
> answer this.

What does the meaning of existing bindings are used anywhere? Do you
mean this binding is used by other SoCs ?

Currently scpsys driver can't be shared between different Mediatek SoCs
because the power domains are different from each other. So I think it
should no need to maintain backward compatibility on scpsys's binding.

> > Apart from that, please send the dtsi part as a seperate patch.

OK.


Best regards,

James


  parent reply	other threads:[~2015-10-01  6:58 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25  6:31 [PATCH] soc: mediatek: Fix random hang up issue while kernel init James Liao
2015-09-25  6:31 ` James Liao
2015-09-25  6:31 ` James Liao
     [not found] ` <1443162717-64831-1-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-09-25  8:26   ` Lucas Stach
2015-09-25  8:26     ` Lucas Stach
2015-09-25  8:26     ` Lucas Stach
     [not found]     ` <1443169573.3135.9.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2015-09-27 11:25       ` Matthias Brugger
2015-09-27 11:25         ` Matthias Brugger
2015-09-27 11:25         ` Matthias Brugger
2015-09-29 10:25         ` Daniel Kurtz
2015-09-29 10:25           ` Daniel Kurtz
     [not found]           ` <CAGS+omCXMRf4bxWancSJSq2a1pc38TYYY46Os9ASWWCRp95_ig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-30  9:07             ` Lucas Stach
2015-09-30  9:07               ` Lucas Stach
2015-09-30  9:07               ` Lucas Stach
2015-10-01  7:15               ` James Liao
2015-10-01  7:15                 ` James Liao
2015-10-01  7:15                 ` James Liao
2015-10-01  8:07                 ` Daniel Kurtz
2015-10-01  8:07                   ` Daniel Kurtz
2015-10-01  8:07                   ` Daniel Kurtz
2015-10-01  9:26                   ` James Liao
2015-10-01  9:26                     ` James Liao
2015-10-01  9:26                     ` James Liao
2015-10-01 10:08                     ` Daniel Kurtz
2015-10-01 10:08                       ` Daniel Kurtz
2015-10-02  3:00                       ` James Liao
2015-10-02  3:00                         ` James Liao
2015-10-02  3:00                         ` James Liao
2015-10-02  9:25                         ` Daniel Kurtz
2015-10-02  9:25                           ` Daniel Kurtz
2015-10-02 10:37                           ` James Liao
2015-10-02 10:37                             ` James Liao
2015-10-02 10:37                             ` James Liao
2015-10-01  6:58             ` James Liao [this message]
2015-10-01  6:58               ` James Liao
2015-10-01  6:58               ` James Liao
2015-10-06  1:57   ` Daniel Kurtz
2015-10-06  1:57     ` Daniel Kurtz
2015-10-06  1:57     ` Daniel Kurtz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1443682732.1714.11.camel@mtksdaap41 \
    --to=jamesjj.liao-nus5lvnupcjwk0htik3j/w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.