All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryder Lee <ryder.lee@mediatek.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-mediatek@lists.infradead.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Red Hung <red.hung@mediatek.com>
Subject: Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
Date: Wed, 10 May 2017 17:31:47 +0800	[thread overview]
Message-ID: <1494408707.31307.32.camel@mtkswgap22> (raw)
In-Reply-To: <CAK8P3a193RxchvFAMWeZiP0sc0bd+VGg=_aVvipSgcbDpHXojg@mail.gmail.com>

On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> 
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> 
> I don't understand this part. Why do you need a static translation for these?
> Shouldn't they just be listed in the 'reg' property of the parent node now that
> you have the clk/reset/phy properties in the parent as well?

At first, I did like that. But I noticed that someone suggest it's
better to use 'assigned-addresses' to handle per-port registers, the
same path as tegra and marvell did, in other platform discussion thread.
So I just put shared register in root node. It could be rolled back if
you feel this is inappropriate.

> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> 
> Child nodes do not normally have interrupt-map properties. Isn't this
> already covered by the interrupt-map in the parent?
> 

I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
(0000:00:02), probe message looks good to me.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 224
pci 0000:01:00.0: assigning IRQ 224
pci 0000:01:00.1: fixup irq: got 224
pci 0000:01:00.1: assigning IRQ 224
pci 0000:01:00.2: fixup irq: got 224
pci 0000:01:00.2: assigning IRQ 224
pci 0000:01:00.3: fixup irq: got 224
pci 0000:01:00.3: assigning IRQ 224

pci 0000:02:00.0: fixup irq: got 225
pci 0000:02:00.0: assigning IRQ 225


But child nodes without interrupt-map properties:
It seems incorrect.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 223
pci 0000:01:00.0: assigning IRQ 223
pci 0000:01:00.1: fixup irq: got 223
pci 0000:01:00.1: assigning IRQ 223
pci 0000:01:00.2: fixup irq: got 223
pci 0000:01:00.2: assigning IRQ 223
pci 0000:01:00.3: fixup irq: got 223
pci 0000:01:00.3: assigning IRQ 223

pci 0000:02:00.0: fixup irq: got 223
pci 0000:02:00.0: assigning IRQ 223

WARNING: multiple messages have this Message-ID (diff)
From: Ryder Lee <ryder.lee@mediatek.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Red Hung <red.hung@mediatek.com>
Subject: Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
Date: Wed, 10 May 2017 17:31:47 +0800	[thread overview]
Message-ID: <1494408707.31307.32.camel@mtkswgap22> (raw)
In-Reply-To: <CAK8P3a193RxchvFAMWeZiP0sc0bd+VGg=_aVvipSgcbDpHXojg@mail.gmail.com>

On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> 
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> 
> I don't understand this part. Why do you need a static translation for these?
> Shouldn't they just be listed in the 'reg' property of the parent node now that
> you have the clk/reset/phy properties in the parent as well?

At first, I did like that. But I noticed that someone suggest it's
better to use 'assigned-addresses' to handle per-port registers, the
same path as tegra and marvell did, in other platform discussion thread.
So I just put shared register in root node. It could be rolled back if
you feel this is inappropriate.

> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> 
> Child nodes do not normally have interrupt-map properties. Isn't this
> already covered by the interrupt-map in the parent?
> 

I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
(0000:00:02), probe message looks good to me.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 224
pci 0000:01:00.0: assigning IRQ 224
pci 0000:01:00.1: fixup irq: got 224
pci 0000:01:00.1: assigning IRQ 224
pci 0000:01:00.2: fixup irq: got 224
pci 0000:01:00.2: assigning IRQ 224
pci 0000:01:00.3: fixup irq: got 224
pci 0000:01:00.3: assigning IRQ 224

pci 0000:02:00.0: fixup irq: got 225
pci 0000:02:00.0: assigning IRQ 225


But child nodes without interrupt-map properties:
It seems incorrect.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 223
pci 0000:01:00.0: assigning IRQ 223
pci 0000:01:00.1: fixup irq: got 223
pci 0000:01:00.1: assigning IRQ 223
pci 0000:01:00.2: fixup irq: got 223
pci 0000:01:00.2: assigning IRQ 223
pci 0000:01:00.3: fixup irq: got 223
pci 0000:01:00.3: assigning IRQ 223

pci 0000:02:00.0: fixup irq: got 223
pci 0000:02:00.0: assigning IRQ 223

WARNING: multiple messages have this Message-ID (diff)
From: Ryder Lee <ryder.lee@mediatek.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: devicetree@vger.kernel.org, Red Hung <red.hung@mediatek.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mediatek@lists.infradead.org,
	Bjorn Helgaas <bhelgaas@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
Date: Wed, 10 May 2017 17:31:47 +0800	[thread overview]
Message-ID: <1494408707.31307.32.camel@mtkswgap22> (raw)
In-Reply-To: <CAK8P3a193RxchvFAMWeZiP0sc0bd+VGg=_aVvipSgcbDpHXojg@mail.gmail.com>

On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> 
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> 
> I don't understand this part. Why do you need a static translation for these?
> Shouldn't they just be listed in the 'reg' property of the parent node now that
> you have the clk/reset/phy properties in the parent as well?

At first, I did like that. But I noticed that someone suggest it's
better to use 'assigned-addresses' to handle per-port registers, the
same path as tegra and marvell did, in other platform discussion thread.
So I just put shared register in root node. It could be rolled back if
you feel this is inappropriate.

> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> 
> Child nodes do not normally have interrupt-map properties. Isn't this
> already covered by the interrupt-map in the parent?
> 

I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
(0000:00:02), probe message looks good to me.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 224
pci 0000:01:00.0: assigning IRQ 224
pci 0000:01:00.1: fixup irq: got 224
pci 0000:01:00.1: assigning IRQ 224
pci 0000:01:00.2: fixup irq: got 224
pci 0000:01:00.2: assigning IRQ 224
pci 0000:01:00.3: fixup irq: got 224
pci 0000:01:00.3: assigning IRQ 224

pci 0000:02:00.0: fixup irq: got 225
pci 0000:02:00.0: assigning IRQ 225


But child nodes without interrupt-map properties:
It seems incorrect.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 223
pci 0000:01:00.0: assigning IRQ 223
pci 0000:01:00.1: fixup irq: got 223
pci 0000:01:00.1: assigning IRQ 223
pci 0000:01:00.2: fixup irq: got 223
pci 0000:01:00.2: assigning IRQ 223
pci 0000:01:00.3: fixup irq: got 223
pci 0000:01:00.3: assigning IRQ 223

pci 0000:02:00.0: fixup irq: got 223
pci 0000:02:00.0: assigning IRQ 223



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: ryder.lee@mediatek.com (Ryder Lee)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
Date: Wed, 10 May 2017 17:31:47 +0800	[thread overview]
Message-ID: <1494408707.31307.32.camel@mtkswgap22> (raw)
In-Reply-To: <CAK8P3a193RxchvFAMWeZiP0sc0bd+VGg=_aVvipSgcbDpHXojg@mail.gmail.com>

On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote:
> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> 
> > +- ranges:
> > +  - The first three entries are expected to translate the addresses for the root
> > +    port registers, which are referenced by the assigned-addresses property of
> > +    the root port nodes (see below).
> 
> I don't understand this part. Why do you need a static translation for these?
> Shouldn't they just be listed in the 'reg' property of the parent node now that
> you have the clk/reset/phy properties in the parent as well?

At first, I did like that. But I noticed that someone suggest it's
better to use 'assigned-addresses' to handle per-port registers, the
same path as tegra and marvell did, in other platform discussion thread.
So I just put shared register in root node. It could be rolled back if
you feel this is inappropriate.

> > +Required properties:
> > +- device_type: Must be "pci"
> > +- assigned-addresses: Address and size of the port configuration registers
> > +- reg: Only the first four bytes are used to refer to the correct bus number
> > +  and device number.
> > +- #address-cells: Must be 3
> > +- #size-cells: Must be 2
> > +- #interrupt-cells: Must be 1
> > +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
> > +  Please refer to the standard PCI bus binding document for a more detailed
> > +  explanation.
> 
> Child nodes do not normally have interrupt-map properties. Isn't this
> already covered by the interrupt-map in the parent?
> 

I have one Intel 4 port ethernet card(0000:00:01) and MTK WLAN card
(0000:00:02), probe message looks good to me.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 224
pci 0000:01:00.0: assigning IRQ 224
pci 0000:01:00.1: fixup irq: got 224
pci 0000:01:00.1: assigning IRQ 224
pci 0000:01:00.2: fixup irq: got 224
pci 0000:01:00.2: assigning IRQ 224
pci 0000:01:00.3: fixup irq: got 224
pci 0000:01:00.3: assigning IRQ 224

pci 0000:02:00.0: fixup irq: got 225
pci 0000:02:00.0: assigning IRQ 225


But child nodes without interrupt-map properties:
It seems incorrect.

pci 0000:00:01.0: fixup irq: got 224
pci 0000:00:01.0: assigning IRQ 224
pci 0000:00:02.0: fixup irq: got 225
pci 0000:00:02.0: assigning IRQ 225

pci 0000:01:00.0: fixup irq: got 223
pci 0000:01:00.0: assigning IRQ 223
pci 0000:01:00.1: fixup irq: got 223
pci 0000:01:00.1: assigning IRQ 223
pci 0000:01:00.2: fixup irq: got 223
pci 0000:01:00.2: assigning IRQ 223
pci 0000:01:00.3: fixup irq: got 223
pci 0000:01:00.3: assigning IRQ 223

pci 0000:02:00.0: fixup irq: got 223
pci 0000:02:00.0: assigning IRQ 223

  reply	other threads:[~2017-05-10  9:32 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-10  2:06 [PATCH v3 0/2] Add PCIe host driver support for Mediatek SoCs Ryder Lee
2017-05-10  2:06 ` Ryder Lee
2017-05-10  2:06 ` Ryder Lee
2017-05-10  2:06 ` Ryder Lee
2017-05-10  2:06 ` [PATCH v3 1/2] PCI: mediatek: Add Mediatek PCIe host controller support Ryder Lee
2017-05-10  2:06   ` Ryder Lee
2017-05-10  2:06   ` Ryder Lee
2017-05-10  2:06   ` Ryder Lee
2017-05-20 19:46   ` Paul Gortmaker
2017-05-20 19:46     ` Paul Gortmaker
2017-05-20 19:46     ` Paul Gortmaker
2017-05-20 19:46     ` Paul Gortmaker
2017-05-22  3:27     ` Ryder Lee
2017-05-22  3:27       ` Ryder Lee
2017-05-22  3:27       ` Ryder Lee
2017-05-22  3:27       ` Ryder Lee
2017-05-10  2:07 ` [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe Ryder Lee
2017-05-10  2:07   ` Ryder Lee
2017-05-10  2:07   ` Ryder Lee
2017-05-10  7:58   ` Matthias Brugger
2017-05-10  7:58     ` Matthias Brugger
2017-05-10  7:58     ` Matthias Brugger
2017-05-10  9:31     ` Ryder Lee
2017-05-10  9:31       ` Ryder Lee
2017-05-10  9:31       ` Ryder Lee
2017-05-10  9:31       ` Ryder Lee
2017-05-10  8:08   ` Arnd Bergmann
2017-05-10  8:08     ` Arnd Bergmann
2017-05-10  8:08     ` Arnd Bergmann
2017-05-10  9:31     ` Ryder Lee [this message]
2017-05-10  9:31       ` Ryder Lee
2017-05-10  9:31       ` Ryder Lee
2017-05-10  9:31       ` Ryder Lee
2017-05-10 10:01       ` Arnd Bergmann
2017-05-10 10:01         ` Arnd Bergmann
2017-05-10 10:01         ` Arnd Bergmann
2017-05-10 10:01         ` Arnd Bergmann
2017-05-11  2:44         ` Ryder Lee
2017-05-11  2:44           ` Ryder Lee
2017-05-11  2:44           ` Ryder Lee
2017-05-11  2:44           ` Ryder Lee
2017-05-11  7:17           ` Arnd Bergmann
2017-05-11  7:17             ` Arnd Bergmann
2017-05-11  7:17             ` Arnd Bergmann
2017-05-11  7:17             ` Arnd Bergmann
2017-05-11  9:08             ` Ryder Lee
2017-05-11  9:08               ` Ryder Lee
2017-05-11  9:08               ` Ryder Lee
2017-05-11  9:08               ` Ryder Lee
2017-05-11 12:11               ` Ryder Lee
2017-05-11 12:11                 ` Ryder Lee
2017-05-11 12:11                 ` Ryder Lee
2017-05-11 12:11                 ` Ryder Lee
2017-05-14  5:27                 ` Ryder Lee
2017-05-14  5:27                   ` Ryder Lee
2017-05-14  5:27                   ` Ryder Lee
2017-05-14  5:27                   ` Ryder Lee

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=1494408707.31307.32.camel@mtkswgap22 \
    --to=ryder.lee@mediatek.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=red.hung@mediatek.com \
    --cc=robh+dt@kernel.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.