* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-12 12:30 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, netdev@vger.kernel.org, Shruti Kanetkar,
jg1.han@samsung.com, michal.simek@xilinx.com,
peppe.cavallaro@st.com, davem@davemloft.net,
Madalin-Cristian Bucur
In-Reply-To: <1384167864-2457-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:04 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B2=
1989
> Subject: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>=20
> From: Andy Fleming
>=20
> You need an extra parameter to read or write Clause 45 PHYs, so we need a
> different API with the extra parameter.
>=20
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> include/linux/phy.h | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>=20
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 64ab823..684=
925a
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev=
, u32
> regnum) }
>=20
> /**
> + * phy_read_mmd - Convenience function for reading a register
> + * from an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + *
> + * Same rules as for phy_read();
> + */
> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
> +u32 regnum) {
> + return mdiobus_read(phydev->bus, phydev->addr,
> + MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff)); }
> +
> +/**
> * phy_write - Convenience function for writing a given PHY register
> * @phydev: the phy_device struct
> * @regnum: register number to write
> @@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device
> *phydev)
> return phydev->is_internal;
> }
>=20
> +/**
> + * phy_write_mmd - Convenience function for writing a register
> + * on an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + * @val: value to write to @regnum
> + *
> + * Same rules as for phy_write();
> + */
> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
> + u32 regnum, u16 val)
> +{
> + regnum =3D MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
> +
> + return mdiobus_write(phydev->bus, phydev->addr, regnum, val); }
> +
> struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int =
phy_id,
> bool is_c45, struct phy_c45_device_ids *c45_ids); struct
> phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
> --
> 1.8.4.1
^ permalink raw reply
* Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-11-12 12:23 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, linuxppc-dev, devicetree,
Alexander Popov
In-Reply-To: <20131111201024.GR17929@book.gsilab.sittig.org>
Hello, Gerhard!
2013/11/12 Gerhard Sittig <gsi@denx.de>:
> Alexander, there is outstanding review feedback for a previous
> version of the series that you haven't addressed yet. Can you
> please either look into those issues, or state that it's OK to
> leave them and why this is so?
Excuse me for misunderstanding, Gerhard.
I have thoroughly worked on your feedback to RFCv4
and agreed to your points. So I've just wrote RFCv5.
And all the improvements and known issues based on your feedback
are listed in the cover letter [PATCH RFC v5 0/5].
> It would be nice to get a
> response to the feedback that you are given. It may be
> appropriate not to obey to the feedback, but at least it should
> get considered.
Yes, I see. My implicit response by RFCv5 was not efficient, sorry.
Now should I write a detailed answer in the thread with your feedback
for improving readability of the discussion?
> Have you noticed the recent introduction of the dmaengine@vger
> ML?
No, I didn't.
>Make sure to include it upon the next submission.
Ok, I will.
Thanks.
Best regards,
Alexander.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: typo in dts: "interupt" (four devices)
From: Mark Rutland @ 2013-11-12 9:11 UTC (permalink / raw)
To: Adam Borowski
Cc: devicetree@vger.kernel.org, Pawel Moll, Ian Campbell,
Stephen Warren, rob.herring@calxeda.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384206727-11880-1-git-send-email-kilobyte@angband.pl>
On Mon, Nov 11, 2013 at 09:52:07PM +0000, Adam Borowski wrote:
> These lines were inoperative for four years, which puts some doubt into
> their importance, and it's possible the fixed version will regress, but
> at the very least they should be removed instead.
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
> ---
> arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
> arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
> index cc00f4d..f151426 100644
> --- a/arch/powerpc/boot/dts/xcalibur1501.dts
> +++ b/arch/powerpc/boot/dts/xcalibur1501.dts
> @@ -637,14 +637,14 @@
> tlu@2f000 {
> compatible = "fsl,mpc8572-tlu", "fsl_tlu";
> reg = <0x2f000 0x1000>;
> - interupts = <61 2 >;
> + interrupts = <61 2 >;
While you're fixing the typo, could you get rid of the extraneous space
before the closing bracket? It seems to be duplicated across the other 3
dts fragments you fix up also.
Cheers,
Mark.
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-11-12 7:59 UTC (permalink / raw)
To: Li Xiubo
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
linux-kernel@vger.kernel.org, Huan Wang, LW@KARO-electronics.de,
linux@arm.linux.org.uk, Vinod Koul,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org, Shawn Guo, djbw@fb.com,
rob.herring@calxeda.com, broonie@kernel.org, Zhengxiong Jin,
oskar@scara.com, Fabio Estevam, lgirdwood@gmail.com,
rob@landley.net, Guangyu Chen, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F8287E87B@039-SN2MPN1-013.039d.mgd.msft.net>
On 11/12/2013 08:35 AM, Li Xiubo wrote:
>>>>> +static int fsl_sai_probe(struct platform_device *pdev) {
>>>> [...]
>>>>> +
>>>>> + sai->dma_params_rx.addr = res->start + SAI_RDR;
>>>>> + sai->dma_params_rx.maxburst = 6;
>>>>> + index = of_property_match_string(np, "dma-names", "rx");
>>>>> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
>> index,
>>>>> + &dma_args);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + sai->dma_params_rx.slave_id = dma_args.args[1];
>>>>> +
>>>>> + sai->dma_params_tx.addr = res->start + SAI_TDR;
>>>>> + sai->dma_params_tx.maxburst = 6;
>>>>> + index = of_property_match_string(np, "dma-names", "tx");
>>>>> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
>> index,
>>>>> + &dma_args);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + sai->dma_params_tx.slave_id = dma_args.args[1];
>>>>
>>>> The driver should not have to manually parse the dma devicetree
>>>> properties, this is something that should be handled by the dma
>>>> engine driver.
>>>>
>>>
>>> What do you think about the DMA slave_id ?
>>> I have been noticed by one colleague that this should be parsed here,
>>> which is from your opinions ?
>> Sure slave_id can be parsed here, but IMO it should be programmed via the
>> dma_slave_confog into the respective channel
>>
>
> Actually, these are parsed for cpu_dai->playback_dma_data and cpu_dai->capture_dma_data dynamically, whose type is struct dma_slave_config.
>
> And now I must parse them here, because the platform eDMA driver's newest version will check and use the slave_ids to select and configure the eDMA channels via dma_device->device_control().
Parsing them here is a layering violation. The format of the DMA specifier
depends on the DMA controller. A DMA slave should not make any assumptions
about how the specifier looks like, it should not even look at them. You should
fix the DMA controller driver to work without slave_id in the devicetree case.
- Lars
^ permalink raw reply
* Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
From: pegasus @ 2013-11-12 7:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <alpine.LRH.2.00.1311111312390.25474@ra8135-ec1.am.freescale.net>
I re-read the link you posted earlier and this time it made more sense to me.
The kind of questions which are coming into my mind were being discussed.
So, off I went and downloaded the latest version of
arch/powerpc/kernel/traps.c hoping to see those very changes in them.
However it didn't match one on one with what was written in that thread.
Ditto for the other files in your patch. Looks like your patch didn't make
it to upstream but it looks exactly like what I need here. So allow me to
discuss certain finer points of it, to make sure I understand what it does
correctly.
In that thread you say
James Yang wrote
> BookE ISA's branch taken exception triggers before a branch that will be
> taken executes. This allows software to examine the branch and the
> conditions under which it will be taken. It also means software can tell
> where basic blocks end (at least the ones which are terminated by taken
> branches).
*
> There are no architected registers that report the address of the branch
> instruction after it has executed.
*
My thoughts exactly!
In the first patch's description, you say
James Yang wrote
> This patch makes available the unmodified BookE branch taken debug
> exception through PTRACE_SINGLEBLOCK if the ptrace() addr parameter is set
> to 2. (The existing behavior of PTRACE_SINGLEBLOCK is retained for any
> other addr parameter value, e.g., 0.)
*
> SIGTRAP will be signaled with the NIP pointing to the branch instruction
> before it has executed. The ptrace-calling program can then examine the
> program state.
*
>
/
> It should then request a PTRACE_SINGLESTEP in order to advance the program
> to the next instruction or a PTRACE_CONT to resume normal program
> execution.
/
> The si_code now also reports TRAP_BRANCH.
So requesting PTRACE_CONT has to happen inside the SIGTRAP signal handler
right? So as to advance the branch instruction (and since we are talking
BookE here, we are dead sure this branch will be taken). Now as for the
second patch, as far as I can see, implements the same functionality.
However it makes the change permanent and any tool which is used to the NIP
pointing to the branch target will be broken.
Anyways, for me either of them will work. But I think the first patch makes
everyone happy by using the 'addr' field of ptrace. This also means I will
have to make my (broken) ptrace working which, it seems is not as easy
adding an enum field as you suggested. May be theres a check somewhere in
the actual ptrace code which checks for illegal values and hence even after
adding an enum, it is being reported as illegal in my case. However getting
that to work is another story.
Please confirm my understanding of your patches and since these patches have
not made their way to the upstream kernel, will have to use them myself
directly. By the way, I'm using 2.6.32.10 (you know..the long-term kernel)
and I couldn't find any of your changes in them but then again I couldn't
find it in the latest 3.12 version either.
--
View this message in context: http://linuxppc.10917.n7.nabble.com/BookE-branch-taken-behavior-vis-a-vis-updating-the-NIP-register-tp77960p78036.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Li Xiubo @ 2013-11-12 7:35 UTC (permalink / raw)
To: Vinod Koul, lars@metafoo.de
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, timur@tabi.org,
linux-kernel@vger.kernel.org, Huan Wang, LW@KARO-electronics.de,
Lars-Peter Clausen, linux@arm.linux.org.uk,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org, Shawn Guo, djbw@fb.com,
rob.herring@calxeda.com, broonie@kernel.org, Zhengxiong Jin,
oskar@scara.com, Fabio Estevam, lgirdwood@gmail.com,
rob@landley.net, Guangyu Chen, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131112050226.GK8834@intel.com>
> > > > +static int fsl_sai_probe(struct platform_device *pdev) {
> > > [...]
> > > > +
> > > > + sai->dma_params_rx.addr =3D res->start + SAI_RDR;
> > > > + sai->dma_params_rx.maxburst =3D 6;
> > > > + index =3D of_property_match_string(np, "dma-names", "rx");
> > > > + ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> index,
> > > > + &dma_args);
> > > > + if (ret)
> > > > + return ret;
> > > > + sai->dma_params_rx.slave_id =3D dma_args.args[1];
> > > > +
> > > > + sai->dma_params_tx.addr =3D res->start + SAI_TDR;
> > > > + sai->dma_params_tx.maxburst =3D 6;
> > > > + index =3D of_property_match_string(np, "dma-names", "tx");
> > > > + ret =3D of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> index,
> > > > + &dma_args);
> > > > + if (ret)
> > > > + return ret;
> > > > + sai->dma_params_tx.slave_id =3D dma_args.args[1];
> > >
> > > The driver should not have to manually parse the dma devicetree
> > > properties, this is something that should be handled by the dma
> > > engine driver.
> > >
> >
> > What do you think about the DMA slave_id ?
> > I have been noticed by one colleague that this should be parsed here,
> > which is from your opinions ?
> Sure slave_id can be parsed here, but IMO it should be programmed via the
> dma_slave_confog into the respective channel
>=20
Actually, these are parsed for cpu_dai->playback_dma_data and cpu_dai->capt=
ure_dma_data dynamically, whose type is struct dma_slave_config.
And now I must parse them here, because the platform eDMA driver's newest v=
ersion will check and use the slave_ids to select and configure the eDMA ch=
annels via dma_device->device_control().=20
--
Xiubo
^ permalink raw reply
* Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang @ 2013-11-12 7:05 UTC (permalink / raw)
To: Dan Williams
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll,
Stephen Warren, Koul, Vinod, Linux Kernel Mailing List,
rob.herring, dmaengine, linuxppc-dev
In-Reply-To: <CAPcyv4h00zGc2=ZLwnCpP3WTQ8JbFteV-torU+qCo98YXrfq5A@mail.gmail.com>
On 11/12/2013 08:09 AM, Dan Williams wrote:
> On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
> <hongbo.zhang@freescale.com> wrote:
>>>>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>>>>> index 49e8fbd..16a9a48 100644
>>>>>> --- a/drivers/dma/fsldma.c
>>>>>> +++ b/drivers/dma/fsldma.c
>>>>>> @@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
>>>>>> fsldma_device
>>>>>> *fdev,
>>>>>> WARN_ON(fdev->feature != chan->feature);
>>>>>> chan->dev = fdev->dev;
>>>>>> - chan->id = ((res.start - 0x100) & 0xfff) >> 7;
>>>>>> + chan->id = (res.start & 0xfff) < 0x300 ?
>>>>>> + ((res.start - 0x100) & 0xfff) >> 7 :
>>>>>> + ((res.start - 0x200) & 0xfff) >> 7;
>>>>>> if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
>>> Isn't it a bit fragile to have this based on the resource address?
>>> Can't device tree tell you the channel id directly by an index into
>>> the "dma0: dma@100300" node?
>>
>> Yes, both this way and putting a "cell-index" into device tree work.
>> This won't be fragile, because the resource address should always be defined
>> correctly, otherwise even if we can tell a channel id by "cell-index" but
>> with wrong resource address, nothing will work.
>> This piece of code only doesn't seem as neat as using "cell-index", but we
>> prefer the style that let the device tree describes as true as what hardware
>> really has. This doesn't mean "cell-index" isn't acceptable, if it is
>> necessary and unavoidable, we can send another patch to add it, but
>> currently there is no need and we don't have to do this.
>>
> I'm pointing it out because we just had a bug fix to another driver
> motivated by the fact that resource addresses may move from one
> implementation to another, whereas the cell index provided by device
> tree is static. Just a note, no need to fix it now.
Get it, and will remember it, thank you Dan.
> --
> Dan
>
^ permalink raw reply
* [PATCH 2/2] powerpc/eeh: More accurate log
From: Gavin Shan @ 2013-11-12 6:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1384238962-13170-1-git-send-email-shangw@linux.vnet.ibm.com>
We possibly has fenced PHB except frozen PE. So the output log
doesn't cover all cases and the patch fixes it.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh_event.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_event.c b/arch/powerpc/kernel/eeh_event.c
index d27c5af..72d748b 100644
--- a/arch/powerpc/kernel/eeh_event.c
+++ b/arch/powerpc/kernel/eeh_event.c
@@ -74,8 +74,13 @@ static int eeh_event_handler(void * dummy)
pe = event->pe;
if (pe) {
eeh_pe_state_mark(pe, EEH_PE_RECOVERING);
- pr_info("EEH: Detected PCI bus error on PHB#%d-PE#%x\n",
- pe->phb->global_number, pe->addr);
+ if (pe->type & EEH_PE_PHB)
+ pr_info("EEH: Detected error on PHB#%d\n",
+ pe->phb->global_number);
+ else
+ pr_info("EEH: Detected PCI bus error on "
+ "PHB#%d-PE#%x\n",
+ pe->phb->global_number, pe->addr);
eeh_handle_event(pe);
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
From: Gavin Shan @ 2013-11-12 6:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER
on PCI bridges. According to one experiment I had, the MSIx interrupts
didn't raise from the adapter without the bit applied to all upstream
PCI bridges including root port of the adapter. The patch forces to
have that bit enabled accordingly.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 1fb331d..180af13 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -687,6 +687,15 @@ void eeh_save_bars(struct eeh_dev *edev)
for (i = 0; i < 16; i++)
eeh_ops->read_config(dn, i * 4, 4, &edev->config_space[i]);
+
+ /*
+ * For PCI bridges including root port, we need enable bus
+ * master explicitly. Otherwise, it can't fetch IODA table
+ * entries correctly. So we cache the bit in advance so that
+ * we can restore it after reset, either PHB range or PE range.
+ */
+ if (edev->mode & EEH_DEV_BRIDGE)
+ edev->config_space[1] |= PCI_COMMAND_MASTER;
}
/**
--
1.7.9.5
^ permalink raw reply related
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Vinod Koul @ 2013-11-12 5:02 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
timur@tabi.org, linux-kernel@vger.kernel.org, Guo Shawn-R65073,
LW@KARO-electronics.de, Lars-Peter Clausen,
linux@arm.linux.org.uk, Chen Guangyu-B42378, oskar@scara.com,
grant.likely@linaro.org, devicetree@vger.kernel.org,
ian.campbell@citrix.com, pawel.moll@arm.com,
swarren@wwwdotorg.org, rob.herring@calxeda.com,
broonie@kernel.org, linux-arm-kernel@lists.infradead.org,
Estevam Fabio-R49496, lgirdwood@gmail.com, rob@landley.net,
djbw@fb.com, Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F8286A385@039-SN2MPN1-013.039d.mgd.msft.net>
On Mon, Oct 28, 2013 at 05:58:42AM +0000, Xiubo Li-B47053 wrote:
> Hi Dan, Vinod,
>
>
> > > +static int fsl_sai_probe(struct platform_device *pdev) {
> > [...]
> > > +
> > > + sai->dma_params_rx.addr = res->start + SAI_RDR;
> > > + sai->dma_params_rx.maxburst = 6;
> > > + index = of_property_match_string(np, "dma-names", "rx");
> > > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > > + &dma_args);
> > > + if (ret)
> > > + return ret;
> > > + sai->dma_params_rx.slave_id = dma_args.args[1];
> > > +
> > > + sai->dma_params_tx.addr = res->start + SAI_TDR;
> > > + sai->dma_params_tx.maxburst = 6;
> > > + index = of_property_match_string(np, "dma-names", "tx");
> > > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > > + &dma_args);
> > > + if (ret)
> > > + return ret;
> > > + sai->dma_params_tx.slave_id = dma_args.args[1];
> >
> > The driver should not have to manually parse the dma devicetree
> > properties, this is something that should be handled by the dma engine
> > driver.
> >
>
> What do you think about the DMA slave_id ?
> I have been noticed by one colleague that this should be parsed here, which
> is from your opinions ?
Sure slave_id can be parsed here, but IMO it should be programmed via the
dma_slave_confog into the respective channel
--
~Vinod
>
>
> > > +
> > > + ret = snd_soc_register_component(&pdev->dev, &fsl_component,
> > > + &fsl_sai_dai, 1);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = fsl_pcm_dma_init(pdev);
> > > + if (ret)
> > > + goto out;
>
>
--
^ permalink raw reply
* Re: [PATCH] powerpc: add explicit OF includes for ppc4xx
From: Vinod Koul @ 2013-11-12 4:52 UTC (permalink / raw)
To: Rob Herring
Cc: linux-ide, linux-kernel, Rob Herring, Herbert Xu, Paul Mackerras,
linux-crypto, Matt Mackall, Tejun Heo, Dan Williams, linuxppc-dev,
David S. Miller
In-Reply-To: <1384148143-14335-1-git-send-email-robherring2@gmail.com>
On Sun, Nov 10, 2013 at 11:35:43PM -0600, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit
> includes of of_*.h headers by powerpc's prom.h. Some PPC4xx components
> were missed in initial clean-up patch, so add the necessary includes
> to fix ppc4xx builds.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ide@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> ---
> I intend to send this patch to Linus with the rest of the DT clean-up
> series.
>
> Rob
>
> arch/powerpc/sysdev/ppc4xx_ocm.c | 1 +
> arch/powerpc/sysdev/xilinx_intc.c | 1 +
> drivers/ata/sata_dwc_460ex.c | 2 ++
> drivers/char/hw_random/ppc4xx-rng.c | 1 +
> drivers/crypto/amcc/crypto4xx_core.c | 3 +++
> drivers/dma/ppc4xx/adma.c | 2 ++
For this:
Acked-by Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> 6 files changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c
> index 1b15f93..b7c4345 100644
> --- a/arch/powerpc/sysdev/ppc4xx_ocm.c
> +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
> @@ -26,6 +26,7 @@
> #include <linux/kernel.h>
> #include <linux/dma-mapping.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <asm/rheap.h>
> #include <asm/ppc4xx_ocm.h>
> #include <linux/slab.h>
> diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
> index f4fdc94..83f943a 100644
> --- a/arch/powerpc/sysdev/xilinx_intc.c
> +++ b/arch/powerpc/sysdev/xilinx_intc.c
> @@ -24,6 +24,7 @@
> #include <linux/irq.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <asm/io.h>
> #include <asm/processor.h>
> #include <asm/i8259.h>
> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
> index 2e39173..523524b 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -31,6 +31,8 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/libata.h>
> diff --git a/drivers/char/hw_random/ppc4xx-rng.c b/drivers/char/hw_random/ppc4xx-rng.c
> index 732c330..521f76b 100644
> --- a/drivers/char/hw_random/ppc4xx-rng.c
> +++ b/drivers/char/hw_random/ppc4xx-rng.c
> @@ -13,6 +13,7 @@
> #include <linux/platform_device.h>
> #include <linux/hw_random.h>
> #include <linux/delay.h>
> +#include <linux/of_address.h>
> #include <linux/of_platform.h>
> #include <asm/io.h>
>
> diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
> index f88e3d8..efaf630 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.c
> +++ b/drivers/crypto/amcc/crypto4xx_core.c
> @@ -27,6 +27,9 @@
> #include <linux/dma-mapping.h>
> #include <linux/platform_device.h>
> #include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/slab.h>
> #include <asm/dcr.h>
> diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c
> index 370ff82..e24b5ef 100644
> --- a/drivers/dma/ppc4xx/adma.c
> +++ b/drivers/dma/ppc4xx/adma.c
> @@ -42,6 +42,8 @@
> #include <linux/uaccess.h>
> #include <linux/proc_fs.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <asm/dcr.h>
> #include <asm/dcr-regs.h>
> --
> 1.8.1.2
>
--
^ permalink raw reply
* RE: [PATCH v6] clk: corenet: Adds the clock binding
From: Yuantian Tang @ 2013-11-12 2:00 UTC (permalink / raw)
To: Mark Rutland, mike.turquette@linaro.org
Cc: devicetree@vger.kernel.org, Scott Wood,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131111115202.GD21201@e106331-lin.cambridge.arm.com>
> > +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
> > @@ -0,0 +1,123 @@
> > +* Clock Block on Freescale CoreNet Platforms
> > +
> > +Freescale CoreNet chips take primary clocking input from the external
> > +SYSCLK signal. The SYSCLK input (frequency) is multiplied using
> > +multiple phase locked loops (PLL) to create a variety of frequencies
> > +which can then be passed to a variety of internal logic, including
> > +cores and peripheral IP blocks.
> > +Please refer to the Reference Manual for details.
> > +
> > +1. Clock Block Binding
> > +
> > +Required properties:
> > +- compatible: Should include one or more of the following:
>=20
> When you say "one or more", I assume you mean of the specific clock block
> strings, and then a chassis string?
>=20
> If so, it might be better to say smoething like:
>=20
> - compatible: Should contain a specific clock block compatible string
> and a single chassis clock compatible string.
>=20
> Clock block strings include:
> * "fsl,p2041-clockgen"
> * "fsl,p3041-clockgen"
>=20
> Chassis clock strings include:
> * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
> * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clock
>=20
Sounds better.
> > + * "fsl,<chip>-clockgen": for chip specific clock block, here chip
> > + could be but not limited to one of the: p2041, p3041, p4080,
> > + p5020, p5040, t4240, b4420, b4860
> > + * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
> > + * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
> > + Notes that "fsl,qoriq-clockgen-1.0" and "fsl,qoriq-clockgen-2.0"
> > + cannot be included simultaneously.
> > +- reg: Offset and length of the clock register set
> > +
> > +Recommended properties:
> > +- ranges: Allows valid translation between child's address space and
> > + parent's. Must be present if the device has sub-nodes.
> > +- #address-cells: Specifies the number of cells used to represent
> > + physical base addresses. Must be present if the device has
> > + sub-nodes and set to 1 if present
> > +- #size-cells: Specifies the number of cells used to represent
> > + the size of an address. Must be present if the device has
> > + sub-nodes and set to 1 if present
>=20
> Is there any particular reason these _must_ be 1?
>=20
They are one u32 variable long and no other options, so, they should be set=
to 1.
> > +
> > +2. Clock Provider/Consumer Binding
> > +
> > +Most of the bindings are from the common clock binding[1].
> > + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Required properties:
> > +- compatible : Should include one of the following:
> > + * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
> > + * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
> > + * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
> > + * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
> > + * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0)
> > + * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0)
> > +- #clock-cells: From common clock binding; indicates the number of
> > + output clock. 0 is for "fsl,qoriq-sysclk-[1,2].0" and
> > + "fsl,qoriq-core-mux-[1,2].0"; 1 for "fsl,qoriq-core-pll-[1,2].0".
>=20
> Nit: #clock-cells defines the number of cells in a clock-specifier, not
> the number of output clocks. How about:
>=20
> - #clock-cells: The number of cells in a clock-specifier. Should be <0>
> for "fsl,qoriq-sysclk-[1,2].0" clocks, or <1> for
> "fsl,qoriq-core-pll-[1,2].0" clocks.
>=20
> > + If #clock-cells has a value of 1, its clock consumer should specify
> > + the desired clock by having the clock ID in its "clocks" phandle
> > + cell. The following is a full list IDs:
>=20
> The ID is in the clock-specifier, not the phandle. How about the
> following instead:
>=20
> For "fsl,qoriq-core-pll-[1,2].0" clocks, the single clock-specifier cell
> may take the following values:
>=20
OK, thanks.
> > + * 0 - equal to the PLL frequency
> > + * 1 - equal to the PLL frequency divided by 2
> > + * 2 - equal to the PLL frequency divided by 4
> > +
> > +Recommended properties:
> > +- clocks: Should be the phandle of input parent clock
> > +- clock-names: From common clock binding, indicates the clock name
>=20
> Is this not well defined and common across all of the clocks? The set of
> inputs they have must be well known, and if it isn't then this property
> isn't all that useful.
>=20
> > +- clock-output-names: From common clock binding, indicates the names
> of
> > + output clocks
>=20
> Similarly, I'd expect that there might be well defined output names.
>=20
The clock-output-names and clock-names vary both from nodes to nodes and
from platforms to platforms. There is no general rules to define it.
I think the *-names properties should be added easily by following the exam=
ple below.
> > +- reg: Should be the offset and length of clock block base address.
> > + The length should be 4.
> > +
> > +Example for clock block and clock provider:
> > +/ {
> > + clockgen: global-utilities@e1000 {
> > + compatible =3D "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
> > + ranges =3D <0x0 0xe1000 0x1000>;
> > + reg =3D <0xe1000 0x1000>;
> > + #address-cells =3D <1>;
> > + #size-cells =3D <1>;
> > +
> > + sysclk: sysclk {
> > + #clock-cells =3D <0>;
> > + compatible =3D "fsl,qoriq-sysclk-1.0";
> > + clock-output-names =3D "sysclk";
> > + }
> > +
> > + pll0: pll0@800 {
> > + #clock-cells =3D <1>;
> > + reg =3D <0x800 0x4>;
> > + compatible =3D "fsl,qoriq-core-pll-1.0";
> > + clocks =3D <&sysclk>;
> > + clock-output-names =3D "pll0", "pll0-div2";
> > + };
> > +
> > + pll1: pll1@820 {
> > + #clock-cells =3D <1>;
> > + reg =3D <0x820 0x4>;
> > + compatible =3D "fsl,qoriq-core-pll-1.0";
> > + clocks =3D <&sysclk>;
> > + clock-output-names =3D "pll1", "pll1-div2";
> > + };
>=20
> The binding documentation for clock-output-names describes clock-output-
> names as the name of the clock output signals. I understand this as
> meaning name of the output with respect to the clock, rather than a
> global namespace, but I may be mistaken there. Mike?
>=20
> Given that I'd expect pll0 and pll1 to have the same set of clock-output-
> names, (perhaps "pll", "pll-div2") as they seem to be instances of the
> same HW block. As far as I am aware the precise instance shouldn't affect
> the name (unless the documentation for the HW have these logical output
> names?).
>=20
These names will be used to register clock in driver, so it should be uniqu=
e globally.
So...
> > +
> > + mux0: mux0@0 {
> > + #clock-cells =3D <0>;
> > + reg =3D <0x0 0x4>;
> > + compatible =3D "fsl,qoriq-core-mux-1.0";
> > + clocks =3D <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> > + clock-names =3D "pll0", "pll0-div2", "pll1", "pll1-div2";
> > + clock-output-names =3D "cmux0";
> > + };
>=20
> I have a similar worry here with regards to the clock-names, but I guess
> it doesn't really matter here if the documentation doesn't provide any
> better names for the inputs to the mux.
>=20
> However for the output name I'd expect just "cmux".
>=20
Same as above, cmux is not unique if we have multiple MUXes.
Thanks,
Yuantian
> Thanks,
> Mark,
>=20
> > +
> > + mux1: mux1@20 {
> > + #clock-cells =3D <0>;
> > + reg =3D <0x20 0x4>;
> > + compatible =3D "fsl,qoriq-core-mux-1.0";
> > + clocks =3D <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> > + clock-names =3D "pll0", "pll0-div2", "pll1", "pll1-div2";
> > + clock-output-names =3D "cmux1";
> > + };
> > + };
> > + }
> > +
> > +Example for clock consumer:
> > +
> > +/ {
> > + cpu0: PowerPC,e5500@0 {
> > + ...
> > + clocks =3D <&mux0>;
> > + ...
> > + };
> > + }
> > --
> > 1.8.0
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2013-11-12 0:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Linux Kernel list
Hi Linus !
Now that you've proven that even a typhoon can't get you, let's start
throwing code at you again !
The bulk of this is LE updates. One should now be able to build an
LE kernel and even run some things in it.
I'm still sitting on a handful of patches to enable the new ABI that
I *might* still send this merge window around, but due to the
incertainty (they are pretty fresh) I want to keep them separate.
Other notable changes are some infrastructure bits to better handle
PCI pass-through under KVM, some bits and pieces added to the new
PowerNV platform support such as access to the CPU SCOM bus via sysfs,
and support for EEH error handling on PHB3 (Power8 PCIe).
We also grew arch_get_random_long() for both pseries and powernv when
running on P7+ and P8, exploiting the HW rng.
And finally various embedded updates from freescale.
Cheers,
Ben.
The following changes since commit 8b5ede69d24db939f52b47effff2f6fe1e83e08b:
powerpc/irq: Don't switch to irq stack from softirq stack (2013-10-07 14:19:39 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next
for you to fetch changes up to 0c4888ef1d8a8b82c29075ce7e257ff795af15c7:
powerpc: Fix fatal SLB miss when restoring PPR (2013-11-06 14:13:53 +1100)
----------------------------------------------------------------
Alexey Kardashevskiy (3):
hashtable: add hash_for_each_possible_rcu_notrace()
powerpc: Prepare to support kernel handling of IOMMU map/unmap
powerpc: add real mode support for dma operations on powernv
Alistair Popple (5):
powerpc: Little endian fixes for platforms/powernv/opal.c
powerpc: Little endian fix for arch/powerpc/platforms/powernv/pci.c
powerpc: Little endian fix for arch/powerpc/platforms/powernv/pci-p5ioc2.c
powerpc: Little endian sparse clean up for arch/powerpc/platforms/powernv/pci-ioda.c
powerpc: Fix 64K page size support for PPC44x
Anatolij Gustschin (1):
powerpc/52xx: fix build breakage for MPC5200 LPBFIFO module
Anton Blanchard (30):
powerpc: Fix endian issues in VMX copy loops
powerpc: Book 3S MMU little endian support
powerpc: Fix offset of FPRs in VSX registers in little endian builds
powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds
powerpc: Little endian builds double word swap VSX state during context save/restore
powerpc: Add little endian support for word-at-a-time functions
powerpc: Set MSR_LE bit on little endian builds
powerpc: Reset MSR_LE on signal entry
powerpc: Remove open coded byte swap macro in alignment handler
powerpc: Remove hard coded FP offsets in alignment handler
powerpc: Alignment handler shouldn't access VSX registers with TS_FPR
powerpc: Add little endian support to alignment handler
powerpc: Handle VSX alignment faults in little endian mode
powerpc: Use generic checksum code in little endian
powerpc: Use generic memcpy code in little endian
powerpc: uname should return ppc64le/ppcle on little endian builds
powerpc/powernv: More little endian issues in OPAL RTC driver
powerpc/powernv: Fix some PCI sparse errors and one LE bug
KVM: PPC: Disable KVM on little endian builds
powerpc: Don't set HAVE_EFFICIENT_UNALIGNED_ACCESS on little endian builds
powerpc: Work around little endian gcc bug
powerpc: Fix little endian issue in OF PCI scan
powerpc/pseries: Fix endian issues in pseries iommu code
powerpc/pseries: Fix dedicated processor partition detection
powerpc: Use -mcpu=power7 on ppc64 little endian builds
powerpc: sync ppc64, ppc64e and pseries configs
powerpc: Enable multipath modules on ppc64 and pseries
powerpc: Enable virtio on ppc64 and pseries configs
powerpc: Use 32 bit loads and stores when operating on condition register values
powerpc: Add VMX optimised xor for RAID5
Bartlomiej Zolnierkiewicz (2):
powerpc/legacy_serial: Fix incorrect placement of __initdata tag
powerpc/8xx/tqm8xx: Fix incorrect placement of __initdata tag
Benjamin Herrenschmidt (26):
powerpc: Endian safe trampoline
powerpc/powernv: Fix endian issues in OPAL RTC driver
powerpc/powernv: Fix endian issues in OPAL ICS backend
powerpc/powernv: Make OPAL NVRAM device tree accesses endian safe
powerpc/powernv: Fix endian issues in powernv PCI code
powerpc/powernv: Fix endian issues in OPAL console and udbg backend
powerpc/powernv: Fix OPAL entry and exit in little endian mode
powerpc/powernv: Don't register exception handlers in little endian mode
powerpc/hvsi: Fix endian issues in HVSI driver
tty/hvc_opal: powerpc: Make OPAL HVC device tree accesses endian safe
powerpc: Enable /dev/port when isa_io_special is set
powerpc/scom: Change scom_read() and scom_write() to return errors
powerpc/scom: Add support for "reg" property
powerpc/scom: Create debugfs files using ibm,chip-id if available
powerpc/powernv: Add scom support under OPALv3
powerpc/scom: CONFIG_SCOM_DEBUGFS should depend on CONFIG_DEBUG_FS
powerpc/scom: Use "devspec" rather than "path" in debugfs entries
Merge branch 'for-kvm' into next
Merge branch 'for-kvm' into next
Merge remote-tracking branch 'scott/next' into next
Merge remote-tracking branch 'agust/next' into next
powerpc/boot: Properly handle the base "of" boot wrapper
powerpc/scom: Enable 64-bit addresses
powerpc/scom: Improve debugfs interface
powerpc/powernv: Add support for indirect XSCOM via debugfs
powerpc: Fix fatal SLB miss when restoring PPR
Bharat Bhushan (4):
powerpc: Added __cmpdi2 for signed 64bit comparision
powerpc: remove unnecessary line continuations
powerpc: move debug registers in a structure
powerpc: export debug registers save function for KVM
Brian Norris (1):
powerpc/mpc512x: remove unnecessary #if
Cedric Le Goater (4):
powerpc/kernel: Fix endian issue in rtas_pci
powerpc/nvram: Scan partitions only once
powerpc/nvram: Fix endian issue when reading the NVRAM size
powerpc/nvram: Fix endian issue when using the partition length
Christian Kujau (2):
powerpc/6xx: CONFIG_MCU_MPC8349EMITX cannot be a module
powerpc/pmu: Fix ADB_PMU_LED_IDE dependencies
Chunhe Lan (1):
powerpc/pci: Change the DECLARE_PCI_FIXUP_{HEADER => EARLY} macro of pci quirk
Dan Streetman (1):
powerpc: Only save/restore SDR1 if in hypervisor mode
Eugene Surovegin (2):
powerpc: Make kernel module helper endian-safe.
powerpc: Make ftrace endian-safe.
Gavin Shan (8):
powerpc/powernv: Enable EEH for PHB3
powerpc/powernv: Support inbound error injection
powerpc/eeh: Output error number
powerpc/powernv: Double size of log blob
powerpc/eeh: Output PHB3 diag-data
powerpc/eeh: Reorder output messages
powerpc/powernv: Add PE to its own PELTV
powerpc/powernv: Reserve the correct PE number
Geert Uytterhoeven (1):
powerpc/kexec: kexec_sequence() is in misc_64.S
Gerhard Sittig (1):
powerpc/mpc512x: silence build warning upon disabled DIU
Haijun.Zhang (2):
powerpc/eSDCH: Specify voltage for T4240QDS
powerpc/dts: Correct sdhci quirk for bsc9131
Hongtao Jia (1):
powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
Ian Munsie (3):
powerpc: Support endian agnostic MMIO
powerpc: Include the appropriate endianness header
powerpc: Add ability to build little endian kernels
James Yang (2):
powerpc: Emulate sync instruction variants
powerpc/booke: clear DBCR0_BT in user_disable_single_step()
Kevin Hao (5):
powerpc/ppc64: Remove the unneeded load of ti_flags in resume_kernel
powerpc/booke64: Check napping in performance monitor interrupt
powerpc/85xx: introduce corenet_generic machine
powerpc/85xx: rename the corenet_ds.c to corenet_generic.c
powerpc/85xx: use one kernel option for all the CoreNet_Generic boards
LEROY Christophe (4):
powerpc/mpc8xx: Clearer Oops message for Software Emulation Exception
powerpc/8xx: Revert commit e0908085fc2391c85b85fb814ae1df377c8e0dcb
powerpc/8xx: Fixing issue with CONFIG_PIN_TLB
powerpc/8xx: Fixing memory init issue with CONFIG_PIN_TLB
Laurent Dufour (1):
powerpc: prom_init exception when updating core value
Lijun Pan (2):
powerpc/e6500: Include Power ISA properties
powerpc/e500v2: Include Power ISA properties
Michael Ellerman (5):
hwrng: Return errors to upper levels in pseries-rng.c
powerpc: Implement arch_get_random_long/int() for powernv
hwrng: Add a driver for the hwrng found in power7+ systems
powerpc/pseries: Implement arch_get_random_long() based on H_RANDOM
powerpc: FA_DUMP depends on KEXEC
Michael Neuling (1):
powerpc/tm: Remove interrupt disable in __switch_to()
Mihai Caraman (2):
powerpc/booke64: Use common defines for AltiVec interrupts numbers
powerpc/fsl-booke: Use common defines for SPE/FP interrupts numbers
Minghuan Lian (1):
powerpc/dts: fix sRIO error interrupt for b4860
Paul Bolle (1):
powerpc: remove dependency on MV64360
Paul Mackerras (4):
powerpc: Put FP/VSX and VR state into structures
powerpc: Provide for giveup_fpu/altivec to save state in alternate location
powerpc: Don't corrupt user registers on 32-bit
powerpc/boot: Don't change link address for OF-based platforms
Philippe Bergheaud (2):
powerpc/bpf: BPF JIT compiler for 64-bit Little Endian
powerpc: word-at-a-time optimization for 64-bit Little Endian
Prabhakar Kushwaha (1):
powerpc/dts/c293pcie: Add range field for IFC NAND
Prarit Bhargava (1):
powerpc/vio: use strcpy in modalias_show
Robert Jennings (2):
powerpc: Fix warnings for arch/powerpc/mm/numa.c
powerpc: Move local setup.h declarations to arch includes
Scott Wood (3):
powerpc/mpic: Disable preemption when calling mpic_processor_id()
powerpc/b4qds: enable coreint
powerpc: Fix PPC_EMULATED_STATS build break with sync patch
Shengzhou Liu (1):
powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
Stephen Rothwell (1):
powerpc: Add includes to fix powernv/rng.c build
Sudeep KarkadaNagesha (2):
powerpc: Remove big endianness assumption in of_find_next_cache_node
of: Move definition of of_find_next_cache_node into common code.
Suzuki Poulose (1):
powerpc: Set the NOTE type for SPE regset
Tiejun Chen (1):
powerpc/kgdb: use DEFINE_PER_CPU to allocate kgdb's thread_info
Tom Musta (4):
powerpc: Fix Handler of Unaligned Load/Store Strings
powerpc: Enable Little Endian Alignment Handler for Float Pair Instructions
powerpc: Fix Unaligned Loads and Stores
powerpc: Fix Unaligned LE Floating Point Loads and Stores
Vaishnavi Bhat (1):
powerpc: Fix a typo in comments of va to pa conversion
Vasant Hegde (2):
powerpc/powernv: Create opal sysfs directory
powerpc/powernv: Code update interface
Vladimir Murzin (3):
powerpc: Fix section mismatch warning in free_lppacas
powerpc/bpf: Fix DIVWU instruction opcode
powerpc/bpf: Support MOD operation
Wei Yongjun (2):
powerpc/6xx: add missing iounmap() on error in hlwd_pic_init()
powerpc/mv643xx_eth: fix return check in mv64x60_eth_register_shared_pdev()
Wolfram Sang (2):
arch/powerpc/platforms/83xx: Remove obsolete cleanup for clientdata
Kind of revert "powerpc: 52xx: provide a default in mpc52xx_irqhost_map()"
York Sun (2):
powerpc/t4240emu: Add device tree file for t4240emu
powerpc/b4860emu: Add device tree file for b4860emu
Zhao Qiang (1):
powerpc/p1010rdb: add P1010RDB-PB platform support
arch/powerpc/Kconfig | 12 +-
arch/powerpc/Makefile | 37 +-
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/dts/b4860emu.dts | 218 ++++++++
arch/powerpc/boot/dts/b4qds.dtsi | 51 +-
arch/powerpc/boot/dts/c293pcie.dts | 1 +
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/bsc9131si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/bsc9131si-pre.dtsi | 3 +
arch/powerpc/boot/dts/t4240emu.dts | 268 ++++++++++
arch/powerpc/boot/dts/t4240qds.dts | 73 +--
arch/powerpc/boot/wrapper | 8 +
arch/powerpc/configs/corenet32_smp_defconfig | 7 +-
arch/powerpc/configs/corenet64_smp_defconfig | 5 +-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 27 +-
arch/powerpc/configs/ppc64e_defconfig | 12 +-
arch/powerpc/configs/ppc6xx_defconfig | 2 +-
arch/powerpc/configs/pseries_defconfig | 25 +-
arch/powerpc/include/asm/archrandom.h | 32 ++
arch/powerpc/include/asm/checksum.h | 5 +
arch/powerpc/include/asm/emulated_ops.h | 1 +
arch/powerpc/include/asm/hvsi.h | 16 +-
arch/powerpc/include/asm/io.h | 69 ++-
arch/powerpc/include/asm/lppaca.h | 12 +-
arch/powerpc/include/asm/machdep.h | 16 +
arch/powerpc/include/asm/mmu-hash64.h | 4 +-
arch/powerpc/include/asm/opal.h | 109 +++-
arch/powerpc/include/asm/page.h | 4 +-
arch/powerpc/include/asm/pgtable-ppc64.h | 2 +
arch/powerpc/include/asm/ppc-opcode.h | 8 +-
arch/powerpc/include/asm/ppc_asm.h | 142 ++----
arch/powerpc/include/asm/processor.h | 91 ++--
arch/powerpc/include/asm/prom.h | 3 -
arch/powerpc/include/asm/reg.h | 7 +-
arch/powerpc/include/asm/reg_booke.h | 8 +-
arch/powerpc/include/asm/scom.h | 23 +-
arch/powerpc/include/asm/setup.h | 4 +
arch/powerpc/include/asm/sfp-machine.h | 2 +-
arch/powerpc/include/asm/string.h | 4 +
arch/powerpc/include/asm/switch_to.h | 1 +
arch/powerpc/include/asm/word-at-a-time.h | 78 +++
arch/powerpc/include/asm/xor.h | 67 +++
arch/powerpc/include/uapi/asm/byteorder.h | 4 +
arch/powerpc/kernel/align.c | 173 ++++---
arch/powerpc/kernel/asm-offsets.c | 29 +-
arch/powerpc/kernel/eeh.c | 6 +-
arch/powerpc/kernel/entry_64.S | 50 +-
arch/powerpc/kernel/exceptions-64e.S | 6 +-
arch/powerpc/kernel/fpu.S | 86 ++--
arch/powerpc/kernel/ftrace.c | 4 +
arch/powerpc/kernel/head_64.S | 3 +
arch/powerpc/kernel/head_8xx.S | 3 +
arch/powerpc/kernel/head_fsl_booke.S | 10 +-
arch/powerpc/kernel/kgdb.c | 6 +-
arch/powerpc/kernel/legacy_serial.c | 2 +-
arch/powerpc/kernel/machine_kexec_64.c | 2 +-
arch/powerpc/kernel/misc_32.S | 14 +
arch/powerpc/kernel/module.c | 3 +-
arch/powerpc/kernel/module_32.c | 3 +-
arch/powerpc/kernel/module_64.c | 19 +-
arch/powerpc/kernel/nvram_64.c | 10 +-
arch/powerpc/kernel/paca.c | 6 +-
arch/powerpc/kernel/pci_of_scan.c | 4 +-
arch/powerpc/kernel/ppc_ksyms.c | 10 +
arch/powerpc/kernel/process.c | 67 +--
arch/powerpc/kernel/prom.c | 31 --
arch/powerpc/kernel/prom_init.c | 28 +-
arch/powerpc/kernel/ptrace.c | 209 ++++----
arch/powerpc/kernel/ptrace32.c | 13 +-
arch/powerpc/kernel/rtas_pci.c | 6 +-
arch/powerpc/kernel/setup-common.c | 2 -
arch/powerpc/kernel/setup.h | 9 -
arch/powerpc/kernel/setup_32.c | 2 -
arch/powerpc/kernel/setup_64.c | 2 -
arch/powerpc/kernel/signal_32.c | 81 +--
arch/powerpc/kernel/signal_64.c | 32 +-
arch/powerpc/kernel/swsusp_asm64.S | 4 +
arch/powerpc/kernel/tm.S | 49 +-
arch/powerpc/kernel/traps.c | 56 ++-
arch/powerpc/kernel/vdso.c | 3 +-
arch/powerpc/kernel/vdso32/vdso32.lds.S | 4 +
arch/powerpc/kernel/vdso64/vdso64.lds.S | 4 +
arch/powerpc/kernel/vecemu.c | 6 +-
arch/powerpc/kernel/vector.S | 80 +--
arch/powerpc/kernel/vio.c | 4 +-
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/book3s_pr.c | 36 +-
arch/powerpc/kvm/booke.c | 19 +-
arch/powerpc/lib/Makefile | 21 +-
arch/powerpc/lib/copyuser_power7.S | 54 +-
arch/powerpc/lib/memcpy_power7.S | 55 +-
arch/powerpc/lib/sstep.c | 97 +++-
arch/powerpc/lib/xor_vmx.c | 177 +++++++
arch/powerpc/mm/hash_native_64.c | 46 +-
arch/powerpc/mm/hash_utils_64.c | 38 +-
arch/powerpc/mm/init_32.c | 5 +
arch/powerpc/mm/init_64.c | 51 +-
arch/powerpc/mm/numa.c | 8 +-
arch/powerpc/mm/pgtable.c | 19 +-
arch/powerpc/net/bpf_jit.h | 11 +
arch/powerpc/net/bpf_jit_64.S | 9 +-
arch/powerpc/net/bpf_jit_comp.c | 37 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 18 +-
arch/powerpc/platforms/52xx/Kconfig | 2 +-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 5 +-
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 1 -
arch/powerpc/platforms/85xx/Kconfig | 101 +---
arch/powerpc/platforms/85xx/Makefile | 8 +-
arch/powerpc/platforms/85xx/b4_qds.c | 102 ----
arch/powerpc/platforms/85xx/corenet_ds.c | 96 ----
arch/powerpc/platforms/85xx/corenet_ds.h | 19 -
arch/powerpc/platforms/85xx/corenet_generic.c | 182 +++++++
arch/powerpc/platforms/85xx/p1010rdb.c | 2 +
arch/powerpc/platforms/85xx/p2041_rdb.c | 87 ----
arch/powerpc/platforms/85xx/p3041_ds.c | 89 ----
arch/powerpc/platforms/85xx/p4080_ds.c | 87 ----
arch/powerpc/platforms/85xx/p5020_ds.c | 93 ----
arch/powerpc/platforms/85xx/p5040_ds.c | 84 ----
arch/powerpc/platforms/85xx/t4240_qds.c | 93 ----
arch/powerpc/platforms/8xx/tqm8xx_setup.c | 4 +-
arch/powerpc/platforms/Kconfig.cputype | 9 +-
arch/powerpc/platforms/chrp/nvram.c | 4 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 +
arch/powerpc/platforms/powernv/Kconfig | 2 +
arch/powerpc/platforms/powernv/Makefile | 4 +-
arch/powerpc/platforms/powernv/eeh-ioda.c | 153 +++++-
arch/powerpc/platforms/powernv/eeh-powernv.c | 5 +-
arch/powerpc/platforms/powernv/opal-flash.c | 667 +++++++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-nvram.c | 4 +-
arch/powerpc/platforms/powernv/opal-rtc.c | 12 +-
arch/powerpc/platforms/powernv/opal-wrappers.S | 16 +-
arch/powerpc/platforms/powernv/opal-xscom.c | 128 +++++
arch/powerpc/platforms/powernv/opal.c | 57 ++-
arch/powerpc/platforms/powernv/pci-ioda.c | 110 ++--
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 4 +-
arch/powerpc/platforms/powernv/pci.c | 78 ++-
arch/powerpc/platforms/powernv/pci.h | 6 +-
arch/powerpc/platforms/powernv/rng.c | 125 +++++
arch/powerpc/platforms/pseries/Makefile | 2 +-
arch/powerpc/platforms/pseries/iommu.c | 59 +--
arch/powerpc/platforms/pseries/nvram.c | 10 +-
arch/powerpc/platforms/pseries/rng.c | 44 ++
arch/powerpc/platforms/wsp/scom_smp.c | 18 +-
arch/powerpc/platforms/wsp/scom_wsp.c | 12 +-
arch/powerpc/platforms/wsp/wsp.c | 13 +-
arch/powerpc/sysdev/Kconfig | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 5 +-
arch/powerpc/sysdev/fsl_soc.h | 3 -
arch/powerpc/sysdev/mpic.c | 8 +-
arch/powerpc/sysdev/mv64x60_dev.c | 2 +-
arch/powerpc/sysdev/scom.c | 168 ++++---
arch/powerpc/sysdev/xics/ics-opal.c | 17 +-
drivers/char/hw_random/Kconfig | 13 +
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/powernv-rng.c | 81 +++
drivers/char/hw_random/pseries-rng.c | 14 +-
drivers/macintosh/Kconfig | 1 +
drivers/of/base.c | 31 ++
drivers/tty/hvc/hvc_opal.c | 4 +-
drivers/tty/hvc/hvsi_lib.c | 25 +-
include/linux/hashtable.h | 15 +
include/linux/mm.h | 14 +
include/linux/of.h | 2 +
include/linux/page-flags.h | 4 +-
168 files changed, 4200 insertions(+), 2125 deletions(-)
create mode 100644 arch/powerpc/boot/dts/b4860emu.dts
create mode 100644 arch/powerpc/boot/dts/t4240emu.dts
create mode 100644 arch/powerpc/include/asm/archrandom.h
delete mode 100644 arch/powerpc/kernel/setup.h
create mode 100644 arch/powerpc/lib/xor_vmx.c
delete mode 100644 arch/powerpc/platforms/85xx/b4_qds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/corenet_ds.h
create mode 100644 arch/powerpc/platforms/85xx/corenet_generic.c
delete mode 100644 arch/powerpc/platforms/85xx/p2041_rdb.c
delete mode 100644 arch/powerpc/platforms/85xx/p3041_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p4080_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5020_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/p5040_ds.c
delete mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
create mode 100644 arch/powerpc/platforms/powernv/opal-flash.c
create mode 100644 arch/powerpc/platforms/powernv/opal-xscom.c
create mode 100644 arch/powerpc/platforms/powernv/rng.c
create mode 100644 arch/powerpc/platforms/pseries/rng.c
create mode 100644 drivers/char/hw_random/powernv-rng.c
^ permalink raw reply
* Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Dan Williams @ 2013-11-12 0:09 UTC (permalink / raw)
To: Hongbo Zhang
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll,
Stephen Warren, Koul, Vinod, Linux Kernel Mailing List,
rob.herring, dmaengine, linuxppc-dev
In-Reply-To: <52809F67.20901@freescale.com>
On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
<hongbo.zhang@freescale.com> wrote:
>>>>> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
>>>>> index 49e8fbd..16a9a48 100644
>>>>> --- a/drivers/dma/fsldma.c
>>>>> +++ b/drivers/dma/fsldma.c
>>>>> @@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct
>>>>> fsldma_device
>>>>> *fdev,
>>>>> WARN_ON(fdev->feature != chan->feature);
>>>>> chan->dev = fdev->dev;
>>>>> - chan->id = ((res.start - 0x100) & 0xfff) >> 7;
>>>>> + chan->id = (res.start & 0xfff) < 0x300 ?
>>>>> + ((res.start - 0x100) & 0xfff) >> 7 :
>>>>> + ((res.start - 0x200) & 0xfff) >> 7;
>>>>> if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
>>
>> Isn't it a bit fragile to have this based on the resource address?
>> Can't device tree tell you the channel id directly by an index into
>> the "dma0: dma@100300" node?
>
>
> Yes, both this way and putting a "cell-index" into device tree work.
> This won't be fragile, because the resource address should always be defined
> correctly, otherwise even if we can tell a channel id by "cell-index" but
> with wrong resource address, nothing will work.
> This piece of code only doesn't seem as neat as using "cell-index", but we
> prefer the style that let the device tree describes as true as what hardware
> really has. This doesn't mean "cell-index" isn't acceptable, if it is
> necessary and unavoidable, we can send another patch to add it, but
> currently there is no need and we don't have to do this.
>
I'm pointing it out because we just had a bug fix to another driver
motivated by the fact that resource addresses may move from one
implementation to another, whereas the cell index provided by device
tree is static. Just a note, no need to fix it now.
--
Dan
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support
From: Scott Wood @ 2013-11-11 23:47 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20131109064336.GB27936@pek-khao-d1.corp.ad.wrs.com>
On Sat, 2013-11-09 at 14:43 +0800, Kevin Hao wrote:
> On Fri, Nov 08, 2013 at 03:16:12PM -0600, Scott Wood wrote:
> > OK... Why are you splitting out smp_85xx_basic_setup()?
>
> In the current implementation of smp_85xx_setup_cpu(), we only invoke
> the function mpic_setup_this_cpu() when the smp_85xx_ops.probe is set
> to smp_mpic_probe(). So if we set smp_85xx_ops.probe to NULL when doorbell
> is available, we must make sure that the mpic_setup_this_cpu() is also invoked
> when there does have a mpic. The smp_85xx_basic_setup() is for the board which
> has no mpic.
>
> static void smp_85xx_setup_cpu(int cpu_nr)
> {
> if (smp_85xx_ops.probe == smp_mpic_probe)
> mpic_setup_this_cpu();
>
> if (cpu_has_feature(CPU_FTR_DBELL))
> doorbell_setup_this_cpu();
> }
>
> > Where do you
> > call it other than from smp_85xx_setup_cpu()?
>
> We would set the .setup_cpu() to smp_85xx_basic_setup() if it is a
> non-mpic board. The following is quoted form the patch:
> np = of_find_node_by_type(NULL, "open-pic");
> if (np) {
> smp_85xx_ops.probe = smp_mpic_probe;
> + smp_85xx_ops.setup_cpu = smp_85xx_setup_cpu;
> smp_85xx_ops.message_pass = smp_mpic_message_pass;
> - }
> + } else
> + smp_85xx_ops.setup_cpu = smp_85xx_basic_setup;
OK, somehow I missed the change to .setup_cpu before. :-P
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: typo in dts: "interupt" (four devices)
From: Adam Borowski @ 2013-11-11 21:52 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, devicetree, linuxppc-dev
Cc: Adam Borowski
These lines were inoperative for four years, which puts some doubt into
their importance, and it's possible the fixed version will regress, but
at the very least they should be removed instead.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts b/arch/powerpc/boot/dts/xcalibur1501.dts
index cc00f4d..f151426 100644
--- a/arch/powerpc/boot/dts/xcalibur1501.dts
+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
@@ -637,14 +637,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2 >;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5301.dts b/arch/powerpc/boot/dts/xpedite5301.dts
index 53c1c6a..d00fe16 100644
--- a/arch/powerpc/boot/dts/xpedite5301.dts
+++ b/arch/powerpc/boot/dts/xpedite5301.dts
@@ -547,14 +547,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2 >;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5330.dts b/arch/powerpc/boot/dts/xpedite5330.dts
index 2152259..e506554 100644
--- a/arch/powerpc/boot/dts/xpedite5330.dts
+++ b/arch/powerpc/boot/dts/xpedite5330.dts
@@ -583,14 +583,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2 >;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5370.dts b/arch/powerpc/boot/dts/xpedite5370.dts
index 11dbda1..9f1c608 100644
--- a/arch/powerpc/boot/dts/xpedite5370.dts
+++ b/arch/powerpc/boot/dts/xpedite5370.dts
@@ -545,14 +545,14 @@
tlu@2f000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x2f000 0x1000>;
- interupts = <61 2 >;
+ interrupts = <61 2 >;
interrupt-parent = <&mpic>;
};
tlu@15000 {
compatible = "fsl,mpc8572-tlu", "fsl_tlu";
reg = <0x15000 0x1000>;
- interupts = <75 2>;
+ interrupts = <75 2>;
interrupt-parent = <&mpic>;
};
};
--
1.8.5.rc0
^ permalink raw reply related
* Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
From: James Yang @ 2013-11-11 20:11 UTC (permalink / raw)
To: pegasus; +Cc: linuxppc-dev
In-Reply-To: <1384156293077-78004.post@n7.nabble.com>
On Mon, 11 Nov 2013, pegasus wrote:
> And this is due to the pipelining feature that is inherent in all
> processors.
No, it has nothing to do with pipelining at all. It is just the
convention that IBM defined as to how the branch taken exception works
in BookE Power ISA. The pipeline behavior is not visible from the
architected state.
> But I still have a question about how one would then be able to
> signal to the userspace who might be interpreting this information
> differently? I mean if SRR0 contains, not the branch instruction
> address but the address of the branch target, how would any debugger
> be able to catch function calls?
On Server and the BookE-mimicking-Server, PT_NIP would point to the
start of the function you are calling. However, you do not get the
callsite address unless you know you stopped after a function-calling
branch-and-link executed, single step again and read the LR and
subtract 4. If you don't know if the branch that caused the exception
was actually a branch-and-link, you don't know if you are at the
beginning of a function or not, unless you keep a table of the address
of all possible functions and look up each PT_NIP to see if you are.
But that wouldn't be 100% accurate either, since a non-linking branch
could just redirect to the beginning of the function. In the other
thread, Ben said they have the CFAR register, but from the way it is
described in the ISA document, you will not always get the address of
the callsite, e.g. if your target is in the same cache black, the CFAR
might not change. So, I don't think it can work in a simple way.
On BookE with my patch to NOT mimic server, you will stop before the
branch executes, so PT_NIP points to the branch itself, so that there
is your callsite information. If you want the function target, you
decode the instruction to see if it is a branch-and-link, and then
compute the target address or manually singlestep and grab the new
PT_NIP.
> May be there is a trick involved here and hence gdb or for that
> matter the other debuggers are still in the market.
Per the other thread, and my inquiry through my company's gdb experts
and upstream on the gdb mailing list, gdb does NOT use hardware branch
tracing, at least not using PTRACE_SINGLEBLOCK. I don't personally
know of any debuggers that use it in the form that it exists in Linux.
> But then I would be immensely obliged if you could shed some light
> on how is this accomplished. Lets say I am waiting at the userspace
> in my own sigtrap, to watch out for branch instructions. Lets say I
> want to profile my code to get to know how many branch instructions
> it has generated. How could I ever do that using my own custom
> SIGTRAP handler?
Lots of ways to skin this cat, but I don't think any of them are easy
or simple.
- Using valgrind is probably the easiest way to get this information
on an unmodified executable.
- You may want to recompile your program with call-arch profiling if
you have source code. gcc -fprofile-arcs but read the docs.
- Another method is to set up performance monitor counter to interrupt
after a branch has executed, but callsite information may be lost as
well and you still have the issue of discerning whether you just
called a function or not.
- You can use my patch for BookE, but it's just an RFC. Also, using
PTRACE_SINGLEBLOCK is slow. You could also stop on every
PTRACE_SINGLESTEP, but this is even slower.
> Coming on to PTRACE_SINGLESTEP, the sysroot that has been provided
> to us by our vendor does not include a PTRACE_SINGLEBLOCK in
> sys/ptrace.h:
> Although I can clearly see that PTRACE_SINGLEBLOCK is supported in the
> kernel.
>
> Hence I am not able to compile this simple program in userspace:
> Heres the error I get:
> testptrace.c: In function 'int main()':
> testptrace.c:47: error: invalid conversion from 'int' to '__ptrace_request'
> testptrace.c:47: error: initializing argument 1 of 'long int
> ptrace(__ptrace_request, ...)'
> make: *** [testptrace] Error 1
>
> How should I go about using ptrace to test this?
I don't know. You'll probably have to request support from your vendor
or whoever provided you with those headers. If you are using a glibc
based toolchain, your glibc is probably out-of-date. You can try
adding PTRACE_SINGLEBLOCK into the enum definition just to get past
the compiler syntax error, but I don't know if that will break things
or not in your libc ptrace(). You may have to write your own function
that calls the __ptrace syscall directly if the libc ptrace() does
something to the request or the response.
^ permalink raw reply
* Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
From: Gerhard Sittig @ 2013-11-11 20:10 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Vinod Koul,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1383290374-17484-3-git-send-email-a13xp0p0v88@gmail.com>
On Fri, Nov 01, 2013 at 11:19 +0400, Alexander Popov wrote:
>
> Introduce support for slave s/g transfer preparation and the associated
> device control callback in the MPC512x DMA controller driver, which adds
> support for data transfers between memory and peripheral I/O to the
> previously supported mem-to-mem transfers.
Alexander, there is outstanding review feedback for a previous
version of the series that you haven't addressed yet. Can you
please either look into those issues, or state that it's OK to
leave them and why this is so? It would be nice to get a
response to the feedback that you are given. It may be
appropriate not to obey to the feedback, but at least it should
get considered.
Have you noticed the recent introduction of the dmaengine@vger
ML? Make sure to include it upon the next submission.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH RFC v5 1/5] dma: mpc512x: reorder mpc8308 specific instructions
From: Gerhard Sittig @ 2013-11-11 20:01 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: Lars-Peter Clausen, Arnd Bergmann, Vinod Koul, Alexander Popov,
Dan Williams, linuxppc-dev
In-Reply-To: <20131101110418.1158b999@crub>
[ dropping devicetree@vger from CC ]
On Fri, Nov 01, 2013 at 11:04 +0100, Anatolij Gustschin wrote:
>
> On Fri, 1 Nov 2013 11:19:30 +0400
> Alexander Popov <a13xp0p0v88@gmail.com> wrote:
>
> > Concentrate the specific code for MPC8308 in the 'if' branch
> > and handle MPC512x in the 'else' branch.
> > This modification only reorders instructions but doesn't change behaviour.
> >
> > Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> > ---
> > drivers/dma/mpc512x_dma.c | 42 +++++++++++++++++++++++++-----------------
> > 1 file changed, 25 insertions(+), 17 deletions(-)
>
> Acked-by: Anatolij Gustschin <agust@denx.de>
I feel that this patch has become stable and can be taken,
regardless of the pending review of the other parts in the series.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Lijun Pan @ 2013-11-11 19:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lijun Pan
In-Reply-To: <1383952632-5770-1-git-send-email-Lijun.Pan@freescale.com>
mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
---
arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
arch/powerpc/configs/mpc85xx_defconfig | 18 +++
arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
3 files changed, 35 insertions(+), 188 deletions(-)
delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig
deleted file mode 100644
index b06d37d..0000000
--- a/arch/powerpc/configs/85xx/p1023_defconfig
+++ /dev/null
@@ -1,188 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_AUDIT=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_RCU_FANOUT=32
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_MAC_PARTITION=y
-CONFIG_PHYSICAL_START=0x00000000
-CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
-CONFIG_QUICC_ENGINE=y
-CONFIG_QE_GPIO=y
-CONFIG_CPM2=y
-CONFIG_HIGHMEM=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_BINFMT_MISC=m
-CONFIG_MATH_EMULATION=y
-CONFIG_SWIOTLB=y
-CONFIG_PCI=y
-CONFIG_PCIEPORTBUS=y
-# CONFIG_PCIEAER is not set
-# CONFIG_PCIEASPM is not set
-CONFIG_PCI_MSI=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-CONFIG_IP_PNP_RARP=y
-CONFIG_NET_IPIP=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_ARPD=y
-CONFIG_INET_ESP=y
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
-CONFIG_IP_SCTP=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_MTD=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_FSL_ELBC=y
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=131072
-CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_LEGACY=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_MULTI_LUN=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_ATA=y
-CONFIG_SATA_FSL=y
-CONFIG_SATA_SIL24=y
-CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
-CONFIG_FS_ENET=y
-CONFIG_FSL_PQ_MDIO=y
-CONFIG_E1000E=y
-CONFIG_PHYLIB=y
-CONFIG_AT803X_PHY=y
-CONFIG_MARVELL_PHY=y
-CONFIG_DAVICOM_PHY=y
-CONFIG_CICADA_PHY=y
-CONFIG_VITESSE_PHY=y
-CONFIG_FIXED_PHY=y
-CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=y
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-CONFIG_HW_RANDOM=y
-CONFIG_NVRAM=y
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_CPM=m
-CONFIG_I2C_MPC=y
-CONFIG_GPIO_MPC8XXX=y
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-CONFIG_SOUND=y
-CONFIG_SND=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-# CONFIG_SND_SUPPORT_OLD_API is not set
-CONFIG_USB=y
-CONFIG_USB_DEVICEFS=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_STORAGE=y
-CONFIG_EDAC=y
-CONFIG_EDAC_MM_EDAC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_DMADEVICES=y
-CONFIG_FSL_DMA=y
-# CONFIG_NET_DMA is not set
-CONFIG_STAGING=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_ISO9660_FS=m
-CONFIG_JOLIET=y
-CONFIG_ZISOFS=y
-CONFIG_UDF_FS=m
-CONFIG_MSDOS_FS=m
-CONFIG_VFAT_FS=y
-CONFIG_NTFS_FS=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_ADFS_FS=m
-CONFIG_AFFS_FS=m
-CONFIG_HFS_FS=m
-CONFIG_HFSPLUS_FS=m
-CONFIG_BEFS_FS=m
-CONFIG_BFS_FS=m
-CONFIG_EFS_FS=m
-CONFIG_CRAMFS=y
-CONFIG_VXFS_FS=m
-CONFIG_HPFS_FS=m
-CONFIG_QNX4FS_FS=m
-CONFIG_SYSV_FS=m
-CONFIG_UFS_FS=m
-CONFIG_NFS_FS=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-CONFIG_NFSD=y
-CONFIG_CRC_T10DIF=y
-CONFIG_FRAME_WARN=8092
-CONFIG_DEBUG_FS=y
-CONFIG_DETECT_HUNG_TASK=y
-# CONFIG_DEBUG_BUGVERBOSE is not set
-CONFIG_DEBUG_INFO=y
-CONFIG_STRICT_DEVMEM=y
-CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-CONFIG_CRYPTO_AES=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=y
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index d2e0fab..b5b03ff 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -6,6 +6,7 @@ CONFIG_AUDIT=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_RCU_FANOUT=32
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
@@ -13,6 +14,7 @@ CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
@@ -20,6 +22,7 @@ CONFIG_MODVERSIONS=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
+CONFIG_PHYSICAL_START=0x00000000
CONFIG_MPC8540_ADS=y
CONFIG_MPC8560_ADS=y
CONFIG_MPC85xx_CDS=y
@@ -31,6 +34,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -44,12 +48,15 @@ CONFIG_TQM8560=y
CONFIG_SBC8548=y
CONFIG_QUICC_ENGINE=y
CONFIG_QE_GPIO=y
+CONFIG_CPM2=y
CONFIG_HIGHMEM=y
CONFIG_BINFMT_MISC=m
CONFIG_MATH_EMULATION=y
+CONFIG_SWIOTLB=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_FSL_IFC=y
CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
CONFIG_PCI_MSI=y
CONFIG_RAPIDIO=y
CONFIG_NET=y
@@ -113,6 +120,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -129,10 +137,12 @@ CONFIG_PATA_VIA=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_FS_ENET=y
+CONFIG_FSL_PQ_MDIO=y
CONFIG_UCC_GETH=y
CONFIG_GIANFAR=y
CONFIG_E1000=y
CONFIG_E1000E=y
+CONFIG_PHYLIB=y
CONFIG_IGB=y
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
@@ -172,6 +182,8 @@ CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_SOUND=y
CONFIG_SND=y
+CONFIG_SND_MIXER_OSS=y
+CONFIG_SND_PCM_OSS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_DRIVERS is not set
CONFIG_SND_INTEL8X0=y
@@ -196,6 +208,7 @@ CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_USB=y
+CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_FSL=y
@@ -210,10 +223,12 @@ CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
+CONFIG_STAGING=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
@@ -254,6 +269,7 @@ CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_CRC_T10DIF=y
+CONFIG_FRAME_WARN=8092
CONFIG_CRC16=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
@@ -263,9 +279,11 @@ CONFIG_CRYPTO_LZO=y
CONFIG_DEBUG_FS=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
+CONFIG_STRICT_DEVMEM=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DEV_FSL_CAAM=y
CONFIG_CRYPTO_DEV_TALITOS=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 4cb7b59..7d96a9f 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -10,12 +10,14 @@ CONFIG_AUDIT=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
+CONFIG_RCU_FANOUT=32
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
CONFIG_EXPERT=y
CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
@@ -23,6 +25,7 @@ CONFIG_MODVERSIONS=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
+CONFIG_PHYSICAL_START=0x00000000
CONFIG_MPC8540_ADS=y
CONFIG_MPC8560_ADS=y
CONFIG_MPC85xx_CDS=y
@@ -34,6 +37,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -47,12 +51,15 @@ CONFIG_TQM8560=y
CONFIG_SBC8548=y
CONFIG_QUICC_ENGINE=y
CONFIG_QE_GPIO=y
+CONFIG_CPM2=y
CONFIG_HIGHMEM=y
CONFIG_BINFMT_MISC=m
CONFIG_MATH_EMULATION=y
+CONFIG_SWIOTLB=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_FSL_IFC=y
CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
CONFIG_PCI_MSI=y
CONFIG_RAPIDIO=y
CONFIG_NET=y
@@ -116,6 +123,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -131,9 +139,11 @@ CONFIG_PATA_ALI=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_FS_ENET=y
+CONFIG_FSL_PQ_MDIO=y
CONFIG_UCC_GETH=y
CONFIG_GIANFAR=y
CONFIG_E1000E=y
+CONFIG_PHYLIB=y
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
CONFIG_CICADA_PHY=y
@@ -173,6 +183,8 @@ CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_SOUND=y
CONFIG_SND=y
+CONFIG_SND_MIXER_OSS=y
+CONFIG_SND_PCM_OSS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_DRIVERS is not set
CONFIG_SND_INTEL8X0=y
@@ -197,6 +209,7 @@ CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_USB=y
+CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_FSL=y
@@ -211,10 +224,12 @@ CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
+CONFIG_STAGING=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
@@ -256,6 +271,7 @@ CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC16=y
+CNOFIG_FRAME_WARN=8092
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
@@ -264,6 +280,7 @@ CONFIG_CRYPTO_LZO=y
CONFIG_DEBUG_FS=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
+CONFIG_STRICT_DEVMEM=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
--
1.7.9.7
^ permalink raw reply related
* Ping Re: [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes
From: Joseph S. Myers @ 2013-11-11 14:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Liu Yu, linux-kernel, Shan Hai
In-Reply-To: <Pine.LNX.4.64.1311041649250.4290@digraph.polyomino.org.uk>
Ping. I haven't seen any comments on any of these patches.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* [PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
From: Aneesh Kumar K.V @ 2013-11-11 14:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
This patch depends on the below two changes
1) [PATCH v5 0/6] KVM: PPC: Book3S: MMIO support for Little Endian guests (kvm-ppc)
http://mid.gmane.org/1383672128-26795-1-git-send-email-clg@fr.ibm.com
2) [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
http://mid.gmane.org/1384178577-23721-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com
arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
arch/powerpc/kvm/book3s_pr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index 83da1f8..d339096 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -38,7 +38,7 @@
static void kvmppc_mmu_book3s_64_reset_msr(struct kvm_vcpu *vcpu)
{
- kvmppc_set_msr(vcpu, MSR_SF);
+ kvmppc_set_msr(vcpu, MSR_SF | (vcpu->arch.shared->msr & MSR_LE));
}
static struct kvmppc_slb *kvmppc_mmu_book3s_64_find_slbe(
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index a7fe87a..cf9362c 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -226,7 +226,7 @@ static void kvmppc_recalc_shadow_msr(struct kvm_vcpu *vcpu)
ulong smsr = vcpu->arch.shared->msr;
/* Guest MSR values */
- smsr &= MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE;
+ smsr &= MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE | MSR_LE;
/* Process MSR values */
smsr |= MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_PR | MSR_EE;
/* External providers the guest reserved */
--
1.8.3.2
^ permalink raw reply related
* [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Aneesh Kumar K.V @ 2013-11-11 14:02 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
NOTE: I am not sure why we were originally computing dsisr and dar. So may be
we need a variant of this patch. But with this and the additional patch
"powerpc: book3s: PR: Enable Little Endian PR guest" I am able to get a Little Endian
PR guest to boot.
arch/powerpc/kvm/book3s_emulate.c | 64 ++-------------------------------------
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 99d40f8..62768f9 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -569,70 +569,10 @@ unprivileged:
u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
{
- u32 dsisr = 0;
-
- /*
- * This is what the spec says about DSISR bits (not mentioned = 0):
- *
- * 12:13 [DS] Set to bits 30:31
- * 15:16 [X] Set to bits 29:30
- * 17 [X] Set to bit 25
- * [D/DS] Set to bit 5
- * 18:21 [X] Set to bits 21:24
- * [D/DS] Set to bits 1:4
- * 22:26 Set to bits 6:10 (RT/RS/FRT/FRS)
- * 27:31 Set to bits 11:15 (RA)
- */
-
- switch (get_op(inst)) {
- /* D-form */
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- dsisr |= (inst >> 12) & 0x4000; /* bit 17 */
- dsisr |= (inst >> 17) & 0x3c00; /* bits 18:21 */
- break;
- /* X-form */
- case 31:
- dsisr |= (inst << 14) & 0x18000; /* bits 15:16 */
- dsisr |= (inst << 8) & 0x04000; /* bit 17 */
- dsisr |= (inst << 3) & 0x03c00; /* bits 18:21 */
- break;
- default:
- printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
- break;
- }
-
- dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
-
- return dsisr;
+ return vcpu->arch.fault_dsisr;
}
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
{
- ulong dar = 0;
- ulong ra = get_ra(inst);
- ulong rb = get_rb(inst);
-
- switch (get_op(inst)) {
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- if (ra)
- dar = kvmppc_get_gpr(vcpu, ra);
- dar += (s32)((s16)inst);
- break;
- case 31:
- if (ra)
- dar = kvmppc_get_gpr(vcpu, ra);
- dar += kvmppc_get_gpr(vcpu, rb);
- break;
- default:
- printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
- break;
- }
-
- return dar;
+ return vcpu->arch.fault_dar;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH] powerpc: book3s: kvm: Don't abuse host r2 in exit path
From: Aneesh Kumar K.V @ 2013-11-11 13:59 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR
KVM mode when both HV and PR are enabled in the kernel. Without this we
get the below crash
(qemu)
Unable to handle kernel paging request for data at address 0xffffffffffff8310
Faulting instruction address: 0xc00000000001d5a4
cpu 0x2: Vector: 300 (Data Access) at [c0000001dc53aef0]
pc: c00000000001d5a4: .vtime_delta.isra.1+0x34/0x1d0
lr: c00000000001d760: .vtime_account_system+0x20/0x60
sp: c0000001dc53b170
msr: 8000000000009032
dar: ffffffffffff8310
dsisr: 40000000
current = 0xc0000001d76c62d0
paca = 0xc00000000fef1100 softe: 0 irq_happened: 0x01
pid = 4472, comm = qemu-system-ppc
enter ? for help
[c0000001dc53b200] c00000000001d760 .vtime_account_system+0x20/0x60
[c0000001dc53b290] c00000000008d050 .kvmppc_handle_exit_pr+0x60/0xa50
[c0000001dc53b340] c00000000008f51c kvm_start_lightweight+0xb4/0xc4
[c0000001dc53b510] c00000000008cdf0 .kvmppc_vcpu_run_pr+0x150/0x2e0
[c0000001dc53b9e0] c00000000008341c .kvmppc_vcpu_run+0x2c/0x40
[c0000001dc53ba50] c000000000080af4 .kvm_arch_vcpu_ioctl_run+0x54/0x1b0
[c0000001dc53bae0] c00000000007b4c8 .kvm_vcpu_ioctl+0x478/0x730
[c0000001dc53bca0] c0000000002140cc .do_vfs_ioctl+0x4ac/0x770
[c0000001dc53bd80] c0000000002143e8 .SyS_ioctl+0x58/0xb0
[c0000001dc53be30] c000000000009e58 syscall_exit+0x0/0x98
--- Exception: c00 (System Call) at 00001fffff960160
SP (1ffffecbe3c0) is in userspace
These changes were originally part of
http://mid.gmane.org/20130806042205.GR19254@iris.ozlabs.ibm.com
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 7 +++----
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 0bd9348..69fe837 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -79,6 +79,7 @@ struct kvmppc_host_state {
ulong vmhandler;
ulong scratch0;
ulong scratch1;
+ ulong scratch2;
u8 in_guest;
u8 restore_hid5;
u8 napping;
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 8e6ede6..841a4c8 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -583,6 +583,7 @@ int main(void)
HSTATE_FIELD(HSTATE_VMHANDLER, vmhandler);
HSTATE_FIELD(HSTATE_SCRATCH0, scratch0);
HSTATE_FIELD(HSTATE_SCRATCH1, scratch1);
+ HSTATE_FIELD(HSTATE_SCRATCH2, scratch2);
HSTATE_FIELD(HSTATE_IN_GUEST, in_guest);
HSTATE_FIELD(HSTATE_RESTORE_HID5, restore_hid5);
HSTATE_FIELD(HSTATE_NAPPING, napping);
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 339aa5e..16f7654 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -750,15 +750,14 @@ kvmppc_interrupt_hv:
* guest CR, R12 saved in shadow VCPU SCRATCH1/0
* guest R13 saved in SPRN_SCRATCH0
*/
- /* abuse host_r2 as third scratch area; we get r2 from PACATOC(r13) */
- std r9, HSTATE_HOST_R2(r13)
+ std r9, HSTATE_SCRATCH2(r13)
lbz r9, HSTATE_IN_GUEST(r13)
cmpwi r9, KVM_GUEST_MODE_HOST_HV
beq kvmppc_bad_host_intr
#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
cmpwi r9, KVM_GUEST_MODE_GUEST
- ld r9, HSTATE_HOST_R2(r13)
+ ld r9, HSTATE_SCRATCH2(r13)
beq kvmppc_interrupt_pr
#endif
/* We're now back in the host but in guest MMU context */
@@ -778,7 +777,7 @@ kvmppc_interrupt_hv:
std r6, VCPU_GPR(R6)(r9)
std r7, VCPU_GPR(R7)(r9)
std r8, VCPU_GPR(R8)(r9)
- ld r0, HSTATE_HOST_R2(r13)
+ ld r0, HSTATE_SCRATCH2(r13)
std r0, VCPU_GPR(R9)(r9)
std r10, VCPU_GPR(R10)(r9)
std r11, VCPU_GPR(R11)(r9)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/4] phylib: Add of_phy_attach
From: shh.xie @ 2013-11-11 11:08 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Shruti, Shaohui Xie, madalin.bucur
From: Andy Fleming
10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
drivers/of/of_mdio.c | 22 ++++++++++++++++++++--
include/linux/of_mdio.h | 8 ++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..a748274 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -221,8 +221,7 @@ EXPORT_SYMBOL(of_phy_connect);
* not call this function from new drivers.
*/
struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
- void (*hndlr)(struct net_device *),
- phy_interface_t iface)
+ void (*hndlr)(struct net_device *), phy_interface_t iface)
{
struct device_node *net_np;
char bus_id[MII_BUS_ID_SIZE + 3];
@@ -247,3 +246,22 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ struct phy_device *phy = of_phy_find_device(phy_np);
+
+ if (!phy)
+ return NULL;
+
+ return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..dcda44d 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,8 @@ extern struct phy_device *of_phy_connect(struct net_device *dev,
struct device_node *phy_np,
void (*hndlr)(struct net_device *),
u32 flags, phy_interface_t iface);
+extern struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface);
extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface);
@@ -44,6 +46,12 @@ static inline struct phy_device *of_phy_connect(struct net_device *dev,
return NULL;
}
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
static inline struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface)
--
1.8.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox