* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-19 18:10 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, LiuShuo, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4E2571.20409@parrot.com>
On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> LiuShuo a =C3=A9crit :
>> =E4=BA=8E 2011=E5=B9=B408=E6=9C=8819=E6=97=A5 01:00, Matthieu CASTET =E5=
=86=99=E9=81=93:
>>> b35362@freescale.com a =C3=A9crit :
>>>> From: Liu Shuo<b35362@freescale.com>
>>>>
>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In =
order
>>>> to support the Nand flash chip whose page size is larger than 2K byt=
es,
>>>> we divide a page into multi-2K pages for MTD layer driver. In that c=
ase,
>>>> we force to set the page size to 2K bytes. We convert the page addre=
ss of
>>>> MTD layer driver to a real page address in flash chips and a column =
index
>>>> in fsl_elbc driver. We can issue any column address by UA instructio=
n of
>>>> elbc controller.
>>>>
>>> Why do you need to do that ?
>>>
>>> When mtd send you a 4k page, why can't you write it by 2*2k pages wri=
te ?
>> 1. It's easy to implement.
>> 2. We don't need to move the data in buffer more times, because we
>> want to use the HW_ECC.
>>
>> In flash chip per Page:
>> ----------------------------------------------------------------
>> | first data | first oob | second data | second oob |
>> ----------------------------------------------------------------
> How the bad block marker are handled with this remapping ?
It has to be migrated prior to first use (this needs to be documented,
and ideally a U-Boot command provided do do this), or else special
handling would be needed when building the BBT. The only way around
this would be to do ECC in software, and do the buffering needed to let
MTD treat it as a 4K chip.
-Scott
^ permalink raw reply
* [PATCH 40/75] pasemi: convert to SKB paged frag API.
From: Ian Campbell @ 2011-08-19 13:27 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, devicetree-discuss, linux-kernel, Olof Johansson,
linuxppc-dev
In-Reply-To: <1313760393.5010.356.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
---
drivers/net/pasemi_mac.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 9ec112c..3cd2cd3 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1505,9 +1505,8 @@ static int pasemi_mac_start_tx(struct sk_buff *skb, struct net_device *dev)
for (i = 0; i < nfrags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- map[i+1] = pci_map_page(mac->dma_pdev, frag->page,
- frag->page_offset, frag->size,
- PCI_DMA_TODEVICE);
+ map[i + 1] = skb_frag_dma_map(&mac->dma_pdev->dev, frag, 0,
+ frag->size, PCI_DMA_TODEVICE);
map_size[i+1] = frag->size;
if (pci_dma_mapping_error(mac->dma_pdev, map[i+1])) {
nfrags = i;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-19 8:57 UTC (permalink / raw)
To: LiuShuo
Cc: linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4DD661.5080006@freescale.com>
LiuShuo a écrit :
> 于 2011年08月19日 01:00, Matthieu CASTET 写道:
>> b35362@freescale.com a écrit :
>>> From: Liu Shuo<b35362@freescale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>> we divide a page into multi-2K pages for MTD layer driver. In that case,
>>> we force to set the page size to 2K bytes. We convert the page address of
>>> MTD layer driver to a real page address in flash chips and a column index
>>> in fsl_elbc driver. We can issue any column address by UA instruction of
>>> elbc controller.
>>>
>> Why do you need to do that ?
>>
>> When mtd send you a 4k page, why can't you write it by 2*2k pages write ?
> 1. It's easy to implement.
> 2. We don't need to move the data in buffer more times, because we
> want to use the HW_ECC.
>
> In flash chip per Page:
> ----------------------------------------------------------------
> | first data | first oob | second data | second oob |
> ----------------------------------------------------------------
How the bad block marker are handled with this remapping ?
Mtd will search in the first oob, but this will be the data zone of the nand,
not where manufacturer put marker.
Matthieu
^ permalink raw reply
* [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: K.Prasad @ 2011-08-19 7:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
In-Reply-To: <20110819074527.GA21817@in.ibm.com>
While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
user-space debuggers (like GDB) who may want to use it. Hence we introduce a
new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
"features" member of "struct ppc_debug_info" to advertise support for the
same on Book3E PowerPC processors.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 48223f9..cf014f9 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -380,6 +380,7 @@ struct ppc_debug_info {
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x0000000000000002
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x0000000000000004
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0000000000000008
+#define PPC_DEBUG_FEATURE_DATA_BP_EXACT 0x0000000000000010
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 18d28b6..71db5a6 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1636,6 +1636,7 @@ long arch_ptrace(struct task_struct *child, long request,
#ifdef CONFIG_PPC_ADV_DEBUG_DAC_RANGE
dbginfo.features |=
PPC_DEBUG_FEATURE_DATA_BP_RANGE |
+ PPC_DEBUG_FEATURE_DATA_BP_EXACT |
PPC_DEBUG_FEATURE_DATA_BP_MASK;
#endif
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-08-19 7:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
In-Reply-To: <20110819074527.GA21817@in.ibm.com>
PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
PowerPC specific ptrace flags that use the watchpoint register. While they are
targeted primarily towards BookE users, user-space applications such as GDB
have started using them for BookS too.
This patch enables the use of generic hardware breakpoint interfaces for these
new flags. The version number of the associated data structures
"ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
Apart from the usual benefits of using generic hw-breakpoint interfaces, these
changes allow debuggers (such as GDB) to use a common set of ptrace flags for
their watchpoint needs and allow more precise breakpoint specification (length
of the variable can be specified).
[Edjunior: Identified an issue in the patch with the sanity check for version
numbers]
Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/powerpc/ptrace.txt | 16 ++++++
arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++---
2 files changed, 112 insertions(+), 8 deletions(-)
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499..97301ae 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS) using version 2
+
+ p.version = 2;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..18d28b6 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1339,11 +1339,17 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret, len = 0;
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
- if (bp_info->version != 1)
+ if ((bp_info->version != 1) && (bp_info->version != 2))
return -ENOTSUPP;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
@@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
*/
if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
(bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
- bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
- if (child->thread.dabr)
- return -ENOSPC;
-
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1398,15 +1400,86 @@ static long ppc_set_hwdebug(struct task_struct *child,
dabr |= DABR_DATA_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (bp_info->version == 1)
+ goto version_one;
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
- child->thread.dabr = dabr;
+ bp = thread->ptrace_bps[0];
+ if (!bp_info->addr) {
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+ }
+ /*
+ * Check if the request is for 'range' breakpoints. We can
+ * support it if range < 8 bytes.
+ */
+ if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
+ len = bp_info->addr2 - bp_info->addr;
+ else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
+ ptrace_put_breakpoints(child);
+ return -EINVAL;
+ }
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
+ thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(child);
+ thread->dabr = dabr;
+ return 0;
+ }
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_len = len;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, NULL, child);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(child);
+ return PTR_ERR(bp);
+ }
+
+ ptrace_put_breakpoints(child);
+ return 1;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
+version_one:
+ if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ child->thread.dabr = dabr;
return 1;
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
}
static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
int rc;
@@ -1426,10 +1499,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
if (child->thread.dabr == 0)
return -ENOENT;
child->thread.dabr = 0;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
return 0;
#endif
@@ -1536,7 +1623,8 @@ long arch_ptrace(struct task_struct *child, long request,
case PPC_PTRACE_GETHWDBGINFO: {
struct ppc_debug_info dbginfo;
- dbginfo.version = 1;
+ /* We return the highest version number supported */
+ dbginfo.version = 2;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
dbginfo.num_instruction_bps = CONFIG_PPC_ADV_DEBUG_IACS;
dbginfo.num_data_bps = CONFIG_PPC_ADV_DEBUG_DACS;
@@ -1560,7 +1648,7 @@ long arch_ptrace(struct task_struct *child, long request,
dbginfo.data_bp_alignment = 4;
#endif
dbginfo.sizeof_condition = 0;
- dbginfo.features = 0;
+ dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
if (!access_ok(VERIFY_WRITE, datavp,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] Changes to PowerPC ptrace flags using watchpoints
From: K.Prasad @ 2011-08-19 7:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
Hi All,
Please find a set of two patches that introduce generic
hw-breakpoint interfaces for a couple of ptrace flags used by server-class
processors and another change to advertise a feature to user-space hitherto
available and used, but not claimed as supported.
GDB, which recently began using the
PPC_PTRACE_GETHWDBGINFO/PPC_PTRACE_SETHWDEBUG/PPC_PTRACE_DELHWDEBUG
flags on BookS processors is presently unable to set watchpoints. The
changes in Patch1, will fix that issue and help it use a common set of code
across BookE and BookS.
K.Prasad (2):
[hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC
ptrace flags
[PowerPC Book3E] Introduce new ptrace debug feature flag
Documentation/powerpc/ptrace.txt | 16 ++++++
arch/powerpc/include/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace.c | 105
++++++++++++++++++++++++++++++++++---
3 files changed, 114 insertions(+), 8 deletions(-)
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-08-19 3:20 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4D452C.7050805@parrot.com>
=E4=BA=8E 2011=E5=B9=B408=E6=9C=8819=E6=97=A5 01:00, Matthieu CASTET =E5=86=
=99=E9=81=93:
> b35362@freescale.com a =C3=A9crit :
>> From: Liu Shuo<b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> to support the Nand flash chip whose page size is larger than 2K bytes=
,
>> we divide a page into multi-2K pages for MTD layer driver. In that cas=
e,
>> we force to set the page size to 2K bytes. We convert the page address=
of
>> MTD layer driver to a real page address in flash chips and a column in=
dex
>> in fsl_elbc driver. We can issue any column address by UA instruction =
of
>> elbc controller.
>>
> Why do you need to do that ?
>
> When mtd send you a 4k page, why can't you write it by 2*2k pages write=
?
1. It's easy to implement.
2. We don't need to move the data in buffer more times, because we
want to use the HW_ECC.
In flash chip per Page:
----------------------------------------------------------------
| first data | first oob | second data | second oob |
----------------------------------------------------------------
> Even better send the first 2K and then if your controller allow it send=
the
> remaining 2K without command/address phase.
The elbc controller don't allow that.
I have to send twice Program CMD for writing the whole 4KB data.
>
> Matthieu
>
^ permalink raw reply
* Question about mem parameter in the bootargs
From: Carlos Roberto Moratelli @ 2011-08-18 20:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Does someone knows what is the smallest step to increase the mem
parameter in the bootargs?
I am running linux in an embedded system where I have a very critical
memory constraint and I would like to have mem=3584k instead mem=3M or
mem=4M.
The Linux boot up sucessfull with mem=3M or mem=4M but the kernel
crashes with mem=3584k.
thank you
Moratelli
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-18 18:27 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <4E4D3CE0.7020602@freescale.com>
On 08/18/2011 11:25 AM, Scott Wood wrote:
> The NOP restrictions should be documented in the code itself, not just
> in the git changelog. Maybe print it to the console when this hack is
> used, along with the NOP value read from the ID. If it's less than 4
> for 4K or 8 for 8K, also print a message saying not to use jffs2 (does
> yaffs2 do similar things?). If it's less than 2 for 4K or 4 for 8K, the
> probe should fail.
We should also warn the user about the need to prepare the NAND chip by
copying the bad block markers to the OOB of the new layout.
-Scott
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-18 18:24 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, b35362@freescale.com,
dwmw2@infradead.org, linux-mtd@lists.infradead.org
In-Reply-To: <4E4D452C.7050805@parrot.com>
On 08/18/2011 12:00 PM, Matthieu CASTET wrote:
> b35362@freescale.com a =E9crit :
>> From: Liu Shuo <b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> to support the Nand flash chip whose page size is larger than 2K bytes=
,
>> we divide a page into multi-2K pages for MTD layer driver. In that cas=
e,
>> we force to set the page size to 2K bytes. We convert the page address=
of
>> MTD layer driver to a real page address in flash chips and a column in=
dex
>> in fsl_elbc driver. We can issue any column address by UA instruction =
of
>> elbc controller.
>>
> Why do you need to do that ?
>=20
> When mtd send you a 4k page, why can't you write it by 2*2k pages write=
?
That would be more complicated given the statefulness of the interface,
for no real benefit.
> Even better send the first 2K and then if your controller allow it send=
the
> remaining 2K without command/address phase.
IIRC Shuo tried this first and couldn't make it work.
-Scott
^ permalink raw reply
* [PATCH] powerpc/85xx: remove left-over printks in p1022_ds.c
From: Timur Tabi @ 2011-08-18 18:12 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Two debugging prinkts were accidentally included in the last patch to
arch/powerpc/platforms/85xx/p1022_ds.c.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index a13d3cc..9d5dd8c 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -147,13 +147,11 @@ static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
switch (port) {
case FSL_DIU_PORT_DVI:
- printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DVIEN);
break;
case FSL_DIU_PORT_LVDS:
- printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DFP port, disable the DVI and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DFPEN);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-18 17:00 UTC (permalink / raw)
To: b35362@freescale.com
Cc: linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <1313634783-8855-1-git-send-email-b35362@freescale.com>
b35362@freescale.com a écrit :
> From: Liu Shuo <b35362@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we divide a page into multi-2K pages for MTD layer driver. In that case,
> we force to set the page size to 2K bytes. We convert the page address of
> MTD layer driver to a real page address in flash chips and a column index
> in fsl_elbc driver. We can issue any column address by UA instruction of
> elbc controller.
>
Why do you need to do that ?
When mtd send you a 4k page, why can't you write it by 2*2k pages write ?
Even better send the first 2K and then if your controller allow it send the
remaining 2K without command/address phase.
Matthieu
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-18 16:25 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <1313634783-8855-1-git-send-email-b35362@freescale.com>
On 08/17/2011 09:33 PM, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we divide a page into multi-2K pages for MTD layer driver. In that case,
> we force to set the page size to 2K bytes. We convert the page address of
> MTD layer driver to a real page address in flash chips and a column index
> in fsl_elbc driver. We can issue any column address by UA instruction of
> elbc controller.
>
> NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
> the Same Page (NOP)', the flash chip which is supported by this workaround
> have to meet below conditions.
> 1. page size is not greater than 4KB
> 2. 1) if main area and spare area have independent NOPs:
> main area NOP : >=3
> spare area NOP : >=2?
How often are the NOPs split like this?
> 2) if main area and spare area have a common NOP:
> NOP : >=4
This depends on how the flash is used. If you treat it as a NOP1 flash
(e.g. run ubifs rather than jffs2), then you need NOP2 for a 4K chip and
NOP4 for an 8K chip. OTOH, if you would be making full use of NOP4 on a
real 2K chip, you'll need NOP8 for a 4K chip.
The NOP restrictions should be documented in the code itself, not just
in the git changelog. Maybe print it to the console when this hack is
used, along with the NOP value read from the ID. If it's less than 4
for 4K or 8 for 8K, also print a message saying not to use jffs2 (does
yaffs2 do similar things?). If it's less than 2 for 4K or 4 for 8K, the
probe should fail.
-Scott
^ permalink raw reply
* Re: build failure with gcc 4.6.0 "array subscript is above array bounds"
From: Andreas Schwab @ 2011-08-18 9:31 UTC (permalink / raw)
To: Ian Campbell; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1313656032.5010.247.camel@zakaz.uk.xensource.com>
Ian Campbell <Ian.Campbell@citrix.com> writes:
> I noticed this with a defconfig build:
> CC arch/powerpc/kernel/ptrace.o
> arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace':
> arch/powerpc/kernel/ptrace.c:1502:5: error: array subscript is above array bounds [-Werror=array-bounds]
> arch/powerpc/kernel/ptrace.c:1530:5: error: array subscript is above array bounds [-Werror=array-bounds]
>
> That corresponds to:
> tmp = ((unsigned long *)child->thread.fpr)
> [TS_FPRWIDTH * (index - PT_FPR0)];
>
> child->thread.fpr is "double fpr[32][TS_FPRWIDTH]".
>
> index has already been bounds checked so we know it is <= PT_FPSCR.
>
> I tried to fix but I don't really know enough about PPC to figure out
> the correct fix is. PT_FPSCR is "PT_FPR0 + 32" on ppc64, which seems
> consistent with the fpr definition.
Perhaps there should be a union that overlays fpr with an array of
longs.
> On ppc32 PT_FPSCR is "PT_FPR0 + 2*32 + 1", I tried replacing the 32 with
> "PT_FPSCR - PT_FPR0" (+ 1) but that got me into the BUILD_BUG_ONs at
> line 346 and 374. At this point I'm afraid gave up trying to fix things,
> I hope the report is useful anyway...
On ppc32 a single ptrace call can only read/write half of an fpr, so
each fpr occupies two slots.
Andreas.
--
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
^ permalink raw reply
* RE: build failure with gcc 4.6.0 "array subscript is above array bounds"
From: David Laight @ 2011-08-18 8:58 UTC (permalink / raw)
To: Ian Campbell, linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <1313656032.5010.247.camel@zakaz.uk.xensource.com>
=20
> Subject: build failure with gcc 4.6.0 "array subscript is=20
> above array bounds"
...
> That corresponds to:
> tmp =3D ((unsigned long *)child->thread.fpr)
> [TS_FPRWIDTH * (index - PT_FPR0)];
>=20
> child->thread.fpr is "double fpr[32][TS_FPRWIDTH]".
>=20
> index has already been bounds checked so we know it is <=3D PT_FPSCR.
That code looks gross....
I think it is trying to index a 2D array with a single index
and type-pun the lookup.
I'm not sure how the array size (for the subscript error)
is determined in the presence of the cast, but without
the cast the index would have to be less than 32.
I also suspect this is failing when gcc inlines the function
from a call where 'index' is a constant.
Possibly the code should read:
tmp =3D (unsigned long *)child->thread.fpr[index - PT_FPRO];
although index may have been scaled by 'sizeof double/sizeof long'.
David
^ permalink raw reply
* build failure with gcc 4.6.0 "array subscript is above array bounds"
From: Ian Campbell @ 2011-08-18 8:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
I noticed this with a defconfig build:
CC arch/powerpc/kernel/ptrace.o
arch/powerpc/kernel/ptrace.c: In function 'arch_ptrace':
arch/powerpc/kernel/ptrace.c:1502:5: error: array subscript is above array bounds [-Werror=array-bounds]
arch/powerpc/kernel/ptrace.c:1530:5: error: array subscript is above array bounds [-Werror=array-bounds]
That corresponds to:
tmp = ((unsigned long *)child->thread.fpr)
[TS_FPRWIDTH * (index - PT_FPR0)];
child->thread.fpr is "double fpr[32][TS_FPRWIDTH]".
index has already been bounds checked so we know it is <= PT_FPSCR.
I tried to fix but I don't really know enough about PPC to figure out
the correct fix is. PT_FPSCR is "PT_FPR0 + 32" on ppc64, which seems
consistent with the fpr definition.
On ppc32 PT_FPSCR is "PT_FPR0 + 2*32 + 1", I tried replacing the 32 with
"PT_FPSCR - PT_FPR0" (+ 1) but that got me into the BUILD_BUG_ONs at
line 346 and 374. At this point I'm afraid gave up trying to fix things,
I hope the report is useful anyway...
Ian.
^ permalink raw reply
* Re: [PATCH v13 0/6] flexcan: Add support for powerpc flexcan (freescale p1010)
From: David Miller @ 2011-08-18 3:36 UTC (permalink / raw)
To: holt; +Cc: netdev, B22300, socketcan-core, linuxppc-dev
In-Reply-To: <1313551944-28603-1-git-send-email-holt@sgi.com>
From: Robin Holt <holt@sgi.com>
Date: Tue, 16 Aug 2011 22:32:18 -0500
> The following set of patches have been reviewed by the above parties and
> all comments have been integrated. Although the patches stray from the
> drivers/net/can directory, the diversions are related to changes for
> the flexcan driver.
>
> The patch set is based upon your net-next-2.6 tree's commit 6c37e46.
>
> Could you please queue these up for the next appropriate push to Linus'
> tree?
Applied to net-next, thanks!
^ permalink raw reply
* [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: b35362 @ 2011-08-18 2:33 UTC (permalink / raw)
To: dwmw2; +Cc: Liu Shuo, linuxppc-dev, linux-mtd
From: Liu Shuo <b35362@freescale.com>
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we divide a page into multi-2K pages for MTD layer driver. In that case,
we force to set the page size to 2K bytes. We convert the page address of
MTD layer driver to a real page address in flash chips and a column index
in fsl_elbc driver. We can issue any column address by UA instruction of
elbc controller.
NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
the Same Page (NOP)', the flash chip which is supported by this workaround
have to meet below conditions.
1. page size is not greater than 4KB
2. 1) if main area and spare area have independent NOPs:
main area NOP : >=3
spare area NOP : >=2
2) if main area and spare area have a common NOP:
NOP : >=4
Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
drivers/mtd/nand/fsl_elbc_nand.c | 66 ++++++++++++++++++++++++++++++-------
1 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index a212116..884a9f1 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -76,6 +76,13 @@ struct fsl_elbc_fcm_ctrl {
unsigned int oob; /* Non zero if operating on OOB data */
unsigned int counter; /* counter for the initializations */
char *oob_poi; /* Place to write ECC after read back */
+
+ /*
+ * If writesize > 2048, these two members are used to calculate
+ * the real page address and real column address.
+ */
+ int subpage_shift;
+ int subpage_mask;
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -164,18 +171,27 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
int buf_num;
+ u32 real_ca = column;
- elbc_fcm_ctrl->page = page_addr;
+ if (priv->page_size && elbc_fcm_ctrl->subpage_shift) {
+ real_ca = (page_addr & elbc_fcm_ctrl->subpage_mask) * 2112;
+ page_addr >>= elbc_fcm_ctrl->subpage_shift;
+ }
- out_be32(&lbc->fbar,
- page_addr >> (chip->phys_erase_shift - chip->page_shift));
+ elbc_fcm_ctrl->page = page_addr;
if (priv->page_size) {
+ real_ca += (oob ? 2048 : 0);
+ elbc_fcm_ctrl->use_mdr = 1;
+ elbc_fcm_ctrl->mdr = real_ca;
+
+ out_be32(&lbc->fbar, page_addr >> 6);
out_be32(&lbc->fpar,
((page_addr << FPAR_LP_PI_SHIFT) & FPAR_LP_PI) |
(oob ? FPAR_LP_MS : 0) | column);
buf_num = (page_addr & 1) << 2;
} else {
+ out_be32(&lbc->fbar, page_addr >> 5);
out_be32(&lbc->fpar,
((page_addr << FPAR_SP_PI_SHIFT) & FPAR_SP_PI) |
(oob ? FPAR_SP_MS : 0) | column);
@@ -256,10 +272,11 @@ static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
if (priv->page_size) {
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
- (FIR_OP_CA << FIR_OP1_SHIFT) |
- (FIR_OP_PA << FIR_OP2_SHIFT) |
- (FIR_OP_CM1 << FIR_OP3_SHIFT) |
- (FIR_OP_RBW << FIR_OP4_SHIFT));
+ (FIR_OP_UA << FIR_OP1_SHIFT) |
+ (FIR_OP_UA << FIR_OP2_SHIFT) |
+ (FIR_OP_PA << FIR_OP3_SHIFT) |
+ (FIR_OP_CM1 << FIR_OP4_SHIFT) |
+ (FIR_OP_RBW << FIR_OP5_SHIFT));
out_be32(&lbc->fcr, (NAND_CMD_READ0 << FCR_CMD0_SHIFT) |
(NAND_CMD_READSTART << FCR_CMD1_SHIFT));
@@ -399,12 +416,13 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
if (priv->page_size) {
out_be32(&lbc->fir,
(FIR_OP_CM2 << FIR_OP0_SHIFT) |
- (FIR_OP_CA << FIR_OP1_SHIFT) |
- (FIR_OP_PA << FIR_OP2_SHIFT) |
- (FIR_OP_WB << FIR_OP3_SHIFT) |
- (FIR_OP_CM3 << FIR_OP4_SHIFT) |
- (FIR_OP_CW1 << FIR_OP5_SHIFT) |
- (FIR_OP_RS << FIR_OP6_SHIFT));
+ (FIR_OP_UA << FIR_OP1_SHIFT) |
+ (FIR_OP_UA << FIR_OP2_SHIFT) |
+ (FIR_OP_PA << FIR_OP3_SHIFT) |
+ (FIR_OP_WB << FIR_OP4_SHIFT) |
+ (FIR_OP_CM3 << FIR_OP5_SHIFT) |
+ (FIR_OP_CW1 << FIR_OP6_SHIFT) |
+ (FIR_OP_RS << FIR_OP7_SHIFT));
} else {
out_be32(&lbc->fir,
(FIR_OP_CM0 << FIR_OP0_SHIFT) |
@@ -453,6 +471,9 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
full_page = 1;
}
+ if (priv->page_size)
+ elbc_fcm_ctrl->use_mdr = 1;
+
fsl_elbc_run_command(mtd);
/* Read back the page in order to fill in the ECC for the
@@ -654,9 +675,28 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
struct nand_chip *chip = mtd->priv;
struct fsl_elbc_mtd *priv = chip->priv;
struct fsl_lbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
unsigned int al;
+ /*
+ * Hack for supporting the flash chip whose writesize is
+ * larger than 2K bytes.
+ */
+ if (mtd->writesize > 2048) {
+ elbc_fcm_ctrl->subpage_shift = ffs(mtd->writesize >> 11) - 1;
+ elbc_fcm_ctrl->subpage_mask =
+ (1 << elbc_fcm_ctrl->subpage_shift) - 1;
+ /*
+ * Rewrite mtd->writesize, mtd->oobsize, chip->page_shift
+ * and chip->pagemask.
+ */
+ mtd->writesize = 2048;
+ mtd->oobsize = 64;
+ chip->page_shift = ffs(mtd->writesize) - 1;
+ chip->pagemask = (chip->chipsize >> chip->page_shift) - 1;
+ }
+
/* calculate FMR Address Length field */
al = 0;
if (chip->pagemask & 0xffff0000)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command
From: Brian Norris @ 2011-08-18 1:20 UTC (permalink / raw)
To: dedekind1; +Cc: LiuShuo, linuxppc-dev, linuxppc-dev, linux-mtd, dwmw2
In-Reply-To: <1313566762.19563.3.camel@sauron>
On Wed, Aug 17, 2011 at 12:39 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> I think the OOB mode should not be a global MTD device state. Each
> ioctl invocation should just specify the mode.
I agree. This brings up some questions, though. See below.
> Brian's idea of having a completely new ioctl or a set of new ioctls for
> OOB which would copletely deprecate the old ones is a good idea. Let's
> wait for his patch.
I sent a patch series (RFC) to the MTD mailing list. You can see the
cover description, which describes my proposed changes and asks some
questions, at the following link, but for some reason the patches are
being held up by the mailing list software - for now, you'll only
receive them if you were CC'd directly:
http://lists.infradead.org/pipermail/linux-mtd/2011-August/037522.html
Follow that thread for more information.
> May be we should even start physically removing depricated ioctls by
> first adding a printk with a warning and then removing completely. But
> first mtdutils should be updated to not use them.
Yes, this sounds fine, although I'm not too familiar with the
MTD_OOB_AUTO stuff, so I'm not sure how well it will replace all the
uses of MEMGETOOBSEL. I don't actually see any users of ECCGETLAYOUT;
I think I've asked about this ioctl before, but I can't seem to find
any response...perhaps it can be killed with no work?
Brian
^ permalink raw reply
* RE: [PATCH] RapidIO: Add mport driver for Tsi721 bridge
From: Bounine, Alexandre @ 2011-08-17 20:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Kim, Chul, linuxppc-dev, linux-kernel
In-Reply-To: <20110816160120.50bda968.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Fri, 12 Aug 2011 15:45:34 -0400
> Alexandre Bounine <alexandre.bounine@idt.com> wrote:
>=20
> > Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge
device.
>=20
> What a huge driver.
It is not over yet. We have plans to add more stuff later.
=20
> >
> > ...
> > +config RAPIDIO_TSI721
> > + bool "IDT Tsi721 PCI Express SRIO Controller support"
> > + depends on RAPIDIO && PCI && PCIEPORTBUS
>=20
> The dependency on PCI is redundant - PCIEPORTBUS already depends on
> PCI. Doesn't matter much though.
Agree. Will clean it for next release.=20
=20
> > + default "n"
> > + ---help---
> > + Include support for IDT Tsi721 PCI Express Serial RapidIO
> controller.
> >
> > ...
> >
> > + /* Wait until DMA transfer is finished */
> > + while ((ch_stat =3D ioread32(priv->regs +
> > + TSI721_DMAC_STS(TSI721_DMACH_MAINT))) &
TSI721_DMAC_STS_RUN) {
> > + udelay(10);
> > + i++;
> > + if (i >=3D 5000000) {
> > + dev_dbg(&priv->pdev->dev,
> > + "%s : DMA[%d] read timeout
ch_status=3D%x\n",
> > + __func__, TSI721_DMACH_MAINT, ch_stat);
> > + if (!do_wr)
> > + *data =3D 0xffffffff;
> > + err =3D -EFAULT;
> > + goto err_out;
> > + }
> > + }
>=20
> Fifty seconds!?!?
Should be "udelay(1)" - 10 usec is too much here.
=20
> EFAULT seems an inappropriate errno.
Switching to EIO.
=20
> > + if (ch_stat & TSI721_DMAC_STS_ABORT) {
> > + /* If DMA operation aborted due to error,
> > + * reinitialize DMA channel
> > + */
.....
> > + iowrite32(0, priv->regs +
> > + TSI721_DMAC_DWRCNT(TSI721_DMACH_MAINT));
> > + udelay(1);
> > + if (!do_wr)
> > + *data =3D 0xffffffff;
> > + err =3D -EFAULT;
Here EIO as well because ABORT error reports more events than just bad
address.
> > ...
> >
> > +static int
> > +tsi721_pw_handler(struct rio_mport *mport)
> > +{
> > + struct tsi721_device *priv =3D mport->priv;
> > + u32 pw_stat;
> > + u32 pw_buf[TSI721_RIO_PW_MSG_SIZE/sizeof(u32)];
> > +
> > +
> > + pw_stat =3D ioread32(priv->regs + TSI721_RIO_PW_RX_STAT);
> > +
> > + if (pw_stat & TSI721_RIO_PW_RX_STAT_PW_VAL) {
> > + pw_buf[0] =3D ioread32(priv->regs +
TSI721_RIO_PW_RX_CAPT(0));
> > + pw_buf[1] =3D ioread32(priv->regs +
TSI721_RIO_PW_RX_CAPT(1));
> > + pw_buf[2] =3D ioread32(priv->regs +
TSI721_RIO_PW_RX_CAPT(2));
> > + pw_buf[3] =3D ioread32(priv->regs +
TSI721_RIO_PW_RX_CAPT(3));
> > +
> > + /* Queue PW message (if there is room in FIFO),
> > + * otherwise discard it.
> > + */
> > + spin_lock(&priv->pw_fifo_lock);
> > + if (kfifo_avail(&priv->pw_fifo) >=3D
TSI721_RIO_PW_MSG_SIZE)
> > + kfifo_in(&priv->pw_fifo, pw_buf,
> > + TSI721_RIO_PW_MSG_SIZE);
> > + else
> > + priv->pw_discard_count++;
> > + spin_unlock(&priv->pw_fifo_lock);
> > + }
> > +
> > + /* Clear pending PW interrupts */
> > + iowrite32(TSI721_RIO_PW_RX_STAT_PW_DISC |
TSI721_RIO_PW_RX_STAT_PW_VAL,
> > + priv->regs + TSI721_RIO_PW_RX_STAT);
> > +
> > + schedule_work(&priv->pw_work);
>=20
> I see scheduled work being done, but no flush_scheduled_work() or
> similar. This is often a bug, leading to code being executed after
> device shutdown or even after rmmod.
Possibly my oversight. I will check if/where flush is needed.
=20
> > + return 0;
> > +}
> > +
> > +static void tsi721_pw_dpc(struct work_struct *work)
> > +{
> > + struct tsi721_device *priv =3D container_of(work, struct
tsi721_device,
> > + pw_work);
> > + unsigned long flags;
> > + u32 msg_buffer[RIO_PW_MSG_SIZE/sizeof(u32)]; /* Use full size PW
message
> > + buffer for RIO
layer */
> > +
> > + /*
> > + * Process port-write messages
> > + */
> > + spin_lock_irqsave(&priv->pw_fifo_lock, flags);
> > + while (kfifo_out(&priv->pw_fifo, (unsigned char *)msg_buffer,
> > + TSI721_RIO_PW_MSG_SIZE)) {
> > + /* Process one message */
> > + spin_unlock_irqrestore(&priv->pw_fifo_lock, flags);
> > +#ifdef DEBUG_PW
> > + {
> > + u32 i;
> > + pr_debug("%s : Port-Write Message:", __func__);
> > + for (i =3D 0; i < RIO_PW_MSG_SIZE/sizeof(u32); ) {
> > + pr_debug("0x%02x: %08x %08x %08x %08x", i*4,
> > + msg_buffer[i], msg_buffer[i + 1],
> > + msg_buffer[i + 2], msg_buffer[i + 3]);
> > + i +=3D 4;
> > + }
> > + pr_debug("\n");
> > + }
> > +#endif
> > + /* Pass the port-write message to RIO core for
processing */
> > + rio_inb_pwrite_handler((union rio_pw_msg *)msg_buffer);
> > + spin_lock_irqsave(&priv->pw_fifo_lock, flags);
> > + }
> > + spin_unlock_irqrestore(&priv->pw_fifo_lock, flags);
> > +}
>=20
> The lock handling in this function is pretty ugly-looking. Is it
> correct?
Ugly for sure. I am trying to protect message FIFO and not to lock it
during=20
execution of rio_inb_pwrite_handler() because it may take relatively
long time.
Inbound port-write controller does not have any HW queue to store PW
messages
and my goal is to get them from device ASAP and to place into the FIFO.
I will redo this function to make locking to look better. =20
=20
> >
> > ...
> >
> > +static void tsi721_db_dpc(struct work_struct *work)
> > +{
> > + struct tsi721_device *priv =3D container_of(work, struct
tsi721_device,
> > + idb_work);
> > + struct rio_mport *mport;
> > + struct rio_dbell *dbell;
> > + int found =3D 0;
> > + u32 wr_ptr, rd_ptr;
> > + u64 *idb_entry;
> > + u32 regval;
> > + union {
> > + u64 msg;
> > + u8 bytes[8];
> > + } idb;
> > +
> > + /*
> > + * Process queued inbound doorbells
> > + */
> > + mport =3D priv->mport;
> > +
> > + wr_ptr =3D ioread32(priv->regs + TSI721_IDQ_WP(IDB_QUEUE));
> > + rd_ptr =3D ioread32(priv->regs + TSI721_IDQ_RP(IDB_QUEUE));
> > +
> > + while (wr_ptr !=3D rd_ptr) {
> > + idb_entry =3D (u64 *)(priv->idb_base +
> > + (TSI721_IDB_ENTRY_SIZE *
rd_ptr));
> > + rd_ptr++;
> > + idb.msg =3D *idb_entry;
>=20
> Is this code correct on both little-endian and big-endian hardware?
Yes. It works on both. Tested on x86 and powerpc.
=20
> > + *idb_entry =3D 0;
> > +
> > + /* Process one doorbell */
> > + list_for_each_entry(dbell, &mport->dbells, node) {
> > + if ((dbell->res->start <=3D DBELL_INF(idb.bytes))
&&
> > + (dbell->res->end >=3D DBELL_INF(idb.bytes))) {
> > ...
> >
> > +static void tsi721_interrupts_init(struct tsi721_device *priv)
> > +{
> > + u32 intr;
> > +
> > + /* Enable IDB interrupts */
> > + iowrite32(TSI721_SR_CHINT_ALL,
> > + priv->regs + TSI721_SR_CHINT(IDB_QUEUE));
> > + iowrite32(TSI721_SR_CHINT_IDBQRCV,
> > + priv->regs + TSI721_SR_CHINTE(IDB_QUEUE));
> > + iowrite32(TSI721_INT_SR2PC_CHAN(IDB_QUEUE),
> > + priv->regs + TSI721_DEV_CHAN_INTE);
> > +
> > + /* Enable SRIO MAC interrupts */
> > + iowrite32(TSI721_RIO_EM_DEV_INT_EN_INT,
> > + priv->regs + TSI721_RIO_EM_DEV_INT_EN);
> > +
> > + if (priv->flags & TSI721_USING_MSIX)
> > + intr =3D TSI721_DEV_INT_SRIO;
> > + else
> > + intr =3D TSI721_DEV_INT_SR2PC_CH | TSI721_DEV_INT_SRIO |
> > + TSI721_DEV_INT_SMSG_CH;
> > +
> > + iowrite32(intr, priv->regs + TSI721_DEV_INTE);
> > + (void)ioread32(priv->regs + TSI721_DEV_INTE);
>=20
> Why include all of these void casts, btw?
Old habit. Used to have compiler warnings in some situations.
Not applicable to this case though. Will clean-up.
> > +}
> > +
> > +/**
> > + * tsi721_request_msix - register interrupt service for MSI-X mode.
> > + * @mport: RapidIO master port structure
> > + *
> > + * Registers MSI-X interrupt service routines for interrupts that
are active
> > + * immediately after mport initialization. Messaging interrupt
service routines
> > + * should be registered during corresponding open requests.
> > + */
> > +static int tsi721_request_msix(struct rio_mport *mport)
> > +{
> > + struct tsi721_device *priv =3D mport->priv;
> > + int err =3D 0;
> > +
> > + err =3D request_irq(priv->msix[TSI721_VECT_IDB].vector,
> > + tsi721_sr2pc_ch_msix, 0,
> > + priv->msix[TSI721_VECT_IDB].irq_name, (void
*)mport);
> > + if (err)
> > + goto out;
> > +
> > + err =3D request_irq(priv->msix[TSI721_VECT_PWRX].vector,
> > + tsi721_srio_msix, 0,
> > + priv->msix[TSI721_VECT_PWRX].irq_name, (void
> *)mport);
>=20
> Did we leak the first IRQ here?
Yes we did. Will fix it here and in one more place.
>=20
> > +out:
> > + return err;
> > +}
> > +
> >
> > ...
> >
> > +static int tsi721_enable_msix(struct tsi721_device *priv)
> > +{
> > + struct msix_entry entries[TSI721_VECT_MAX];
> > + int err;
> > + int i;
> > +
> > + entries[TSI721_VECT_IDB].entry =3D
TSI721_MSIX_SR2PC_IDBQ_RCV(IDB_QUEUE);
> > + entries[TSI721_VECT_PWRX].entry =3D TSI721_MSIX_SRIO_MAC_INT;
> > +
> > + /*
> > + * Initialize MSI-X entries for Messaging Engine:
> > + * this driver supports four RIO mailboxes (inbound and
outbound)
> > + * NOTE: Inbound message MBOX 0...4 use IB channels 4...7.
Therefore
> > + * offset +4 is added to IB MBOX number.
> > + */
> > + for (i =3D 0; i < RIO_MAX_MBOX; i++) {
> > + entries[TSI721_VECT_IMB0_RCV + i].entry =3D
> > + TSI721_MSIX_IMSG_DQ_RCV(i + 4);
> > + entries[TSI721_VECT_IMB0_INT + i].entry =3D
> > + TSI721_MSIX_IMSG_INT(i + 4);
> > + entries[TSI721_VECT_OMB0_DONE + i].entry =3D
> > + TSI721_MSIX_OMSG_DONE(i);
> > + entries[TSI721_VECT_OMB0_INT + i].entry =3D
> > + TSI721_MSIX_OMSG_INT(i);
> > + }
> > +
> > + err =3D pci_enable_msix(priv->pdev, entries, ARRAY_SIZE(entries));
> > + if (err) {
> > + if (err > 0)
> > + dev_info(&priv->pdev->dev,
> > + "Only %d MSI-X vectors available, "
> > + "not using MSI-X\n", err);
> > + return err;
> > + }
> > +
> > + /*
> > + * Copy MSI-X vector information into tsi721 private structure
> > + */
> > + priv->msix[TSI721_VECT_IDB].vector =3D
entries[TSI721_VECT_IDB].vector;
> > + snprintf(priv->msix[TSI721_VECT_IDB].irq_name,
IRQ_DEVICE_NAME_MAX,
> > + DRV_NAME "-idb@pci:%s", pci_name(priv->pdev));
> > + priv->msix[TSI721_VECT_PWRX].vector =3D
entries[TSI721_VECT_PWRX].vector;
> > + snprintf(priv->msix[TSI721_VECT_PWRX].irq_name,
IRQ_DEVICE_NAME_MAX,
> > + DRV_NAME "-pwrx@pci:%s", pci_name(priv->pdev));
> > +
> > + for (i =3D 0; i < RIO_MAX_MBOX; i++) {
> > + priv->msix[TSI721_VECT_IMB0_RCV + i].vector =3D
> > + entries[TSI721_VECT_IMB0_RCV +
i].vector;
> > + snprintf(priv->msix[TSI721_VECT_IMB0_RCV + i].irq_name,
> > + IRQ_DEVICE_NAME_MAX, DRV_NAME "-imbr%d@pci:%s",
> > + i, pci_name(priv->pdev));
> > +
> > + priv->msix[TSI721_VECT_IMB0_INT + i].vector =3D
> > + entries[TSI721_VECT_IMB0_INT +
i].vector;
> > + snprintf(priv->msix[TSI721_VECT_IMB0_INT + i].irq_name,
> > + IRQ_DEVICE_NAME_MAX, DRV_NAME "-imbi%d@pci:%s",
> > + i, pci_name(priv->pdev));
> > +
> > + priv->msix[TSI721_VECT_OMB0_DONE + i].vector =3D
> > + entries[TSI721_VECT_OMB0_DONE +
i].vector;
> > + snprintf(priv->msix[TSI721_VECT_OMB0_DONE + i].irq_name,
> > + IRQ_DEVICE_NAME_MAX, DRV_NAME "-ombd%d@pci:%s",
> > + i, pci_name(priv->pdev));
> > +
> > + priv->msix[TSI721_VECT_OMB0_INT + i].vector =3D
> > + entries[TSI721_VECT_OMB0_INT +
i].vector;
> > + snprintf(priv->msix[TSI721_VECT_OMB0_INT + i].irq_name,
> > + IRQ_DEVICE_NAME_MAX, DRV_NAME "-ombi%d@pci:%s",
> > + i, pci_name(priv->pdev));
> > + }
>=20
> Did we need a dependency on CONFIG_PCI_MSI?
To reduce a driver footprint yes, but it will not help if
system implements regular MSI only. This may be better handled by using
device specific config option depending on CONFIG_PCI_MSI. This way I
will be able
to remove MSI-X code while keeping MSI function. Marking as TODO.
If code size is not a concern, pci_enable_msix() has dependency on
CONFIG_PCI_MSI
and will fail if MSI support is not enabled.
>=20
> > + return 0;
> > +}
> > +
> >
> > ...
> >
> > +static int tsi721_bdma_ch_init(struct tsi721_device *priv, int
chnum)
> > +{
> > + struct tsi721_dma_desc *bd_ptr;
> > + u64 *sts_ptr;
> > + dma_addr_t bd_phys, sts_phys;
> > + int sts_size;
> > + int bd_num =3D priv->bdma[chnum].bd_num;
> > +
> > + dev_dbg(&priv->pdev->dev, "Init Block DMA Engine, CH%d\n",
chnum);
> > +
> > + /*
> > + * Initialize DMA channel for maintenance requests
> > + */
> > +
> > + /* Allocate space for DMA descriptors */
> > + bd_ptr =3D dma_alloc_coherent(&priv->pdev->dev,
> > + bd_num * sizeof(struct
tsi721_dma_desc),
> > + &bd_phys, GFP_KERNEL);
> > + if (!bd_ptr)
> > + return -ENOMEM;
> > +
> > + priv->bdma[chnum].bd_phys =3D bd_phys;
> > + priv->bdma[chnum].bd_base =3D bd_ptr;
> > +
> > + memset(bd_ptr, 0, bd_num * sizeof(struct tsi721_dma_desc));
>=20
> There it is again. Perhaps we need a dma_zalloc_coherent().
It will be nice match to kzalloc().
=20
> > + dev_dbg(&priv->pdev->dev, "DMA descriptors @ %p (phys =3D
%llx)\n",
> > + bd_ptr, (unsigned long long)bd_phys);
> > +
> > + /* Allocate space for descriptor status FIFO */
> > + sts_size =3D (bd_num >=3D TSI721_DMA_MINSTSSZ) ?
> > + bd_num : TSI721_DMA_MINSTSSZ;
> > + sts_size =3D roundup_pow_of_two(sts_size);
> > + sts_ptr =3D dma_alloc_coherent(&priv->pdev->dev,
> > + sts_size * sizeof(struct
tsi721_dma_sts),
> > + &sts_phys, GFP_KERNEL);
> > + if (!sts_ptr) {
> > + /* Free space allocated for DMA descriptors */
> > + dma_free_coherent(&priv->pdev->dev,
> > + bd_num * sizeof(struct
tsi721_dma_desc),
> > + bd_ptr, bd_phys);
> > + priv->bdma[chnum].bd_base =3D NULL;
> > + return -ENOMEM;
> > + }
> > +
> > + priv->bdma[chnum].sts_phys =3D sts_phys;
> > + priv->bdma[chnum].sts_base =3D sts_ptr;
> > + priv->bdma[chnum].sts_size =3D sts_size;
> > +
> > + memset(sts_ptr, 0, sts_size);
>=20
> and again.
This memset() may be safely removed. I will review all similar cases.
=20
> >
> > ...
> >
> > +struct tsi721_dma_desc {
> > + __le32 type_id;
> > +
...
> > +
> > + union {
> > + struct { /* if DTYPE =3D=3D 1 */
> > + __le32 bufptr_lo;
> > + __le32 bufptr_hi;
> > + __le32 s_dist;
> > + __le32 s_size;
> > + } t1;
> > + __le32 data[4]; /* if DTYPE =3D=3D 2 */
> > + u32 reserved[4]; /* if DTYPE =3D=3D 3 */
> > + };
> > +} __attribute__((aligned(32)));
>=20
> We have the __aligned helper for this. (more below)
No excuse to ignore it. Will update.
=20
> >
> > ...
> >
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Networkinterface on MPC5200b
From: Bjoern Slotkowski @ 2011-08-17 11:31 UTC (permalink / raw)
To: linuxppc-dev
Hello,
We have two problems when using the fec of the MPC5200b.
The occurence of both problems is very seldom.
1.
Sometimes the first two octets of the MAC-Adress are wrong.
Removing/inserting the driver does not help.
2.
Sometimes the communication stops.
When Removing the driver following message occurs:
net eth0: queues didn't drain
net eth0: tx: index: 9, outdex: 23
net eth0: rx: index: 81, outdex: 82
Is there any known issue about this ?
For the second point I was able to create a situation to reproduce the
behavior:
For this only a wrong checksum has to be appended to the ethernet-frame
transmitted to the fec.
When sending normal frames afterward nothing happens, the comunication is
dead.
It seems as if the part of the bestcom dma which handles the fec stops.
So we modified the driver code:
Normallly when a checksum error occurs, an error interrupt is generated for
the fec-driver and nothing will be done
beside error counting.
We modified the interrupt routine: The bestcom dma for the fec is setup
again.
This modification helps sometimes but not always.
Sometimes receiving frames does not work.
Sometimes sending frames does not work after the handling of the error.
So we tried to modify the microcode of the dma to find out what wents wrong.
But here we run into trouble:
Every modifiaction especially inserting a NOP at the end leads to a non
working dma
(We also modified the size in the setup-header).
Does anyone has experience with the microcode of the bestcom dma ?
We found some documentation of the dma and how it could be possible to do
something like a debugging
and we were roughly able to read what is happening in the mirocode.
But probably we do not understand all.
Thanks a million,
Björn Slotkowski
--
imc Messsysteme GmbH
Bereich Entwicklung / Dept. Development
Voltastraße 5
D-13355 Berlin
Germany
Tel: +49 30 46 70 90 23
Fax: +49 30 46 31 57 6
mailto:Bjoern.Slotkowski@imc-berlin.de
Homepage: http://www.imc-berlin.de
Sitz der Gesellschaft : Berlin
Handelsregister : Berlin-Charlottenburg HRB 28778
Geschäftsführer : Dr.-Ing. Dietmar Sprenger
^ permalink raw reply
* RE: [PATCH] rio: Use discovered bit to test if enumeration is complete
From: Liu Gang-B34182 @ 2011-08-17 9:45 UTC (permalink / raw)
To: 'Bounine, Alexandre',
'linux-kernel@vger.kernel.org'
Cc: 'linuxppc-dev@ozlabs.org',
'akpm@linux-foundation.org', Gala Kumar-B11780,
Li Yang-R58472, Zang Roy-R61911
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552020244E5@CORPEXCH1.na.ads.idt.com>
Hi, Andrew,
Could you please apply this patch into your tree?
Thanks a lot!
Regards,
Liu Gang
-----Original Message-----
From: Bounine, Alexandre [mailto:Alexandre.Bounine@idt.com]=20
Sent: Tuesday, August 09, 2011 8:36 PM
To: Liu Gang-B34182; linux-kernel@vger.kernel.org
Cc: Li Yang-R58472; Zang Roy-R61911; linuxppc-dev@ozlabs.org; Liu Gang-B341=
82; akpm@linux-foundation.org; Gala Kumar-B11780
Subject: RE: [PATCH] rio: Use discovered bit to test if enumeration is comp=
lete
On Monday, August 08, 2011 at 10:17 PM, Liu Gang wrote:
> Subject: [PATCH] rio: Use discovered bit to test if enumeration is=20
> complete
>=20
> The discovered bit in PGCCSR register indicates if the device has been=20
> discovered by system host. In Rapidio system, some agent devices can=20
> also be master devices. They can issue requests into the system.
>=20
> Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
> ---
> drivers/rapidio/rio-scan.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Alexandre Bounine <alexandre.bounine@idt.com>
^ permalink raw reply
* Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command
From: Artem Bityutskiy @ 2011-08-17 7:39 UTC (permalink / raw)
To: LiuShuo; +Cc: linuxppc-dev, dwmw2, linux-mtd, linuxppc-dev
In-Reply-To: <4E4B6F46.2050209@freescale.com>
On Wed, 2011-08-17 at 15:35 +0800, LiuShuo wrote:
> I think We can add a new ioctl MEMSETOOBMODE for selecting a mode to
> access the OOB area.
>
> Add new member into struct mtd_info:
>
> struct mtd_info {
> ......
>
> enum {
> MTD_OOB_PLACE,
> MTD_OOB_AUTO,
> MTD_OOB_RAW,
> } oob_mode;
> }
>
> In function mtd_do_writeoob() (in drivers/mtd/mtdchar.c) :
> - ops.mode = MTD_OOB_PLACE;
> + ops.mode = mtd->oob_mode;
>
>
>
> Could we do it like this ?
I think the OOB mode should not be a global MTD device state. Each
ioctl invocation should just specify the mode.
Brian's idea of having a completely new ioctl or a set of new ioctls for
OOB which would copletely deprecate the old ones is a good idea. Let's
wait for his patch.
May be we should even start physically removing depricated ioctls by
first adding a printk with a warning and then removing completely. But
first mtdutils should be updated to not use them.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command
From: LiuShuo @ 2011-08-17 7:35 UTC (permalink / raw)
To: dedekind1; +Cc: linuxppc-dev, dwmw2, linux-mtd, linuxppc-dev
In-Reply-To: <1313507201.2679.2.camel@sauron>
=E4=BA=8E 2011=E5=B9=B408=E6=9C=8816=E6=97=A5 23:06, Artem Bityutskiy =E5=
=86=99=E9=81=93:
> On Wed, 2011-08-03 at 13:50 +0800, b35362@freescale.com wrote:
>> From: Liu Shuo<b35362@freescale.com>
>>
>> Flash_erase -j should fill discrete freeoob areas with required bytes
>> of JFFS2 cleanmarker in jffs2_check_nand_cleanmarker(). Not just fill
>> the first freeoob area.
>>
>> Signed-off-by: Liu Shuo<b35362@freescale.com>
>> Signed-off-by: Li Yang<leoli@freescale.com>
> ...
>
>> /*
>> * Process user arguments
>> @@ -197,15 +198,40 @@ int main(int argc, char *argv[])
>> if (ioctl(fd, MEMGETOOBSEL,&oobinfo) !=3D 0)
>> return sys_errmsg("%s: unable to get NAND oobinfo", mtd_device);
>>
>> + cleanmarker.totlen =3D cpu_to_je32(8);
>> /* Check for autoplacement */
>> if (oobinfo.useecc =3D=3D MTD_NANDECC_AUTOPLACE) {
>> + struct nand_ecclayout_user ecclayout;
>> /* Get the position of the free bytes */
>> - if (!oobinfo.oobfree[0][1])
>> + if (ioctl(fd, ECCGETLAYOUT,&ecclayout) !=3D 0)
>> + return sys_errmsg("%s: unable to get NAND ecclayout", mtd_device=
);
>> +
> Hmm, shouldn't we instead make MTD_OOB_AUTO be available for userspace
> via an ioctl instead and make flash_eraseall use it instead?
>
I think We can add a new ioctl MEMSETOOBMODE for selecting a mode to=20
access the OOB area.
Add new member into struct mtd_info:
struct mtd_info {
......
enum {
MTD_OOB_PLACE,
MTD_OOB_AUTO,
MTD_OOB_RAW,
} oob_mode;
}
In function mtd_do_writeoob() (in drivers/mtd/mtdchar.c) :
- ops.mode =3D MTD_OOB_PLACE;
+ ops.mode =3D mtd->oob_mode;
Could we do it like this ?
Thanks
-LiuShuo
^ permalink raw reply
* [PATCH] powerpc/mm: fix the call trace when resumed from hibernation
From: b29983 @ 2011-08-17 5:51 UTC (permalink / raw)
To: benh; +Cc: Tang Yuantian, linuxppc-dev
From: Tang Yuantian <B29983@freescale.com>
In SMP mode, the kernel would produce call trace when resumed
from hibernation. The reason is when the function destroy_context
is called to drop the resuming mm context, the mm->context.active
is 1 which is wrong and should be zero.
We pass the current->active_mm as previous mm context to function
switch_mmu_context to decrease the context.active by 1.
In UP mode, there is no effect.
Signed-off-by: Tang Yuantian <b29983@freescale.com>
---
arch/powerpc/kernel/swsusp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
index 560c961..7cc81f0 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -34,6 +34,6 @@ void save_processor_state(void)
void restore_processor_state(void)
{
#ifdef CONFIG_PPC32
- switch_mmu_context(NULL, current->active_mm);
+ switch_mmu_context(current->active_mm, current->active_mm);
#endif
}
--
1.6.4
^ 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