* [PATCH] powerpc: remove unused do_signal export
From: Christoph Hellwig @ 2007-05-29 11:49 UTC (permalink / raw)
To: linuxppc-dev
do_signal is never used in modular code (obviously), and not other
architecture exports it either.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/ppc_ksyms.c 2007-05-29 12:34:22.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/ppc_ksyms.c 2007-05-29 12:34:30.000000000 +0200
@@ -67,7 +67,6 @@ EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
-EXPORT_SYMBOL(do_signal);
EXPORT_SYMBOL(transfer_to_handler);
EXPORT_SYMBOL(do_IRQ);
EXPORT_SYMBOL(machine_check_exception);
Index: linux-2.6/arch/powerpc/kernel/signal_64.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/signal_64.c 2007-05-29 12:34:46.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/signal_64.c 2007-05-29 12:34:54.000000000 +0200
@@ -568,4 +568,3 @@ int do_signal(sigset_t *oldset, struct p
return 0;
}
-EXPORT_SYMBOL(do_signal);
Index: linux-2.6/arch/ppc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.orig/arch/ppc/kernel/ppc_ksyms.c 2007-05-29 12:34:38.000000000 +0200
+++ linux-2.6/arch/ppc/kernel/ppc_ksyms.c 2007-05-29 12:34:41.000000000 +0200
@@ -65,7 +65,6 @@ extern unsigned long mm_ptov (unsigned l
EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(clear_user_page);
-EXPORT_SYMBOL(do_signal);
EXPORT_SYMBOL(transfer_to_handler);
EXPORT_SYMBOL(do_IRQ);
EXPORT_SYMBOL(machine_check_exception);
^ permalink raw reply
* Re: MPC8560 Gianfar driver hangs after soft reboot
From: Clemens Koller @ 2007-05-29 11:41 UTC (permalink / raw)
To: Bill Farrow; +Cc: linuxppc-embedded
In-Reply-To: <34E73CC1202BF246B7DE3463BEBC068998EE91@postie.optiscan.com>
Hello, Bill!
Bill Farrow schrieb:
> On 25 May 2007 Clemens Koller wrote:
>> Bill Farrow schrieb:
>>> The Gianfar driver is hanging during boot-up after a soft
>> reboot. It works fine when the board is power cycled.
>>> Any hints on where to look further on this issue?
>> I have had some rare issues with PHY initialization on the
>> PM854 with the u-boot-1.2.0 not being able to download something via
>> TFTP. There is an entry somewhere in the U-Boot wiki (I think) that
>> the TQM8540 board can have some issues...
>> well the boards are quite similar.
>> Pushing the reset button (Never needed to power that off) solves the
>> issue.
>
> We have found a work around for this problem: If the network interfaces
> are disabled before doing a soft reboot then everything works properly.
> We are using the ramdisk from the ELDK 4.1 and are no rc scripts for
> busybox to call to shutdown the network interfaces before rebooting. We
> will just add our own script to do this when rebooting.
Something like:
/sbin/ip route del default
/sbin/ip link set eth0 down
/sbin/ip addr del 192.168.1.200/24 dev eth0
(or something similar using the ifconfig <foo>)
Or how do you define to "shutdown the network interfaces"?
I guess I am lucky that I always had rc scripts running on my system.
(native distribution on harddisk, based on http://crux.nu )
> Agreed. I did look at some future kernel versions to see what changes
> had been made to the gianfar source code, but your right, we should try
> some out on the actual hardware.
Yup, there were lots of changes, also in the PHY/MII interface.
> We are using the Microsys carrier board with the PM856 module and has
> been quite stable.
Same over here. It's good stuff!
Best greets,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [RFC/PATCH 4/5] powerpc: Make syscall restart code more common
From: Benjamin Herrenschmidt @ 2007-05-29 11:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070529113232.GA6071@lst.de>
On Tue, 2007-05-29 at 13:32 +0200, Christoph Hellwig wrote:
> On Tue, May 29, 2007 at 04:45:23PM +1000, Benjamin Herrenschmidt
> wrote:
> > +static inline void check_syscall_restart(struct pt_regs *regs,
> > + struct k_sigaction *ka,
> > + int has_handler)
> > +{
>
> I don't think this should be inlined. Just create a new signal.c
> file,
> which can grow a lot more common signal code later on aswell.
I've been thinking about doing that too. In fact, some of the
ptrace-common.h stuff should probably be turned back into ptrace.c too
for the same reason. I'm still toying with that part of the designm but
yeah, I think that's something to do.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH 4/5] powerpc: Make syscall restart code more common
From: Christoph Hellwig @ 2007-05-29 11:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, ulrich.weigand
In-Reply-To: <20070529064533.CA8C4DDFF8@ozlabs.org>
On Tue, May 29, 2007 at 04:45:23PM +1000, Benjamin Herrenschmidt wrote:
> +static inline void check_syscall_restart(struct pt_regs *regs,
> + struct k_sigaction *ka,
> + int has_handler)
> +{
I don't think this should be inlined. Just create a new signal.c file,
which can grow a lot more common signal code later on aswell.
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Benjamin Herrenschmidt @ 2007-05-29 11:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, Christoph Hellwig, linux-scsi, linux-kernel
In-Reply-To: <Pine.LNX.4.62.0705291308280.7698@pademelon.sonytel.be>
On Tue, 2007-05-29 at 13:11 +0200, Geert Uytterhoeven wrote:
> > This looks very inefficient. Just set sg_tablesize of your driver
> > to 1 to avoid getting mutiple segments.
>
> The disadvantage of setting sg_tablesize = 1 is that the driver will
> get small
> requests (PAGE_SIZE) most of the time, which is very bad for
> performance.
And the joke is that not only the HW can do scatter & gather but you
also have an iommu ...
Ben.
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Geert Uytterhoeven @ 2007-05-29 11:11 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20070529104948.GC29351@lst.de>
On Tue, 29 May 2007, Christoph Hellwig wrote:
> [Note that all scsi lldds should go to linux-scsi]
I'll Cc linux-scsi next time.
> > + sgpnt = cmd->request_buffer;
> > + active = 1;
> > + for (k = 0, req_len = 0, act_len = 0; k < cmd->use_sg; ++k, ++sgpnt) {
> > + if (active) {
> > + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> > + if (!kaddr)
> > + return DID_ERROR << 16;
> > + len = sgpnt->length;
> > + if ((req_len + len) > buflen) {
> > + active = 0;
> > + len = buflen - req_len;
> > + }
> > + memcpy(kaddr + sgpnt->offset, buf + req_len, len);
> > + kunmap_atomic(kaddr, KM_USER0);
> > + act_len += len;
> > + }
> > + req_len += sgpnt->length;
> > + }
> > + cmd->resid = req_len - act_len;
>
> This looks very inefficient. Just set sg_tablesize of your driver
> to 1 to avoid getting mutiple segments.
The disadvantage of setting sg_tablesize = 1 is that the driver will get small
requests (PAGE_SIZE) most of the time, which is very bad for performance.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [linux-usb-devel] USB Host at full speed
From: Oliver Neukum @ 2007-05-29 11:07 UTC (permalink / raw)
To: linux-usb-devel; +Cc: axelnico, Linuxppc-embedded
In-Reply-To: <989B956029373F45A0B8AF0297081890D2A07A@zch01exm26.fsl.freescale.net>
Am Dienstag, 29. Mai 2007 13:01 schrieb Li Yang-r58472:
> Your question can be interpreted as how to force EHCI host driver to
> work in full speed. =A0Usb-devel list cc'ed should be a better place for
> such a question.
It can't, which is the reason you pair EHCI with OHCI/UHCI.
Regards
Oliver
^ permalink raw reply
* Re: [Patch ] Kexec/Kdump support - POWER6
From: Stephen Rothwell @ 2007-05-29 11:06 UTC (permalink / raw)
To: michael; +Cc: Milton Miller II, kexec, linuxppc-dev, Mackerras, Paul
In-Reply-To: <1180433684.5953.1.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
On Tue, 29 May 2007 20:14:44 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Add this to your ~/.vimrc, you do use vim right :)
>
> highlight RedundantWhitespace ctermbg=red guibg=red
You need this as well:
match RedundantWhitespace /\s\+$\| \+\ze\t/
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: USB Host at full speed
From: Li Yang-r58472 @ 2007-05-29 11:01 UTC (permalink / raw)
To: axelnico, Linuxppc-embedded; +Cc: linux-usb-devel
In-Reply-To: <662798.70353.qm@web26515.mail.ukl.yahoo.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> axelnico@yahoo.fr
> Sent: Tuesday, May 29, 2007 5:11 PM
> To: Linuxppc-embedded@ozlabs.org
> Subject: USB Host at full speed
>=20
> Hello ALL,
>=20
> I m currently trying to force the USB host controller from MPC8349 to
only work
> at full speed i.e. whatever is the connected device, the bandwidth
should be 12MB.
> I thought i could perform it just by setting some registers to right
value but it
> aren't working.
> I fear i have to force software to always use TT and split transfer
but i dont
> know exactly where to start..
>=20
> If anybody could help, would be so great!!
Your question can be interpreted as how to force EHCI host driver to
work in full speed. Usb-devel list cc'ed should be a better place for
such a question.
- Leo
^ permalink raw reply
* Re: [patch 7/7] ps3: FLASH ROM Storage Driver
From: Christoph Hellwig @ 2007-05-29 10:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Christoph Hellwig, linux-kernel
In-Reply-To: <Pine.LNX.4.62.0705291157260.7698@pademelon.sonytel.be>
On Tue, May 29, 2007 at 11:57:52AM +0200, Geert Uytterhoeven wrote:
> On Tue, 29 May 2007, Christoph Hellwig wrote:
> > On Fri, May 25, 2007 at 10:36:14AM +0200, Geert.Uytterhoeven@sonycom.com wrote:
> > > Add a FLASH ROM Storage Driver for the PS3:
> > > - Implemented as a misc character device driver
> > > - Uses a fixed 256 KiB buffer allocated from boot memory as the hypervisor
> > > requires the writing of aligned 256 KiB blocks
> >
> > Looks good, but please either make the driver aware of multiple devices
> > even if they can't happen currently, or alternatively error out in
> > ->probe if of some reason it's called for a second device.
>
> ps3flash_probe() does return -EBUSY when called for a second device.
You're right, I missed that bit.
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Christoph Hellwig @ 2007-05-29 10:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel
In-Reply-To: <200705252304.30396.arnd@arndb.de>
On Fri, May 25, 2007 at 11:04:29PM +0200, Arnd Bergmann wrote:
> On Friday 25 May 2007, Geert Uytterhoeven wrote:
> >
> > > What is the problem? Is there infrastructure missing in the
> > > CD-ROM layer?
> >
> > As the CD/DVD/BD part just accepts SCSI/ATAPI commands (except for plain
> > read/write), I was suggested to keep it as a SCSI driver.
>
> Ok, so I guess the tradeoff here is that by writing it as a SCSI
> driver, you don't need to implement any of the cdrom_device_ops
> yourself but instead need to fake a few of the SCSI commands
> in ps3rom_request(). Fair enough.
ps3rom is just a normal scsi low level driver. Currently the only
attached devices or MMC devices so the sr driver attaches to it,
but if you want to hack the ps3 hardware you should be able to
attach a tape or disk aswell, and linux would work (lv1 and gameos
might of course not like this)
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Christoph Hellwig @ 2007-05-29 10:49 UTC (permalink / raw)
To: Geert.Uytterhoeven; +Cc: linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20070525083632.677742000@sonycom.com>
[Note that all scsi lldds should go to linux-scsi]
> +config PS3_ROM
> + tristate "PS3 ROM Storage Driver"
> + depends on PPC_PS3 && BLK_DEV_SR
> + select PS3_STORAGE
> + default y
please don't put any default y statements in.
> +#define DEVICE_NAME "ps3rom"
> +
> +#define BOUNCE_SIZE (64*1024)
> +
> +#define PS3ROM_MAX_SECTORS (BOUNCE_SIZE / CD_FRAMESIZE)
> +
> +#define LV1_STORAGE_SEND_ATAPI_COMMAND (1)
> +
> +
> +struct ps3rom_private {
> + spinlock_t lock;
> + struct task_struct *thread;
> + struct Scsi_Host *host;
> + struct scsi_cmnd *cmd;
> + void (*scsi_done)(struct scsi_cmnd *);
> +};
> +#define ps3rom_priv(dev) ((dev)->sbd.core.driver_data)
> +/*
> + * to position parameter
> + */
> +enum {
> + NOT_AVAIL = -1,
> + USE_SRB_10 = -2,
> + USE_SRB_6 = -3,
> + USE_CDDA_FRAME_RAW = -4
> +};
none of these seem to be used at all in the driver.
> +
> +#ifdef DEBUG
> +static const char *scsi_command(unsigned char cmd)
> +{
> + switch (cmd) {
> + case TEST_UNIT_READY: return "TEST_UNIT_READY/GPCMD_TEST_UNIT_READY";
> + case REZERO_UNIT: return "REZERO_UNIT";
> + case REQUEST_SENSE: return "REQUEST_SENSE/GPCMD_REQUEST_SENSE";
...
this kind of things shouldn't be in a low level driver. Either keep it
in your out of tree debug patches or if you feel adventurous send a
patch to linux-scsi that implements it in drivers/scsi/constant.c which
has debug code for other protocol-level scsi constants.
> +static int ps3rom_slave_alloc(struct scsi_device *scsi_dev)
> +{
> + struct ps3_storage_device *dev;
> +
> + dev = (struct ps3_storage_device *)scsi_dev->host->hostdata[0];
> +
> + dev_dbg(&dev->sbd.core, "%s:%u: id %u, lun %u, channel %u\n", __func__,
> + __LINE__, scsi_dev->id, scsi_dev->lun, scsi_dev->channel);
> +
> + scsi_dev->hostdata = dev;
This seems rather pointless. The scsi_device has a pointer to the
host, so every access to scsi_dev->hostdata can simply be replaced
by an access through the host.
> +static int ps3rom_slave_configure(struct scsi_device *scsi_dev)
> +{
> + struct ps3_storage_device *dev = scsi_dev->hostdata;
> +
> + dev_dbg(&dev->sbd.core, "%s:%u: id %u, lun %u, channel %u\n", __func__,
> + __LINE__, scsi_dev->id, scsi_dev->lun, scsi_dev->channel);
> +
> + /*
> + * ATAPI SFF8020 devices use MODE_SENSE_10,
> + * so we can prohibit MODE_SENSE_6
> + */
> + scsi_dev->use_10_for_ms = 1;
> +
> + return 0;
> +}
> +
> +static void ps3rom_slave_destroy(struct scsi_device *scsi_dev)
> +{
> +}
No need to implement an empty method here.
> +static int ps3rom_queuecommand(struct scsi_cmnd *cmd,
> + void (*done)(struct scsi_cmnd *))
> +{
> + struct ps3_storage_device *dev = cmd->device->hostdata;
> + struct ps3rom_private *priv = ps3rom_priv(dev);
> +
> + dev_dbg(&dev->sbd.core, "%s:%u: command 0x%02x (%s)\n", __func__,
> + __LINE__, cmd->cmnd[0], scsi_command(cmd->cmnd[0]));
> +
> + spin_lock_irq(&priv->lock);
> + if (priv->cmd) {
> + /* no more than one can be processed */
> + dev_err(&dev->sbd.core, "%s:%u: more than 1 command queued\n",
> + __func__, __LINE__);
> + spin_unlock_irq(&priv->lock);
> + return SCSI_MLQUEUE_HOST_BUSY;
> + }
Just set can_queue to 1 in the host template and the midlayer will take
care of this.
> +
> + // FIXME Prevalidate commands?
> + priv->cmd = cmd;
> + priv->scsi_done = done;
No need to keep your own scsi_done pointer. What you should do instead
in queuecommand is to set the scsi_done pointer in the scsi_cmnd here
and just use it later.
> + spin_unlock_irq(&priv->lock);
> + wake_up_process(priv->thread);
Offloading every I/O to a thread is very bad for I/O performance.
Why do you need this?
> + return 0;
> +}
> +
> +/*
> + * copy data from device into scatter/gather buffer
> + */
> +static int fill_from_dev_buffer(struct scsi_cmnd *cmd, const void *buf,
> + int buflen)
> +{
> + int k, req_len, act_len, len, active;
> + void *kaddr;
> + struct scatterlist *sgpnt;
> +
> + if (!cmd->request_bufflen)
> + return 0;
> +
> + if (!cmd->request_buffer)
> + return DID_ERROR << 16;
> +
> + if (cmd->sc_data_direction != DMA_BIDIRECTIONAL &&
> + cmd->sc_data_direction != DMA_FROM_DEVICE)
> + return DID_ERROR << 16;
> +
> + if (!cmd->use_sg) {
> + req_len = cmd->request_bufflen;
> + act_len = min(req_len, buflen);
> + memcpy(cmd->request_buffer, buf, act_len);
> + cmd->resid = req_len - act_len;
> + return 0;
> + }
This is never true anymore.
> +
> + sgpnt = cmd->request_buffer;
> + active = 1;
> + for (k = 0, req_len = 0, act_len = 0; k < cmd->use_sg; ++k, ++sgpnt) {
> + if (active) {
> + kaddr = kmap_atomic(sgpnt->page, KM_USER0);
> + if (!kaddr)
> + return DID_ERROR << 16;
> + len = sgpnt->length;
> + if ((req_len + len) > buflen) {
> + active = 0;
> + len = buflen - req_len;
> + }
> + memcpy(kaddr + sgpnt->offset, buf + req_len, len);
> + kunmap_atomic(kaddr, KM_USER0);
> + act_len += len;
> + }
> + req_len += sgpnt->length;
> + }
> + cmd->resid = req_len - act_len;
This looks very inefficient. Just set sg_tablesize of your driver
to 1 to avoid getting mutiple segments.
> +static void ps3rom_request(struct ps3_storage_device *dev,
> + struct scsi_cmnd *cmd)
> +{
> + unsigned char opcode = cmd->cmnd[0];
> + struct ps3rom_private *priv = ps3rom_priv(dev);
> +
> + dev_dbg(&dev->sbd.core, "%s:%u: command 0x%02x (%s)\n", __func__,
> + __LINE__, opcode, scsi_command(opcode));
> +
> + switch (opcode) {
> + case INQUIRY:
> + ps3rom_atapi_request(dev, cmd, srb6_len(cmd),
> + PIO_DATA_IN_PROTO, DIR_READ, 1);
> + break;
> +
> + case REQUEST_SENSE:
> + ps3rom_atapi_request(dev, cmd, srb6_len(cmd),
> + PIO_DATA_IN_PROTO, DIR_READ, 0);
> + break;
> +
> + case ALLOW_MEDIUM_REMOVAL:
> + case START_STOP:
> + case TEST_UNIT_READY:
> + ps3rom_atapi_request(dev, cmd, 0, NON_DATA_PROTO, DIR_NA, 1);
> + break;
This switch statement looks very wrong. The data direction and length
can easily be derived from the scsi_cmnd structure.
> + default:
> + dev_err(&dev->sbd.core, "%s:%u: illegal request 0x%02x (%s)\n",
> + __func__, __LINE__, opcode, scsi_command(opcode));
> + cmd->result = DID_ERROR << 16;
> + memset(cmd->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
> + cmd->sense_buffer[0] = 0x70;
> + cmd->sense_buffer[2] = ILLEGAL_REQUEST;
Normally you should just hand down any command to the device, that's
the whole point of the modular scsi protocol stack.
> + struct ps3_storage_device *dev = to_ps3_storage_device(&_dev->core);
> + struct ps3rom_private *priv;
> + int error;
> + struct Scsi_Host *host;
> + struct task_struct *task;
> +
> + if (dev->blk_size != CD_FRAMESIZE) {
> + dev_err(&dev->sbd.core,
> + "%s:%u: cannot handle block size %lu\n", __func__,
> + __LINE__, dev->blk_size);
> + return -EINVAL;
> + }
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
Normally you should allocate the private data using scsi_host_alloc,
that's why it has a priv_size argument.
> +static int ps3rom_remove(struct ps3_system_bus_device *_dev)
> +{
> + struct ps3_storage_device *dev = to_ps3_storage_device(&_dev->core);
> + struct ps3rom_private *priv = ps3rom_priv(dev);
> +
> + scsi_remove_host(priv->host);
> + scsi_host_put(priv->host);
> + kthread_stop(priv->thread);
> + ps3stor_teardown(dev);
> + kfree(dev->bounce_buf);
> + kfree(priv);
the scsi_host_put should come last.
^ permalink raw reply
* [PATCH] powerpc: fix virt_to_page() with NULL
From: Akinobu Mita @ 2007-05-29 10:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
pte_alloc_one() is expected to return NULL if out of memory.
But it returns virt_to_page(NULL) and it is not NULL.
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Akinobu Mita <mita@fixstars.com>
---
include/asm-powerpc/pgalloc-64.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: 2.6-rc-ps3/include/asm-powerpc/pgalloc-64.h
===================================================================
--- 2.6-rc-ps3.orig/include/asm-powerpc/pgalloc-64.h
+++ 2.6-rc-ps3/include/asm-powerpc/pgalloc-64.h
@@ -90,7 +90,8 @@ static inline pte_t *pte_alloc_one_kerne
static inline struct page *pte_alloc_one(struct mm_struct *mm,
unsigned long address)
{
- return virt_to_page(pte_alloc_one_kernel(mm, address));
+ pte_t *pte = pte_alloc_one_kernel(mm, address);
+ return pte ? virt_to_page(pte) : NULL;
}
static inline void pte_free_kernel(pte_t *pte)
^ permalink raw reply
* Re: [Patch ] Kexec/Kdump support - POWER6
From: Michael Ellerman @ 2007-05-29 10:14 UTC (permalink / raw)
To: sachinp; +Cc: Milton Miller II, Paul Mackerras, kexec, linuxppc-dev
In-Reply-To: <465ABFC9.9020502@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]
On Mon, 2007-05-28 at 17:10 +0530, Sachin P. Sant wrote:
> Benjamin Herrenschmidt wrote:
> > If you're going to use the B (1T segment) bit instead of the bolted bit,
> > at least define a proper constant in line with the existing naming of
> > the hash table constants in mmu-hash64.h. I would suggest doing the same
> > with the VRMA_MASK/VALUE thing and calling it HPTE_V_VRMA_MASK or
> > something similar.
> >
> Well i had used them properly in my previous patches. Don't know why
> i changed it in this patch :-(
>
> Here is the updated patch.
>
> >> + }
> >> }
> >>
> > In addition, I would recommend following Michael's advice and using
> > using the bulk remove Hcall whenever possible.
> >
> Yes will send out a separate patch to use bulk remove Hcall.
>
> Thanks
> -Sachin
>
>
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
> ---
>
>
>
>
> plain text document attachment (kexec-kdump-support-on-POWER6)
> * On Power machines supporting VRMA, Kexec/Kdump does not work.
> * Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
> * Make sure these hpte entries are left untouched.
> *
> * This patch also adds plpar_pte_read_raw() on the lines of
> * plpar_pte_remove_raw().
>
> Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
> ---
>
> diff -Naurp a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> --- a/arch/powerpc/platforms/pseries/lpar.c 2007-05-19 09:36:17.000000000 +0530
> +++ b/arch/powerpc/platforms/pseries/lpar.c 2007-05-28 16:49:46.000000000 +0530
> @@ -369,16 +369,30 @@ static long pSeries_lpar_hpte_remove(uns
> return -1;
> }
>
> +#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000)
> +#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff)
> +
> static void pSeries_lpar_hptab_clear(void)
> {
> unsigned long size_bytes = 1UL << ppc64_pft_size;
> unsigned long hpte_count = size_bytes >> 4;
> - unsigned long dummy1, dummy2;
> + unsigned long dummy1, dummy2, dword0;
> + long lpar_rc;
> int i;
>
> /* TODO: Use bulk call */
> - for (i = 0; i < hpte_count; i++)
> - plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
> + for (i = 0; i < hpte_count; i++) {
> + /* dont remove HPTEs with VRMA mappings */
> + lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
> + &dummy1, &dummy2);
> + if (lpar_rc == H_NOT_FOUND) {
> + lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
> + if (!lpar_rc && (((dword0 >> 24) & HPTE_V_VRMA_MASK) <xxxxxxx
You have trailing whitespace on that line.
Add this to your ~/.vimrc, you do use vim right :)
highlight RedundantWhitespace ctermbg=red guibg=red
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: BDI2000 configuration file for MPC8313E-RDB
From: Frank Prepelica @ 2007-05-29 10:08 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
Hi Leonid,
the PowerTAB pro JTAG Debugger cannot access NAND directly like the =
BDI2000.
I thought it could, but as you said there's no way to program NAND =
directly.
The configuration file I posted was the unmodified one that I got from =
the http://www.ultsol.com/ webpage. Therefore you find at section [FILE] =
PCB82xx120.ep. (I change the IP and the file to u-boot.bin)
I still got the problem that I don't know how to get access to NAND to
store the 4KB bootloader and to boot completely from NAND.=20
I tried via u-boot by booting from NOR.
=3D> nand info
Device 0: NAND 32MiB 3,3V 8-bit, sector size 16 KiB
=3D> nand erase=20
NAND erase: device 0 whole chip
Erasing at 0x1ffc000 -- 100% complete.
OK
=3D>
That seems each command works. (show info and erase NAND)
But when I'm trying to write for example u-boot.bin to NAND
I'll get this:
=3D> nand write.e 3000000 f8000000 29790
NAND write: device 0 offset 0xf8000000, size 0x29790
Data did not fit into device, due to bad blocks
169872 bytes written: ERROR
=3D>
Furthermore, when I trying to display NAND memory
I'll get this:
=3D> md 0xf8000000
f8000000:Bus Fault @ 0x00000900, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 07f38cc0 Unknown values in msr
NIP: 00000900 XER: 20000000 LR: 07FD4430 REGS: 07f38cc0 TRAP: 0200 DAR: =
FFFFFFFF
MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 07FD4430 07F38DB0 00000080 00000000 B09F0000 00000010 00000001 =
00000008=20
GPR08: 00000001 00000020 00000000 00000000 07F38B78 00000000 07FFC000 =
09FBB000=20
GPR16: 00000000 00000000 00000000 00000000 07F38DB8 00000040 07F38DB8 =
07F38DB8=20
GPR24: 00000000 00000100 00000010 00000004 F8000000 07F38F5C 07FFCDA8 =
07F38DB8=20
Call backtrace:=20
07FD4430 07FDD8D8 07FDCFD0 07FDD12C 07FCCDAC 07FBFAC8 07FBE66C=20
7EB143A6=20
machine check
Resetting the board.
Why? Is the NAND memory not correctly mapped to 0xf8000000? Where
can I change the mapping?
I'm aware of that these are very basic questions, but it doesn't becomes
clear by reading the board specific manuals.=20
Best regards
Frank.
-----Urspr=FCngliche Nachricht-----
Von: Leonid [mailto:Leonid@a-k-a.net]=20
Gesendet: Montag, 21. Mai 2007 17:28
An: Frank Prepelica
Cc: linuxppc-embedded@ozlabs.org
Betreff: RE: BDI2000 configuration file for MPC8313E-RDB
On Monday, May 21, 2007 12:25 AM Frank Prepelica wrote:
> Sorry, but the BDI does not support programming any NAND flash.
> You can write your own driver. Then load the data and the driver into=20
> SDRAM via the BDI and execute it.
> Well, I think I have to try this, if there's really no other way.=20
> I'm not quite sure, maybe you know the PowerTAB Pro JTAG Debugger,
> (it's recommended in the manuals) could this one get directly access
> to NAND memory?
No, I don't but I would like to learn more about NAND flash programmers.
> Uhm, it's possible that achieved that in an "indirect" way that I was
> not aware of. But as I said, the complete flash and ram was empty,
just
> loaded=20
> the corresponding BDI config file to BDI2000 JTAG and I got access to
> flash memory where I placed the bootloader image. Hmm, anyway ;)
> The BDI config: http://www.ultsol.com/config/Emb%20Planet/83xx.cfg
It's still not clear from your description what has been done - "I got
access to flash memory" sounds too vague. It's quite possible that SW
you are using does the trick; at least you have some file, loaded from
the host to RAM:
[HOST]
IP 10.0.0.198
FILE PCB82xx120.ep
Where did you get this PCB82xx120.ep file from?
In any rate, FLASH section of this configuration file specifies NOR
flash so it's out of question that BDI2000 could program NAND by itself:
[FLASH]
CHIPTYPE MIRRORX16 ;Flash type: Micron Q-Flash MT28F640J3
Moreover, since workspace is disabled, direct image programming shall be
really slooow - you had to notice that. Did you? Most likely not - SW
burned your flash.
Best regards
Leonid.
^ permalink raw reply
* Re: [patch 7/7] ps3: FLASH ROM Storage Driver
From: Geert Uytterhoeven @ 2007-05-29 9:57 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070529095355.GA29351@lst.de>
On Tue, 29 May 2007, Christoph Hellwig wrote:
> On Fri, May 25, 2007 at 10:36:14AM +0200, Geert.Uytterhoeven@sonycom.com wrote:
> > Add a FLASH ROM Storage Driver for the PS3:
> > - Implemented as a misc character device driver
> > - Uses a fixed 256 KiB buffer allocated from boot memory as the hypervisor
> > requires the writing of aligned 256 KiB blocks
>
> Looks good, but please either make the driver aware of multiple devices
> even if they can't happen currently, or alternatively error out in
> ->probe if of some reason it's called for a second device.
ps3flash_probe() does return -EBUSY when called for a second device.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [patch 6/7] ps3: ROM Storage Driver
From: Christoph Hellwig @ 2007-05-29 9:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linuxppc-dev, Olaf Hering, linux-kernel
In-Reply-To: <1180217923.19517.42.camel@localhost.localdomain>
On Sun, May 27, 2007 at 08:18:43AM +1000, Benjamin Herrenschmidt wrote:
> > > > linux/highmem.h is not included to get the kmap_* prototypes.
> > >
> > > Beside, I don't see the point of using kmap on ppc64...
> >
> > So what should I use instead?
>
> you don't need to map ... the linear mapping is there.... page_address()
> should just work. But then, kmap will resolve to just that anyway so I
> suppose it doesn't matter.
Generally I'd prefer to use kmap everywhere, to keep code future-proof.
Similar to how I advocate using spinlocks even in drivers for UP-only
architectures.
^ permalink raw reply
* Re: [patch 7/7] ps3: FLASH ROM Storage Driver
From: Christoph Hellwig @ 2007-05-29 9:53 UTC (permalink / raw)
To: Geert.Uytterhoeven; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070525083632.815300000@sonycom.com>
On Fri, May 25, 2007 at 10:36:14AM +0200, Geert.Uytterhoeven@sonycom.com wrote:
> Add a FLASH ROM Storage Driver for the PS3:
> - Implemented as a misc character device driver
> - Uses a fixed 256 KiB buffer allocated from boot memory as the hypervisor
> requires the writing of aligned 256 KiB blocks
Looks good, but please either make the driver aware of multiple devices
even if they can't happen currently, or alternatively error out in
->probe if of some reason it's called for a second device.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 9:44 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Anton Blanchard,
Paul Mackerras
In-Reply-To: <20070529092658.GA32228@iram.es>
> - do you use the standard 32 bit ABI, in which case the caller of libraries
> does not care and the libraries can be put in the standard places, or are
> there cases where the ability to pass 64 bit values in a single
> register would improve performance to the point that it is worth
> having an incompatible library (where to put it and how to name it)?
>
> I'd rather lean towards the first solution but I don't have enough
> data to judge.
>
> - how can an application know that it can use 64 bit registers and call
> the optimized routines?
I'd say use the 32 bits ABI, AT_HWCAP will tell you if you are running
on a 64 bits capable machine. You can then either use hand tuned code at
runtime, or I think ld.so can load alternate libs based on the bits in
there.
> Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or
> 4.3 installed yet) that allows you to tell the compiler to use 32 bit
> addresses but assume that integer registers are 64 bit wide. As long
> as such an option does not exist, the usefulness of this feature is
> somewhat limited. In other words, GCC for now has support for ILP32 and
> LP64 modes, but it would be better to also have support for IP32L64.
Depends... If such binaries are actual 64 bits binaries from a kernel
POV, then no change is necessary.
> Have you considered the case of a mixed (IP32L64) mode calling a pure
> 32 bit library (or a user provided callback). The high part of R13-R31
> will also be clobbered. Therefore the caller has to save and restore
> all registers that are live around the call, which results in
> significant code bloat and needs compiler support.
Yes. The high parts are call clobbered. Either you use C code and you'll
need some new gcc options to use this mode, or, as it's mostly the
request for now, you use hand tuned asm code and you know what you are
doing.
> All of this of course unless all people who write mixed mode code
> are masochistic enough to limit themselves to 100% pure assembly...
:-)
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Gabriel Paubert @ 2007-05-29 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ulrich Weigand, Steve Munroe, linuxppc-dev list, Anton Blanchard,
Paul Mackerras
In-Reply-To: <1180425900.19517.136.camel@localhost.localdomain>
On Tue, May 29, 2007 at 06:05:00PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-29 at 03:52 -0400, Dan Malek wrote:
> > > I've been looking at saving & restoring the top 32 bits of 64 bits
> > > registers when delivering signals to 32 bits processes on a 64 bits
> > > kernel. The principle is easy, but I wonder where to stick them.
> >
> > I'm wondering why you need to do this at all?
> > Why would a 32-bit application care about or
> > know what to do with these?
>
> There are regular demands for the ability to use the full 64 bits
> registers in 32 bits applications when running on a 64 bits processor.
> That ranges from, iirc, the java folks, to people wanting to optimize
> some libs to use 64 bits registers internally when called from 32 bits
> apps etc...
My thoughts exactly, that's a very useful mode for some applications,
either loading a different library or having alternate routines depending
on the availability of 64 bit GPRs for "long long" integer computations,
block copying and initializing (and therefore struct copies and memset()),
etc...
But it also makes me wonder about a few things:
- do you use the standard 32 bit ABI, in which case the caller of libraries
does not care and the libraries can be put in the standard places, or are
there cases where the ability to pass 64 bit values in a single
register would improve performance to the point that it is worth
having an incompatible library (where to put it and how to name it)?
I'd rather lean towards the first solution but I don't have enough
data to judge.
- how can an application know that it can use 64 bit registers and call
the optimized routines?
Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or
4.3 installed yet) that allows you to tell the compiler to use 32 bit
addresses but assume that integer registers are 64 bit wide. As long
as such an option does not exist, the usefulness of this feature is
somewhat limited. In other words, GCC for now has support for ILP32 and
LP64 modes, but it would be better to also have support for IP32L64.
[...]
Well, after downloading the gcc trunk, it still seems to be the case.
Adding the IP32L64 mode des not seem to be such a huge project
(comparable to many Google SoC ones, but it's too late for 2007),
the problem is taht if it is started now, I don't think it will hit
an official GCC release before 2009 at the earliest.
>
> You can use the full 64 bits easily on powerpc, ld/std just work, it's
> only the flags calculations and branches, mostly, that are truncated
> when running in 32 bits mode.
Only the implicit flags calculations, cmp has both 32 and 64 bit
versions, so it's not _that_ bad. However multiprecision arithmetic will
have to be done in 32 bit mode because the carry setting[1] is linked
with the mode (well I seem to remember a variant of the architecture
which had 32 and 64 bit variants for generating the flags, but it was a
long time ago. I've not seen support for this hybrid monster in gcc's md
file and I don't know whether it ever saw the light).
> Also, the kernel syscall & interrupt
> entry/exit path will save & restore the full 64 bits.
>
> The problem is when you use signals. The compat signal code for 32 bits
> apps will only save and restore the bottom 32 bits, thus an application
> using signals will potentially corrupt the top 32 bits, which can be a
> problem if, for example, it uses a library that has optimisations based
> on using the full 64 bits.
>
> We don't intend to update jmpbuf, getcontext/setcontext etc... for
> those... they are purely call clobbered etc..., but it would be nice if
> at least the signal frame save/restore could properly deal with them so
> they don't get randomly clobbered.
Have you considered the case of a mixed (IP32L64) mode calling a pure
32 bit library (or a user provided callback). The high part of R13-R31
will also be clobbered. Therefore the caller has to save and restore
all registers that are live around the call, which results in
significant code bloat and needs compiler support.
All of this of course unless all people who write mixed mode code
are masochistic enough to limit themselves to 100% pure assembly...
Gabriel
[1] and overflow but sadly nobody cares about it, look at Ada code compiled
when checking for overflows and get deeply depressed :-(
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] remove geometry support from ps3 storage driver
From: Geert Uytterhoeven @ 2007-05-29 9:15 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20070521143938.GA20321@lst.de>
On Mon, 21 May 2007, Christoph Hellwig wrote:
> On Mon, May 21, 2007 at 02:53:11PM +0200, Olaf Hering wrote:
> > The old ps3_storage driver did not support DOS geometry, so there is no
> > point to start adding code for it.
>
> That's not quite true. sd applies some heuristics and has a default
> geometry if there is no ->bios_param method. Then again this whole
> gemetry thing really only makes sense on x86.
Would it make sense to have a default implementation in block/ioctl.c?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* USB Host at full speed
From: axelnico @ 2007-05-29 9:11 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hello ALL,
I m currently trying to force the USB host controller from MPC8349 to only work at full speed i.e. whatever is the connected device, the bandwidth should be 12MB.
I thought i could perform it just by setting some registers to right value but it aren't working.
I fear i have to force software to always use TT and split transfer but i dont know exactly where to start..
If anybody could help, would be so great!!
Thank you,
Pierre-Axel.
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 831 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 2/5] powerpc: Cleanup ptrace bits
From: Benjamin Herrenschmidt @ 2007-05-29 9:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ulrich.weigand, Paul Mackerras, Anton Blanchard
In-Reply-To: <20070529064531.D874CDDF70@ozlabs.org>
On Tue, 2007-05-29 at 16:45 +1000, Benjamin Herrenschmidt wrote:
>
> This patch cleans that up a bit by having a ptrace-common.h which
> contains
> really common code (and makes a lot more code common), and
> ptrace-ppc32.h and
> ptrace-ppc64.h files that contain the few remaining different bits.
Hrm.. we do have a subtle difference in vrregs that I've missed.. I'll
respin tomorrow. It looks like we don't store the VRSAVE register at the
same place on 32 and 64 bits... yuck. I need to double check tomorrow.
Ben.
^ permalink raw reply
* Re: Saving to 32 bits of GPRs in signal context
From: Benjamin Herrenschmidt @ 2007-05-29 8:05 UTC (permalink / raw)
To: Dan Malek
Cc: linuxppc-dev list, Ulrich Weigand, Paul Mackerras, Steve Munroe,
Anton Blanchard
In-Reply-To: <B1348C8C-09B1-4906-BF89-CC4206F0CA0A@embeddedalley.com>
On Tue, 2007-05-29 at 03:52 -0400, Dan Malek wrote:
> > I've been looking at saving & restoring the top 32 bits of 64 bits
> > registers when delivering signals to 32 bits processes on a 64 bits
> > kernel. The principle is easy, but I wonder where to stick them.
>
> I'm wondering why you need to do this at all?
> Why would a 32-bit application care about or
> know what to do with these?
There are regular demands for the ability to use the full 64 bits
registers in 32 bits applications when running on a 64 bits processor.
That ranges from, iirc, the java folks, to people wanting to optimize
some libs to use 64 bits registers internally when called from 32 bits
apps etc...
You can use the full 64 bits easily on powerpc, ld/std just work, it's
only the flags calculations and branches, mostly, that are truncated
when running in 32 bits mode. Also, the kernel syscall & interrupt
entry/exit path will save & restore the full 64 bits.
The problem is when you use signals. The compat signal code for 32 bits
apps will only save and restore the bottom 32 bits, thus an application
using signals will potentially corrupt the top 32 bits, which can be a
problem if, for example, it uses a library that has optimisations based
on using the full 64 bits.
We don't intend to update jmpbuf, getcontext/setcontext etc... for
those... they are purely call clobbered etc..., but it would be nice if
at least the signal frame save/restore could properly deal with them so
they don't get randomly clobbered.
Ben.
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: Andrei Konovalov @ 2007-05-29 8:07 UTC (permalink / raw)
To: John Williams
Cc: linuxppc-dev, Wolfgang Reissnegger, David H. Lynch Jr.,
linuxppc-embedded
In-Reply-To: <465B6611.1070107@itee.uq.edu.au>
John Williams wrote:
> Hi Wolfgang,
>
> Wolfgang Reissnegger wrote:
>> David H. Lynch Jr. wrote:
>>
>>> For me the most significant issue is the bazillion layers of nested
>>> macro's and includes.
>>
>>
>> I don't see the macros as an issue, just look at the implementation of,
>> for example, spin_lock_irq() and Xilinx's macros seem like child's
>> play :-)
>> As for includes, yes, there are a few too many header files. But, as
>> time progresses and the need arises they can be merged into fewer files.
>
> It seems the kernel.org decision has been made re: the style issue. None
> of the *_i.[ch], *_g.[ch] + adapter.c drivers will make it to mainline.
BTW, all the current drivers I am aware of have been moved to platform bus,
and do not use *_g.[ch] already.
> I understand why Xilinx did it this way, but to be honest never agreed
> with it myself either. Style issues aside, three levels of function
> calls in an interrupt handler might be portable, but it still isn't a
> good thing!
Another thing we've encountered while moving our current spi driver to the spi
framework is that sometimes there is too much "policy" in the level 1 drivers.
The level 1 spi driver controls the chip select on its own. For this reason
we were not able to use the spi_bitbang stuff. And even then we have to copy
the buffers into a single one to avoid CS toggling in the middle of the EEPROM
write sequence. The latter could probably be worked around, and could be due
to us not making the most of the level 1 driver, but at least this is not
trivial.
Yet another thing is that if one wants just FIFO mode for the TEMAC, he has
to include a bit of SGDMA code too as e.g. XTemac_Start() references
XDmaV3_SgStart() et al. IMHO wider usage of "virtual functions" would
help here (see e.g. how the System ACE driver by Grant L. handles different
bus widths).
Personally and in general, I like the idea of reusable OS independent code.
But it is hard to implement the way everyone would be happy with ;)
Thanks,
Andrei
^ permalink raw reply
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