Re: [PATCH v9 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
Mark? ping.
On 09/03/2013 05:01 PM, Hongbo Zhang wrote:
On 09/02/2013 11:58 PM, Mark Rutland wrote:
Hi,
On Fri, Aug 30, 2013 at 12:26:19PM +0100, hongbo.zh...@freescale.com
wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 67
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 235 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index ddf17af..332ac77 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,73 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale
Txxx and Bxxx
I was under the impression EloPlus was the previous revision. Should
that say Elo3, or is Elo3 considered to be an EloPlus implementation?
In this patch 1/3 I revise the doc to make it clear we have Elo and
EloPlus, and I'm adding another new Elo3. Yes the only difference
between Elo3 and EloPlus is channel numbers(8 channels vs 4 channels),
so we can call "Elo3 is an 8-channel EloPlus"
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include "fsl,elo3-dma"
+- reg :
The example has two reg entries. What both are should be specified. From
what you described last time, it sounds like each is a status register
for four channels.
Presumably the first covers the channels at 0x0,0x80,0x100,0x180, and
the second covers the channels at 0x300,0x380,0x400,0x480? If the
registers have specific names in a datasheet, it would be worth
mentioning them.
Yes, each is a status register for four channels, you got it -- this
means my statement works.
Is it necessary to specify all the register names?
I can describe my two registers, but in other cases the reg entryies
can cover tens even hundreds of registers, just a summary is OK I think.
If the specification of the DMA controller allows for more channels, it
may be worth describing that case now.
This DMA controller doesn't allows for more channels. (Even if it
does, it should be another new controller)
+- ranges: describes the mapping between the address
space of the
+ DMA channels and the address space of the DMA
controller
This looks odd as a required property, and I'm slightly confused. Is
this used to map the reg values of the DMA channels, or is it used when
mapping the DMA address space (for which dma-ranges exists in ePAPR and
other bindings).
It is used to map the reg values of DMA channels.
+
+- DMA channel nodes:
+- compatible: must include "fsl,eloplus-dma-channel"
+- reg :
What does this represent? What are valid values?
In the example below it looks like these are offsets of control
registers within the dma controller.
Yes, they are offsets of control registers within dma controller, but
the contents in these registers are for dma channels.
Physically we have dma controller registers and dma channel registers,
they are in one continuous physical address space, we divide all these
registers into two controller/channel parts, according to contents in
these registers, common status registers for all channels are called
dma controller registers, otherwise channel specific registers are
called dma channel registers.
If the reg property may have any value, how do they get mapped to bits
in the status register(s)?
In fact, each channel has its own status register(and also other
registers), the dma controller status register is just aggregation of
all channel status register. (that seems duplicated somehow, maybe
this is due to hardware compatibility with legacy one, and the device
tree just describes the physical hardware without lie)
May some channels be unusable for some reason, or will all eight
channels be wired on any given Elo3 DMA?
Sorry, not get your point clearly, maybe you are clear now because of
my previous explanations.
Cheers,
Mark.
+- interrupts: IRQ>
+- interrupt-parent : optional, if needed for interrupt
mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x
[PATCH] powerpc/p1010rdb:update phy node in dts
Update phy node according to new P1010RDB-PB board.
Signed-off-by: Shengzhou Liu
Signed-off-by: Zhao Qiang
---
arch/powerpc/boot/dts/p1010rdb.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 7fc3402..8c675bf 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -199,7 +199,7 @@
mdio@24000 {
phy0: ethernet-phy@0 {
- interrupts = <3 1 0 0>;
+ interrupts = <0 1 0 0>;
reg = <0x1>;
};
@@ -209,7 +209,7 @@
};
phy2: ethernet-phy@2 {
- interrupts = <2 1 0 0>;
+ interrupts = <1 1 0 0>;
reg = <0x2>;
};
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 0/6] perf: New conditional branch filter
On 09/10/2013 07:36 AM, Michael Ellerman wrote: > On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote: >> This patchset is the re-spin of the original branch stack sampling >> patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset >> also enables SW based branch filtering support for PPC64 platforms which have >> branch stack sampling support. With this new enablement, the branch filter >> support >> for PPC64 platforms have been extended to include all these combinations >> discussed >> below with a sample test application program. > > ... > >> Mixed filters >> - >> (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog >> Error: >> The perf.data file has no samples! >> >> NOTE: As expected. The HW filters all the branches which are calls and SW >> tries to find return >> branches in that given set. Both the filters are mutually exclussive, so >> obviously no samples >> found in the end profile. > > The semantics of multiple filters is not clear to me. It could be an OR, > or an AND. You have implemented AND, does that match existing behaviour > on x86 for example? I believe it does match. X86 code drops the branch records (originally captured in the LBR) while applying the SW filters. Regards Anshuman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
On Mon, Sep 09, 2013 at 04:24:18PM +0100, Sudeep KarkadaNagesha wrote:
> Hi Shawn,
>
> Ok. But I am bit suspicious about devm_clk_get(cpu_dev, NULL).
> I don't understand completely as how the clock are registered(whether
> with dev_id or with connection_id).
As the connection_id of devm_clk_get() call here is NULL, the clock
lookup should be registered with a proper dev_id in clk_register_clkdev()
call. And that's what you have seen with imx and shmobile code.
> A quick grep revealed that i.mx and shmobile is using conection id while
> registering.
They are using dev_id.
> If the clock is registered with connection id and retrieved
> with cpu_dev(now dev_id is cpu0 and not cpufreq-cpu0), IIUC that would
> break. If we pass pdev->dev for clk_get, it should be fine but again
> IIUC it breaks highbank which gets all the information from DT.
If the clock lookup is from DT, we should be just fine, since it will
work as long as the DT node with 'clocks' property (/cpus/cpu@0 in this
case) is attached to the struct device pointer of devm_clk_get() call.
> So only solution I can think of is to continue to have the code
> assigning (&pdev->dev)->of_node with cpu device node which is not clean
> and arguable as incorrect since there is no DT node for cpufreq-cpu0.
> I don't have a strong opinion though.
>
> Let me know how would you like to fix this.
So we only need to change all clkdev registration to use "cpu0" as
dev_id intstead of "cpufreq-cpu0.0", something like below.
And for imx, it should work even without the changes, because we have
device tree lookup ready there, and those clk_register_clkdev() calls
can just be removed now. But I prefer to include the change and leave
the cleanup to another patch for keeping the change log clear.
Shawn
---8<--
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index c3cfa41..c6b40f3 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -285,7 +285,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[ata_ahb_gate], "ata", NULL);
clk_register_clkdev(clk[rtc_ipg_gate], NULL, "imx21-rtc");
clk_register_clkdev(clk[scc_ipg_gate], "scc", NULL);
- clk_register_clkdev(clk[cpu_div], NULL, "cpufreq-cpu0.0");
+ clk_register_clkdev(clk[cpu_div], NULL, "cpu0");
clk_register_clkdev(clk[emi_ahb_gate], "emi_ahb" , NULL);
mxc_timer_init(MX27_IO_ADDRESS(MX27_GPT1_BASE_ADDR), MX27_INT_GPT1);
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c
b/arch/arm/mach-imx/clk-imx51-imx53.c
index 1a56a33..de1964c 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -328,7 +328,7 @@ static void __init mx5_clocks_common_init(unsigned long
rate_ckil,
clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1");
clk_register_clkdev(clk[ssi3_ipg_gate], NULL, "imx-ssi.2");
clk_register_clkdev(clk[sdma_gate], NULL, "imx35-sdma");
- clk_register_clkdev(clk[cpu_podf], NULL, "cpufreq-cpu0.0");
+ clk_register_clkdev(clk[cpu_podf], NULL, "cpu0");
clk_register_clkdev(clk[iim_gate], "iim", NULL);
clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[dummy], NULL, "imx2-wdt.1");
diff --git a/arch/arm/mach-shmobile/clock-r8a73a4.c
b/arch/arm/mach-shmobile/clock-r8a73a4.c
index 8ea5ef6..5bd2e85 100644
--- a/arch/arm/mach-shmobile/clock-r8a73a4.c
+++ b/arch/arm/mach-shmobile/clock-r8a73a4.c
@@ -555,7 +555,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("pll2h", &pll2h_clk),
/* CPU clock */
- CLKDEV_DEV_ID("cpufreq-cpu0", &z_clk),
+ CLKDEV_DEV_ID("cpu0", &z_clk),
/* DIV6 */
CLKDEV_CON_ID("zb", &div6_clks[DIV6_ZB]),
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c
b/arch/arm/mach-shmobile/clock-sh73a0.c
index 1942eae..c92c023 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -616,7 +616,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("smp_twd", &twd_clk), /* smp_twd */
/* DIV4 clocks */
- CLKDEV_DEV_ID("cpufreq-cpu0", &div4_clks[DIV4_Z]),
+ CLKDEV_DEV_ID("cpu0", &div4_clks[DIV4_Z]),
/* DIV6 clocks */
CLKDEV_CON_ID("vck1_clk", &div6_clks[DIV6_VCK1]),
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 0/6] perf: New conditional branch filter
On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote: > This patchset is the re-spin of the original branch stack sampling > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset > also enables SW based branch filtering support for PPC64 platforms which have > branch stack sampling support. With this new enablement, the branch filter > support > for PPC64 platforms have been extended to include all these combinations > discussed > below with a sample test application program. ... > Mixed filters > - > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog > Error: > The perf.data file has no samples! > > NOTE: As expected. The HW filters all the branches which are calls and SW > tries to find return > branches in that given set. Both the filters are mutually exclussive, so > obviously no samples > found in the end profile. The semantics of multiple filters is not clear to me. It could be an OR, or an AND. You have implemented AND, does that match existing behaviour on x86 for example? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Export cpu_to_chip_id() to fix build error
powerpc allmodconfig build fails with: ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! The problem was introduced with commit 15863ff3b (powerpc: Make chip-id information available to userspace). Export the missing symbol. Cc: Vasant Hegde Cc: Shivaprasad G Bhat Signed-off-by: Guenter Roeck --- arch/powerpc/kernel/smp.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 442d8e2..8e59abc 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -611,6 +611,7 @@ int cpu_to_chip_id(int cpu) of_node_put(np); return of_get_ibm_chip_id(np); } +EXPORT_SYMBOL(cpu_to_chip_id); /* Helper routines for cpu to core mapping */ int cpu_core_index_of_thread(int cpu) -- 1.7.9.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)
On 09/09/2013 04:55 PM, Asai Thambi S P wrote: On 09/08/2013 5:28 PM, Guenter Roeck wrote: Hi all, powerpc allmodconfig build on the latest upstream kernel results in: ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! This is due to commit 15863ff3b (powerpc: Make chip-id information available to userspace). Not surprising, as cpu_to_chip_id() is not exported. Apart from the above error, I have a concern on the patch, purely based on the commit message. (to be honest, I am not familiar with the ppc architecture) Commit message of 15863ff3b has the following text. ** So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id" was always default (-1) on ppc64 architecture. Now, some systems have an ibm,chip-id property in the cpu nodes in the device tree. On these systems, we now use this information to display physical_package_id ** Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property? Looking into the code, I think that is what it does. For other platforms (ie if there is no ibm,chip-id property) it still returns -1. Question for the fix is what path to take to fix the problem. Exporting cpu_to_chip_id() might be the easiest solution. Other platforms export the respective data, so it should not be a problem. I might submit a patch and see where it goes. Guenter Reverting this commit fixes the problem. Any good idea how to fix it for real ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
Hi Tom, On Mon, 9 Sep 2013 07:44:54 -0500 Tom Musta wrote: > > > Looks like the patch has been mangled by the mailer ... it's in HTML to > > begin with :-) > > Frustrating. I did use a plain text option on the mail client and did a > test send to a few accounts before posting to the mailing list. The > patch was verified by checkpatch.pl before it got mangled. > > I will find a better setup and resubmit. Also please find a mailer that does *not* respond to the envelope recipient (linuxppc-dev-bounces+tmusta=us.ibm@lists.ozlabs.org in this case) as that just tends to irritate list owners. -- Cheers, Stephen Rothwells...@canb.auug.org.au (slightly irritated list owner :-)) pgpJ7nZ4PiscK.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc allmodconfig build broken due to commit 15863ff3b (powerpc: Make chip-id information available to userspace)
On 09/08/2013 5:28 PM, Guenter Roeck wrote: Hi all, powerpc allmodconfig build on the latest upstream kernel results in: ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined! This is due to commit 15863ff3b (powerpc: Make chip-id information available to userspace). Not surprising, as cpu_to_chip_id() is not exported. Apart from the above error, I have a concern on the patch, purely based on the commit message. (to be honest, I am not familiar with the ppc architecture) Commit message of 15863ff3b has the following text. ** So far "/sys/devices/system/cpu/cpuX/topology/physical_package_id" was always default (-1) on ppc64 architecture. Now, some systems have an ibm,chip-id property in the cpu nodes in the device tree. On these systems, we now use this information to display physical_package_id ** Shouldn't the new definition of "topology_physical_package_id" apply only to those systems supporting ibm,chip-id property? Reverting this commit fixes the problem. Any good idea how to fix it for real ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
> > Isn't that code occasionally used with uprobes too nowadays ? > > Yes. I believe so. I'm going to back-pedal a little. I reread code and can connect single step code to kprobes but not necessarily to uprobes. So I am not sure that this code is used with uprobes. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
> Looks like the patch has been mangled by the mailer ... it's in HTML to > begin with :-) Frustrating. I did use a plain text option on the mail client and did a test send to a few accounts before posting to the mailing list. The patch was verified by checkpatch.pl before it got mangled. I will find a better setup and resubmit. > Isn't that code occasionally used with uprobes too nowadays ? Yes. I believe so. Tom Musta (tmu...@us.ibm.com) Senior Software Engineer Blue Gene Kernel Development IBM Rochester (507) 253-4119 (T/L 553-4119)___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
big latency while under HV
Hi, i`m working on the embedded hypervisor targeting QorIQ platforms (p3041/p4080). I have working prototype starting custom RTOS on just single core in the guest space. What I see is the big latency (up to 3 times more) in RTOS running atop of HV comparing to RTOS running bare-metal. I`m using lmbench utility. It shows nteger mul: 3.48 nanoseconds integer div: 30.44 nanoseconds integer mod: 13.92 nanoseconds int64 bit: 1.75 nanoseconds int64 add: 1.42 nanoseconds int64 mul: 6.95 nanoseconds HV:hvpriv_count 6 int64 div: 447.56 nanoseconds int64 mod: 385.42 nanoseconds float add: 7.12 nanoseconds float mul: 6.95 nanoseconds float div: 33.05 nanoseconds double add: 7.11 nanoseconds double mul: 8.70 nanoseconds double div: 57.36 nanoseconds float bogomflops: 46.98 nanoseconds double bogomflops: 73.09 nanoseconds The bare-metal results are 3x better. Does anybody have any ideas on what may be the source of such latency ? I forward all the exceptions to the guest w/o affecting HV. Only hvpriv is processed, it takes not more than 2 bus cycles. Sorry for poor english ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
On 09/09/13 15:32, Shawn Guo wrote:
> Hi Sudeep,
>
> On Mon, Sep 09, 2013 at 10:24:39AM +0100, Sudeep KarkadaNagesha wrote:
>> Hi Shawn,
>>
>> Can you please clarify ? The fix would be as below but I would like to
>> know if setting cpu_dev to get_cpu_device(0) instead of &pdev->dev has
>> any impact on other parts of code using cpu_dev ?
>
> I'm sorry. I should have given it a test on hardware before ACKing the
> changes.
>
> The fix below should not have other impact except the prefix of dev_err
> [info, dbg] message output ('cpufreq-cpu0:' to 'cpu cpu0:'), which
> shouldn't be a problem.
>
Hi Shawn,
Ok. But I am bit suspicious about devm_clk_get(cpu_dev, NULL).
I don't understand completely as how the clock are registered(whether
with dev_id or with connection_id).
A quick grep revealed that i.mx and shmobile is using conection id while
registering. If the clock is registered with connection id and retrieved
with cpu_dev(now dev_id is cpu0 and not cpufreq-cpu0), IIUC that would
break. If we pass pdev->dev for clk_get, it should be fine but again
IIUC it breaks highbank which gets all the information from DT.
So only solution I can think of is to continue to have the code
assigning (&pdev->dev)->of_node with cpu device node which is not clean
and arguable as incorrect since there is no DT node for cpufreq-cpu0.
I don't have a strong opinion though.
Let me know how would you like to fix this.
>>
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index cbfffa9..871c336 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -177,7 +177,7 @@ static int cpu0_cpufreq_probe(struct platform_device
>> *pdev)
>> struct device_node *np;
>> int ret;
>>
>> - cpu_dev = &pdev->dev;
>> + cpu_dev = get_cpu_device(0);
>>
>> np = of_node_get(cpu_dev->of_node);
>> if (!np) {
>>
>
> The imx6q-cpufreq driver needs a similar fixing. Please include the
> following changes into your fixing patches. Thanks.
>
Ok no problem I can post the fix based on response for the above question.
Regard,
Sudeep
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
Hi Sudeep,
On Mon, Sep 09, 2013 at 10:24:39AM +0100, Sudeep KarkadaNagesha wrote:
> Hi Shawn,
>
> Can you please clarify ? The fix would be as below but I would like to
> know if setting cpu_dev to get_cpu_device(0) instead of &pdev->dev has
> any impact on other parts of code using cpu_dev ?
I'm sorry. I should have given it a test on hardware before ACKing the
changes.
The fix below should not have other impact except the prefix of dev_err
[info, dbg] message output ('cpufreq-cpu0:' to 'cpu cpu0:'), which
shouldn't be a problem.
>
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index cbfffa9..871c336 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -177,7 +177,7 @@ static int cpu0_cpufreq_probe(struct platform_device
> *pdev)
> struct device_node *np;
> int ret;
>
> - cpu_dev = &pdev->dev;
> + cpu_dev = get_cpu_device(0);
>
> np = of_node_get(cpu_dev->of_node);
> if (!np) {
>
The imx6q-cpufreq driver needs a similar fixing. Please include the
following changes into your fixing patches. Thanks.
Shawn
---8<-
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 85a1b51..69fd4b6 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -233,9 +233,10 @@ put_node:
of_node_put(np);
}
-static void __init imx6q_opp_init(struct device *cpu_dev)
+static void __init imx6q_opp_init(void)
{
struct device_node *np;
+ struct device *cpu_dev = get_cpu_device(0);
np = of_node_get(cpu_dev->of_node);
if (!np) {
@@ -268,7 +269,7 @@ static void __init imx6q_init_late(void)
imx6q_cpuidle_init();
if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ)) {
- imx6q_opp_init(&imx6q_cpufreq_pdev.dev);
+ imx6q_opp_init();
platform_device_register(&imx6q_cpufreq_pdev);
}
}
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 3e39654..d7ebd91 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -202,7 +203,7 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
unsigned long min_volt, max_volt;
int num, ret;
- cpu_dev = &pdev->dev;
+ cpu_dev = get_cpu_device(0);
np = of_node_get(cpu_dev->of_node);
if (!np) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
On Mon, 2013-09-09 at 08:35 +1000, Paul Mackerras wrote: > > Also, you need to indent your code correctly according to > Documentation/CodingStyle. Looks like the patch has been mangled by the mailer ... it's in HTML to begin with :-) Tom, you need to find a mailer setup that works for sending patches, basically that sends them in plain text without any mangling of tabs and spaces and without word wrapping. I personally use "evolution" under Linux which has a "preformatted" style mode for that but I'm sure there are plenty of other options. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly
On Mon, 2013-09-09 at 08:35 +1000, Paul Mackerras wrote: > On Fri, Sep 06, 2013 at 10:13:00AM -0500, Tom Musta wrote: > > To: linuxppc-dev@lists.ozlabs.org > > Subject: [PATCH] powerpc: OE=1 Form Instructions Not Decoded Correctly > > From: Tom Musta > > > > PowerISA uses instruction bit 21 to indicate that the overflow (OV) bit > > of the XER is to be set, as well as its corresponding sticky bit (SO). > > This patch addresses two defects in the implementation of the PowerISA > > single step code for this category of instructions: (a) the OE=1 case > > is not correctly accounted for in the case statement for the extended > > opcode handling. (b) the implementation is not setting XER[OV] and > > XER[SO]. > > Are you seeing any actual problems arising from the OE=1 instructions > not being emulated? This code was designed primarily for emulating > instructions in the kernel, which is written in C, and the C compiler > doesn't emit OE=1 instructions -- or at least it didn't in the past. > So, does the impetus for this change come because the C compiler is > now emitting these instructions, or because this code is being used on > non-kernel instructions, or just for completeness? Your patch > description needs to include answers to these kinds of questions. Isn't that code occasionally used with uprobes too nowadays ? Cheers, Ben. > Also, you need to indent your code correctly according to > Documentation/CodingStyle. > > Paul. > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
The sub-nodes are also reorganized according to right I2C topology.
Signed-off-by: Jia Hongtao
---
V3 change log:
* Change "channel" to "i2c" based on i2c-mux binding.
* Update vendor from philips to nxp.
V2 change log:
* Reorganized the sub-nodes under I2C multiplexer to represent right topology.
arch/powerpc/boot/dts/b4qds.dtsi | 51 +---
arch/powerpc/boot/dts/t4240qds.dts | 69 ++
2 files changed, 73 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..8b47edc 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,25 +120,38 @@
};
i2c@118000 {
- eeprom@50 {
- compatible = "at24,24c64";
- reg = <0x50>;
- };
- eeprom@51 {
- compatible = "at24,24c256";
- reg = <0x51>;
- };
- eeprom@53 {
- compatible = "at24,24c256";
- reg = <0x53>;
- };
- eeprom@57 {
- compatible = "at24,24c256";
- reg = <0x57>;
- };
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
+ mux@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@50 {
+ compatible = "at24,24c64";
+ reg = <0x50>;
+ };
+ eeprom@51 {
+ compatible = "at24,24c256";
+ reg = <0x51>;
+ };
+ eeprom@53 {
+ compatible = "at24,24c256";
+ reg = <0x53>;
+ };
+ eeprom@57 {
+ compatible = "at24,24c256";
+ reg = <0x57>;
+ };
+ rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+ };
};
};
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..a35508f 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,34 +118,47 @@
};
i2c@118000 {
- eeprom@51 {
- compatible = "at24,24c256";
- reg = <0x51>;
- };
- eeprom@52 {
- compatible = "at24,24c256";
- reg = <0x52>;
- };
- eeprom@53 {
- compatible = "at24,24c256";
- reg = <0x53>;
- };
- eeprom@54 {
- compatible = "at24,24c256";
- reg = <0x54>;
- };
- eeprom@55 {
- compatible = "at24,24c256";
- reg = <0x55>;
- };
- eeprom@56 {
- compatible = "at24,24c256";
- reg = <0x56>;
- };
- rtc@68 {
- compatible = "dallas,ds3232";
- reg = <0x68>;
- interrupts = <0x1 0x1 0 0>;
+ mux@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+
Re: Please pull 'next' branch of 5xxx tree
On Thu, 05 Sep 2013 16:50:48 +1000 Benjamin Herrenschmidt wrote: ... > Thanks. BTW. Next time, any chance you can base this off the same point > in Linus tree where my next branch is based ? Or base of my next > branch :-) Okay, I will base of your next branch. Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v3 04/12] Validate r1 value before going to host kernel in virtual mode.
On Mon, 2013-09-09 at 15:29 +1000, Paul Mackerras wrote: > Are we guaranteed that Sapphire will keep the stack pointer positive > at all times? (More a question for Ben H than you.) Good point, we *might* eventually set the top bit.. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes
On 06/09/13 14:44, Guennadi Liakhovetski wrote:
> Hi
>
> On Tue, 20 Aug 2013, Sudeep KarkadaNagesha wrote:
>
>> From: Sudeep KarkadaNagesha
>>
>> Now that the cpu device registration initialises the of_node(if available)
>> appropriately for all the cpus, parsing here is redundant.
>>
>> This patch removes all DT parsing and uses cpu->of_node instead.
>>
>> Acked-by: Shawn Guo
>> Acked-by: Rob Herring
>> Acked-by: Viresh Kumar
>> Signed-off-by: Sudeep KarkadaNagesha
>> ---
>> drivers/cpufreq/cpufreq-cpu0.c | 23 ---
>> 1 file changed, 4 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.=
>> c
>> index ad1fde2..5b05c26 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -174,29 +174,17 @@ static struct cpufreq_driver cpu0_cpufreq_driver =3D =
>> {
>> =20
>> static int cpu0_cpufreq_probe(struct platform_device *pdev)
>> {
>> -=09struct device_node *np, *parent;
>> +=09struct device_node *np;
>> =09int ret;
>> =20
>> -=09parent =3D of_find_node_by_path("/cpus");
>> -=09if (!parent) {
>> -=09=09pr_err("failed to find OF /cpus\n");
>> -=09=09return -ENOENT;
>> -=09}
>> -
>> -=09for_each_child_of_node(parent, np) {
>> -=09=09if (of_get_property(np, "operating-points", NULL))
>> -=09=09=09break;
>> -=09}
>> +=09cpu_dev =3D &pdev->dev;
>> =20
>> +=09np =3D of_node_get(cpu_dev->of_node);
>
> Has this actually been tested? This seems to break cpufreq-cpu0. The
> reason is, that this probe function is called not for the DT CPU node, but
> for a special virtual cpufreq-cpu0 platform device, typically created by
> platforms, using
>
> platform_device_register_simple("cpufreq-cpu0", -1, NULL, 0);
>
> which then of course doesn't have on .of_node associated with it.
>
Hi Guennadi,
Based on my understanding of the original code:
cpu_dev = &pdev->dev;
...
ret = of_init_opp_table(cpu_dev);
of_init_opp_table needs cpu_dev to be get_cpu_device(0). My
understanding was that platform using cpufreq-cpu0 sets &pdev->dev to
get_cpu_device(0). But looks like that's not the case.
Hi Shawn,
Can you please clarify ? The fix would be as below but I would like to
know if setting cpu_dev to get_cpu_device(0) instead of &pdev->dev has
any impact on other parts of code using cpu_dev ?
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index cbfffa9..871c336 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -177,7 +177,7 @@ static int cpu0_cpufreq_probe(struct platform_device
*pdev)
struct device_node *np;
int ret;
- cpu_dev = &pdev->dev;
+ cpu_dev = get_cpu_device(0);
np = of_node_get(cpu_dev->of_node);
if (!np) {
Regards,
Sudeep
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
