On Wed, Jan 16, 2013 at 09:48:25AM +0800, Peter Chen wrote:
> On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> > On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > > As mach/hardware.h is deleted, we need to use platform_device_id to
> > > differentiate SoCs. Besides, one c
On Thu, Jan 17, 2013 at 11:14:22AM +0200, Felipe Balbi wrote:
> On Wed, Jan 16, 2013 at 09:48:25AM +0800, Peter Chen wrote:
> > On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> > > On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > > > As mach/hardware.h is deleted, we need
Hi,
On Thu, Jan 17, 2013 at 05:28:30PM +0800, Peter Chen wrote:
> > > > From what I understand balbi's comment, he dislikes this full list of
> > > > device id. Instead, he prefers to something like below.
> > > >
> > > > static const struct platform_device_id fsl_udc_devtype[] = {
> > > >
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 bytes.? The
last of 5 is:
| 0x69 0x6d 0x78 0x2d 0x75 0x64 0x63 0x2d 0x6d 0x7
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime
Meanwhile we update the platform code accordingly.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/devices/devices-co
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/clk-imx25.c |6 +++---
arch/arm/mach-imx/clk-imx27.c |6 +++---
arch/arm/mach-imx/clk-imx31.
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/fsl_mxc_udc.c | 30 +++---
drivers
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 bytes.? The
last of 5 is:
| 0x69 0x6d 0x78 0x2d 0x75 0x64 0x63 0x2d 0x6d 0x7
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/fsl_mxc_udc.c | 30 +++---
drivers
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime
Meanwhile we update the platform code accordingly.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/devices/devices-co
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/clk-imx25.c |6 +++---
arch/arm/mach-imx/clk-imx27.c |6 +++---
arch/arm/mach-imx/clk-imx31.
On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
>
> Signed-off-by: Peter Chen
do I get Acked-by for this one ?
--
balbi
signature.asc
Descri
On Thu, Jan 17, 2013 at 12:58:33PM +0200, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> >
> > Signed-off-by: Peter C
Hi,
On Thursday 17 January 2013 03:09 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding information between the PHY and
Hi Michal,
On 01/16/2013 10:14 PM, Michal Hocko wrote:
> On Wed 16-01-13 16:14:18, Lin Feng wrote:
> [...]
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 278e3ab..f8c5799 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -162,10 +162,18 @@ config MOVABLE_NODE
>>Say Y here if you want
On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen wrote:
> /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> - if (!cpu_is_mx51()) {
> + if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]
Shouldn't this be:
if (!strcmp(pdev->id_entry->name, "imx-udc-mx51"))
__
Hi,
On Thursday 17 January 2013 03:07 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
New platforms are added which has multiple PHY's (of same type) and
which has multiple USB controllers. The binding information has to be
present in the PHY library (otg.c) in or
Hi,
On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
Hi Kishon,
On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I wrote:
This is in preparation for the changes in PHY library to support adding
and getting multiple PHYs of the same type. In the new design, the
binding informati
On Thu 17-01-13 18:37:10, Lin Feng wrote:
[...]
> > I am still not sure I understand the relation to MEMORY_HOTREMOVE.
> > Is register_page_bootmem_info_node required/helpful even if
> > !CONFIG_MEMORY_HOTREMOVE?
> From old kenrel's view register_page_bootmem_info_node() is defined in
> CONFIG_MEM
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> New platforms are added which has multiple PHY's (of same type) and
> which has multiple USB controllers. The binding information has to be
> present in the PHY library (otg.c) in order for it to return the
> appropriate PHY whenever the USB c
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specified in the platform spe
Hi,
Fabio Estevam writes:
> On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen wrote:
>
> > /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> > - if (!cpu_is_mx51()) {
> > + if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]
>
> Shouldn't this be:
> if (!strcmp(pdev->
Hi Kishon,
On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I wrote:
> This is in preparation for the changes in PHY library to support adding
> and getting multiple PHYs of the same type. In the new design, the
> binding information between the PHY and the USB controller should be
> specif
Hi Kishon,
Thanks for the explanation.
On Thu, Jan 17, 2013 at 6:01 PM, kishon wrote:
> Hi,
>
>
> On Thursday 17 January 2013 05:41 PM, Vivek Gautam wrote:
>>
>> Hi Kishon,
>>
>>
>> On Wed, Jan 16, 2013 at 8:30 PM, Kishon Vijay Abraham I
>> wrote:
>>>
>>> This is in preparation for the changes
On Wed, Jan 16, 2013 at 10:58:16AM -0800, Sukadev Bhattiprolu wrote:
> Jiri Olsa [jo...@redhat.com] wrote:
> | On Tue, Jan 15, 2013 at 03:57:59PM -0300, Arnaldo Carvalho de Melo wrote:
> | > Em Wed, Jan 09, 2013 at 05:07:03PM -0800, Sukadev Bhattiprolu escreveu:
> | > > [PATCH 6/6][v3] perf: Docume
On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann
wrote:
> The equivalent of !cpu_is_mx51() would be
> strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> id_entry->name is different from "imx-udc-mx51".
Yes, agree.
strcmp(pdev->id_entry->name, "imx-udc-mx51") is also better
On Wednesday 2012-08-15 23:36, Benjamin Herrenschmidt wrote:
>BTW... On a somewhat related note ... if you happen to have a spare
>Xserve G5 PSU I'm interested :-)
I tried pulling it out, but the PSU stuck so hard in the ATX-like
mainboard power socket that removing the PSU would have probably
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, the API's
> for adding PHY and getting PHY has been changed. Now the binding
> information of the PHY and controller should be done in platform file
> using usb_bind_phy API. And for
>From 776e6d7942754f139c27753213c9cf4617536618 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Thu, 17 Jan 2013 09:11:30 -0800
Subject: [PATCH] perf; Fix PMU format parsing test failure
On POWER, the 'perf format parsing' test always fails.
Looks like it is because memset() is being pa
On Thu, Jan 17, 2013 at 09:28:14AM -0800, Sukadev Bhattiprolu wrote:
>
> From 776e6d7942754f139c27753213c9cf4617536618 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Thu, 17 Jan 2013 09:11:30 -0800
> Subject: [PATCH] perf; Fix PMU format parsing test failure
>
> On POWER, the 'perf
On Thu, 2013-01-17 at 01:50 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 10, 2013 04:40:18 PM Toshi Kani wrote:
> > This patchset is a prototype of proposed system device hot-plug framework
> > for design review. Unlike other hot-plug environments, such as USB and
> > PCI, there is no co
From: Timur Tabi
Fix and/or improve the compatible strings of the PCI device tree nodes for
some Freescale SOCs. This fixes some issues and improves consistency among
the SOCs.
Specifically:
1) The P1022 has a v1 PCIe controller, so the compatible property should just
say "fsl,mpc8548-pcie".
From: Timur Tabi
The PAMU caches use the LIODNs to determine which cache lines hold the
entries for the corresponding LIODs. The LIODNs must therefore be
carefully assigned to avoid cache thrashing -- two active LIODs with
LIODNs that put them in the same cache line.
Currently, LIODNs are stati
Hello.
I want to make some fixups to the marvell hostbridge and
mpsc code and would like to test them on a PrPmc280/2800.
The problem is, I don't have one anymore.
If you have one handy and don't mind running a quick boot
test for me, please let me know.
Thanks,
Mark
--
___
From: Timur Tabi
The Freescale DIU driver was recently updated to not require every DIU
platform function, so now we can remove the unneeded functions from
some boards.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/512x/mpc512x_shared.c |5 ---
arch/powerpc/platforms/85xx/p1022_ds.c
On Thu, 2013-01-17 at 15:38 +0100, Jan Engelhardt wrote:
>
> Meanwhile, I run Linux 3.7.1 and the software side changed somewhat.
> windfarm_rm31 seems to no longer calm the fans down once loaded,
> whereas therm_pm72 on Linux 3.0 did so.
Hrm, that would be a bug ... unfortunately I never got to
This allows platform_device_add a chance to call insert_resource on all
of the resources from OF. At a minimum this fills in proc/iomem and
presumably makes resource tracking and conflict detection work better.
However, it has the side effect of moving all OF generated platform
devices from /sys/de
The Bestcomm driver requests a memory region larger than the one
described in the device tree. This is due to an extra undocumented field
in the bestcomm register structure. This hasn't been a problem up to
now, but there is a patch pending to make the DT platform_bus support
code use platform_devi
On Thu, Jan 17, 2013 at 12:43:23PM -0200, Fabio Estevam wrote:
> On Thu, Jan 17, 2013 at 9:25 AM, Lothar Waßmann
> wrote:
>
> > The equivalent of !cpu_is_mx51() would be
> > strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
> > id_entry->name is different from "imx-udc-mx51"
Changes for v7:
- Change !strcmp(str1, str2) to strcmp(str1, str2) == 0
Changes for v6:
- Only using imx-udc-mx27 and imx-udc-mx51 stands for
all kinds of i.mx udc
- Fix below build error for platform_device_id at fsl_udc_core.c
drivers/usb/gadget/fsl_usb2_udc: struct platform_device_id is 24 byte
As mach/hardware.h is deleted, we need to use platform_device_id to
differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
already used pdata to differentiate runtime
Meanwhile we update the platform code accordingly.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/devices/devices-co
As mach/hardware.h is deleted, we can't visit platform code at driver.
It has no phy driver to combine with this controller, so it has to use
ioremap to map phy address as a workaround.
Signed-off-by: Peter Chen
---
drivers/usb/gadget/fsl_mxc_udc.c | 30 +++---
drivers
As we use platform_device_id for fsl-usb2-udc driver, it needs to
change clk connection-id, or the related devm_clk_get will be failed.
Signed-off-by: Peter Chen
---
arch/arm/mach-imx/clk-imx25.c |6 +++---
arch/arm/mach-imx/clk-imx27.c |6 +++---
arch/arm/mach-imx/clk-imx31.
Peter,
On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
>
> Signed-off-by: Peter Chen
You should have my ACK put after your SoB, since I have pr
On Fri, Jan 18, 2013 at 10:23:39AM +0800, Shawn Guo wrote:
> Peter,
>
> On Fri, Jan 18, 2013 at 10:15:49AM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> >
> > Signed-off-by
Hi,
On Thursday 17 January 2013 09:37 PM, Roger Quadros wrote:
On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
In order to add support for multipe PHY's of the same type, the API's
for adding PHY and getting PHY has been changed. Now the binding
information of the PHY and controller shoul
POWER8 implements hardware transactional memory support. This patch series
adds kernel support so that user programs can use this hardware transactional
memory and the new state is properly context switched. It is not currently
used by the kernel itself.
This patch series was originally develope
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/cputable.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 06f7fb9..71a498b 100644
--- a/arch/powerpc/include/asm/c
Here we define the new instructions we need for transactional memory in the
kernel. This is so we can support compiling with binutils that don't support
the new transactional memory instructions.
Transactional memory results in two sets of architected state (GPRs/VSRs
etc).
treclaim allows us to
Set of new archtected state for saving away on context switch.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/processor.h | 28
1 file changed, 28 insertions(+)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/power
This adds new macros for saving and restoring checkpointed architected state
from and to the thread_struct.
It also adds some debugging macros for when your brain explodes trying to debug
your transactional memory enabled kernel.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arc
Defines for MSR bits and transactional memory related SPRs TFIAR, TEXASR and
TEXASRU.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/a
Add transactional memory paca scratch register to show_regs. This is useful
for debugging.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/paca.h |1 +
arch/powerpc/kernel/asm-offsets.c |1 +
arch/powerpc/kernel/entry_64.S|4
arch/po
Here we add the helper functions to be used when context switching. These
allow us to fully reclaim and recheckpoint a transaction.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h |2 +-
arch/powerpc/include/asm/tm.h | 20 +++
arch/powerpc/ker
This adds functions to restore the state of the FP/VSX registers from
what's stored in the thread_struct. Two version for FP/VSX are required
since one restores them from transactional/checkpoint side of the
thread_struct and the other from the speculated side.
Similar functions are added for VMX
When we switch out a task, we need to save both the checkpointed and the
speculated state into the thread struct.
Similarly when we are switching in a task we need to load both the checkpointed
and speculated state. If the task was using FP, we non-lazily reload both the
original and the speculat
These should never happen since we always turn on MSR TM when in userspace. We
don't do lazy TM.
Hence if we hit this, we barf and kill the task as something's gone horribly
wrong.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/kernel/exceptions-64s.S | 19
We do lazy FP but not lazy TM (ie. userspace starts with MSR TM=1 FP=0). Hence
if userspace does an FP instruction during a transaction, we'll take an
fp unavailable exception.
This adds functions needed to handle this case. We have to inject the current
FP state into the checkpoint so that the
This hooks the new transactional memory code into context switching, FP/VMX/VMX
unavailable and exception return.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/kernel/exceptions-64s.S | 48 --
arch/powerpc/kernel/fpu.S|
This adds the new transactional memory archtected state to the signal context
in both 32 and 64 bit.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h |1 +
arch/powerpc/kernel/signal.h|8 +
arch/powerpc/kernel/signal_32.c | 500 ++
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/cputable.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 71a498b..5ab77f4 100644
--- a/arch/powerpc/incl
Kconfig option for transactional memory on powerpc.
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/Kconfig |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 684fa64..349ed12 100644
--- a/arch/powerpc/Kconf
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
arch/powerpc/configs/ppc64_defconfig |2 ++
arch/powerpc/configs/pseries_defconfig |2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 6cbde
Signed-off-by: Matt Evans
Signed-off-by: Michael Neuling
---
Documentation/powerpc/transactional_memory.txt | 175
1 file changed, 175 insertions(+)
create mode 100644 Documentation/powerpc/transactional_memory.txt
diff --git a/Documentation/powerpc/transactional_memo
Hi Michal,
On 01/17/2013 09:05 PM, Michal Hocko wrote:
> On Thu 17-01-13 18:37:10, Lin Feng wrote:
> [...]
>>> > > I am still not sure I understand the relation to MEMORY_HOTREMOVE.
>>> > > Is register_page_bootmem_info_node required/helpful even if
>>> > > !CONFIG_MEMORY_HOTREMOVE?
>> > From old
65 matches
Mail list logo