Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote: > Change the PS3 platform code to use hard coded numbers for its > LV1 device types. > > The PS3 platform code was incorrectly using some scsi block > constants for the device type returned from the LV1 hypervisor. > > Fixes build errors like these when CONFIG_BLOCK=n: > > In file included from include/scsi/scsi.h:12, >from arch/powerpc/platforms/ps3/platform.h:25, >from arch/powerpc/platforms/ps3/setup.c:36: > include/scsi/scsi_cmnd.h:27:25: warning: "BLK_MAX_CDB" is not defined > include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not be > bigger than BLK_MAX_CDB > > Signed-off-by: Geoff Levand > --- > Ben, > > Please send upstream for 2.6.29. > > -Geoff > > arch/powerpc/platforms/ps3/platform.h |8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) > > --- a/arch/powerpc/platforms/ps3/platform.h > +++ b/arch/powerpc/platforms/ps3/platform.h > @@ -22,8 +22,6 @@ > #define _PS3_PLATFORM_H > > #include > -#include > - > #include > > /* htab */ > @@ -83,12 +81,12 @@ enum ps3_bus_type { > }; > > enum ps3_dev_type { > - PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */ > + PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */ > PS3_DEV_TYPE_SB_GELIC = 3, > PS3_DEV_TYPE_SB_USB = 4, > - PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */ > + PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */ > PS3_DEV_TYPE_SB_GPIO = 6, > - PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */ > + PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */ This looks like you're just papering over the bug, by hardcoding the same values that are in the scsi header. Or are they really independent, in which case I'd say the comments are confusing. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new "test" branch in powerpc.git tree
On Fri, 2009-02-06 at 18:42 +0100, Michel Dänzer wrote: > On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote: > > On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote: > > > > > >> Which begs the question of what master is for. So far, it's just been > > >> a mirror of next from what I can tell. Maybe it should just track > > >> Linus' tree? > > > > > >I've been wondering myself what to do with it ... I may just leave it to > > >track linus indeed. Or maybe just delete it. > > > > I don't think you can delete it without hosing people who try to clone it. > > The branch to check out by git clone can be overridden via a special > file in the .git directory in the shared repository. Unfortunately > though, I don't remember what it's called... According to Julien Cristau of the Debian X Strike Force (none of the Git repos of which have a master branch), it should be .git/HEAD. Some experiments of mine seem to confirm this. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
On Sunday 08 February 2009, Paul Collins wrote: > Paul Collins writes: > > > "Rafael J. Wysocki" writes: > > > >> On Wednesday 21 January 2009, Paul Collins wrote: > >>> Got a couple of these on a PowerBook running 2.6.29-rc2 either during > >>> suspend or resume -- it's hard to tell. (The suspend message is > >>> timestamped in syslog with the time I resumed, so I guess it was > >>> buffered along with the subsequent "Badness" messages.) > >> > >> Please check if the patch from http://lkml.org/lkml/2009/1/13/144 fixes the > >> problem for you. > > > > It does not fix the problem. > > I'm also getting this warning since 2.6.28.1, which incorporated commit > 1c5745aa380efb6417b5681104b007c8612fb496 ("sched_clock: prevent > scd->clock from moving backwards, take #2") as commit > e268dcdd404f4558cdd24c8ecede3e064df8fa33, this being the patch that > introduced the WARN_ON(timekeeping_suspended) check. Hm, I thought the timekeeping suspend problem was fixed in this commit. Ingo? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
* Rafael J. Wysocki wrote: > On Sunday 08 February 2009, Paul Collins wrote: > > Paul Collins writes: > > > > > "Rafael J. Wysocki" writes: > > > > > >> On Wednesday 21 January 2009, Paul Collins wrote: > > >>> Got a couple of these on a PowerBook running 2.6.29-rc2 either during > > >>> suspend or resume -- it's hard to tell. (The suspend message is > > >>> timestamped in syslog with the time I resumed, so I guess it was > > >>> buffered along with the subsequent "Badness" messages.) > > >> > > >> Please check if the patch from http://lkml.org/lkml/2009/1/13/144 fixes > > >> the > > >> problem for you. > > > > > > It does not fix the problem. > > > > I'm also getting this warning since 2.6.28.1, which incorporated commit > > 1c5745aa380efb6417b5681104b007c8612fb496 ("sched_clock: prevent > > scd->clock from moving backwards, take #2") as commit > > e268dcdd404f4558cdd24c8ecede3e064df8fa33, this being the patch that > > introduced the WARN_ON(timekeeping_suspended) check. > > Hm, I thought the timekeeping suspend problem was fixed in this commit. Ingo? Thomas? :-) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC 0/11] FSL eSDHC support: second call for comments
On Fri, 6 Feb 2009 21:05:20 +0300 Anton Vorontsov wrote: > Hi all, > > There were only a few comments on the previous version. So, here is > the second call for comments. > Yeah sorry, haven't really had time for looking over your patches properly. See my first comments to relevant patches now though. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/11] sdhci: Add support for bus-specific IO memory accessors
On Fri, 6 Feb 2009 21:06:45 +0300 Anton Vorontsov wrote: > Currently the SDHCI driver works with PCI accessors (write{l,b,w} and > read{l,b,w}). > > With this patch drivers may change memory accessors, so that we can > support hosts with "weird" IO memory access requirments. > > For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit > width, with big-endian addressing. That is, readb(0x2f) should turn > into readb(0x2c), and readw(0x2c) should be translated to > le16_to_cpu(readw(0x2e)). > > Signed-off-by: Anton Vorontsov > --- I was hoping we wouldn't have to do a lot of magic in the accessors since the spec is rather clear on the register interface. :/ Let's see if I've understood this correctly. 1. The CPU is big-endian but the register are little-endian (as the spec requires). I was under the impression that the read*/write* accessor handled any endian conversion between the bus and the cpu? How do e.g. PCI work on Sparc? 2. Register access must be done 32 bits at a time. Now this is just broken and might cause big problems as some registers cannot just be read and written back to. OTOH you refer to readw() in your example, not readl(). What's the deal here? > +static inline void sdhci_writel(struct sdhci_host *host, u32 val, int reg) > +{ > + host->writel(host, val, reg); > +} Having to override these are worst case scenario as far as I'm concerned, so I'd prefer something like: if (!host->ops->writel) writel(host->ioaddr + reg, val); else host->ops->writel(host, val, reg); and maybe even a likely() up there. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/11] sdhci: Add type checking for IO memory accessors
On Fri, 6 Feb 2009 21:06:48 +0300 Anton Vorontsov wrote: > A new restricted integer type introduced: sdhci_reg_t. > > Header file now specifies registers via sdhci_reg() inline function. > Only one place (not counting sdhci_def_*() accessors) need to cast > a register back to an offset, i.e. sdhci_finish_command(). > > From now on sparse tool will warn about IO memory accessors misuses, > for exampple: > > sdhci_writeb(host, SDHCI_TIMEOUT_CONTROL, count); > > CHECK sdhci.c > sdhci.c:614:21: warning: incorrect type in argument 2 (different base types) > sdhci.c:614:21:expected unsigned char [unsigned] [usertype] val > sdhci.c:614:21:got restricted int > sdhci.c:614:44: warning: incorrect type in argument 3 (different base types) > sdhci.c:614:44:expected restricted int [usertype] reg > sdhci.c:614:44:got unsigned char [unsigned] [assigned] [usertype] count > > Signed-off-by: Anton Vorontsov > --- Is this really a problem? It's a lot of noise in the code and I can't really see this as a major issue, or even a minor one. :) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/11] sdhci: Add support for card-detection polling
On Fri, 6 Feb 2009 21:06:50 +0300 Anton Vorontsov wrote: > This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified, > sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't > enable card insert/remove interrupts. > > This is needed for hosts with unreliable card detection, such as FSL > eSDHC. The original eSDHC driver was tring to "debounce" card-detection > IRQs by reading present state and disabling particular interrupts. But > with this debouncing scheme I noticed that sometimes we miss card > insertion/removal events. > > Signed-off-by: Anton Vorontsov > --- I guess you need to fix the check at the start of the request function as well. > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index b7a79a0..45c5f1f 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -162,6 +162,9 @@ static void sdhci_init(struct sdhci_host *host) > SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE | > SDHCI_INT_ADMA_ERROR; > > + if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) > + intmask &= ~(SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT); > + A matter of taste perhaps, but I think it would make more sense to not add them in the first place than to add and then remove them. Card detection interrupts should be handled separately anyway as they should not be enabled before mmc_add_host() returns and should be disabled before calling mmc_remove_host(). Patch welcome. ;) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/11] sdhci: Add quirk to suppress PIO interrupts during DMA transfers
On Fri, 6 Feb 2009 21:06:55 +0300 Anton Vorontsov wrote: > Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA > transfers, this causes tons of unneeded interrupts, and thus highly > degraded speed. > > This patch adds SDHCI_QUIRK_PIO_IRQS_DURING_DMA quirk. When specified, > the sdhci driver will disable PIO interrupts during DMA transfers. > > Signed-off-by: Anton Vorontsov > --- It's probably better to change the interrupt handling to only enable relevant interrupts instead of having everything on constantly. Too many quirks just makes the driver difficult to understand. -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/11] sdhci: Add support for hosts that don't specify clocks in the cap. register
On Fri, 6 Feb 2009 21:06:57 +0300 Anton Vorontsov wrote: > FSL eSDHC hosts don't provide clocks bits in the capabilities register, > instead we're getting clocks values from the device tree. > > There is somewhat similar change[1] from Ben Dooks, the change adds > callbacks for getting the clocks. But for eSDHC the callbacks are > superfluous, since the clocks are static. > > [1] http://lkml.org/lkml/2008/12/2/157 > > Signed-off-by: Anton Vorontsov > --- As I told Ben, I prefer if we stick to the standard as much as possible. So no external info unless the register is set to zero. And since we know the Samsung chip needs callbacks, we might as well add them here. It's not like this is a performance critical path. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/11] sdhci: Add set_clock callback
On Fri, 6 Feb 2009 21:06:59 +0300 Anton Vorontsov wrote: > FSL eSDHC hosts have incompatible register map to manage the SDCLK. > This patch adds set_clock callback so that drivers could overwrite > set_clock behaviour. > > Similar patch[1] was posted by Ben Dooks, though in Ben's version the > callback is named change_clock, plus the patch has some unrelated bits > that makes the patch difficult to reuse. > > [1] http://lkml.org/lkml/2008/12/2/160 > > Signed-off-by: Anton Vorontsov > --- A set_clock() callback is reasonable as there might be a clock source that needs to be set up, but completely overriding the normal routine (i.e. the "return") should be quirked IMO. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/11] sdhci: Add quirk for Freescale eSDHC controllers
On Fri, 6 Feb 2009 21:07:01 +0300 Anton Vorontsov wrote: > This patch adds SDHCI_QUIRK_FSL quirk. The quirk is used to instruct > the sdhci driver about various FSL eSDHC host incompatibilities: > No device quirks please. They should be for specific bugs, not lumping things together like this. Otherwise we'll soon have an unmanageable mess. > 1) FSL eSDHC controllers can support maximum block size up to 4096 >bytes. The MBL (Maximum Block Length) field in the capabilities >register extended by one bit. > >(Should we implement a dedicated quirk for this? I.e. > SDHCI_QUIRK_MAX_BLK_SZ_4096?) > Yes please. It would have to mean "always support 4096" though, not "turn reserved bit 18 into a block length bit". > 2) sdhci_init() is needed after error conditions. > >(Can we safely do this for all controllers?) > Please investigate which part of sdhci_init() is needed. How does it break without this? > 3) Small udelay is needed to make eSDHC work in PIO mode. Without >the delay reading causes endless interrupt storm, and writing >corrupts data. The first guess would be that we must wait for >some bit in some register, but I didn't find any reliable bits >that changes before and after the delay. Though, more investigation >on this is in my todo list. Please try to investigate more, but if you cannot improve it further then a specific quirk can be added. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/cell: add missing #include for oprofile
arch/powerpc/oprofile/cell/spu_profiler.c is missing a asm/time.h include which is required for ppc_proc_freq. This can cause compile failures for some config combinations. Signed-off-by: Michael Neuling --- This is against mainline, so should be pushed up soon-ish arch/powerpc/oprofile/cell/spu_profiler.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6-ozlabs/arch/powerpc/oprofile/cell/spu_profiler.c === --- linux-2.6-ozlabs.orig/arch/powerpc/oprofile/cell/spu_profiler.c +++ linux-2.6-ozlabs/arch/powerpc/oprofile/cell/spu_profiler.c @@ -16,6 +16,7 @@ #include #include #include +#include #include "pr_util.h" #define SCALE_SHIFT 14 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote: > On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote: > > Change the PS3 platform code to use hard coded numbers for its > > LV1 device types. > > > > The PS3 platform code was incorrectly using some scsi block > > constants for the device type returned from the LV1 hypervisor. > > > > Fixes build errors like these when CONFIG_BLOCK=n: > > > > In file included from include/scsi/scsi.h:12, > >from arch/powerpc/platforms/ps3/platform.h:25, > >from arch/powerpc/platforms/ps3/setup.c:36: > > include/scsi/scsi_cmnd.h:27:25: warning: "BLK_MAX_CDB" is not defined > > include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not be > > bigger than BLK_MAX_CDB Adding Jens and James on CC since I think a proper fix lies in blkdev.h or scsi*.h So basically, the whole of blkdev.h is inside a big ifdef CONFIG_BLOCK... which means that scsi_cmnd.h can't build which in turn makes scsi.h fail. The PS3 platform code wants to use some of the standard SCSI types from there though, as they are part of the hypervisor ABI. (And in fact it can be argued that non-block devices using SCSI do exist, such as scanners, no ?) Any reason other than pre-historical to have blkdev.h shielded like that ? Cheers, Ben. > > Signed-off-by: Geoff Levand > > --- > > Ben, > > > > Please send upstream for 2.6.29. > > > > -Geoff > > > > arch/powerpc/platforms/ps3/platform.h |8 +++- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > --- a/arch/powerpc/platforms/ps3/platform.h > > +++ b/arch/powerpc/platforms/ps3/platform.h > > @@ -22,8 +22,6 @@ > > #define _PS3_PLATFORM_H > > > > #include > > -#include > > - > > #include > > > > /* htab */ > > @@ -83,12 +81,12 @@ enum ps3_bus_type { > > }; > > > > enum ps3_dev_type { > > - PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */ > > + PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */ > > PS3_DEV_TYPE_SB_GELIC = 3, > > PS3_DEV_TYPE_SB_USB = 4, > > - PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */ > > + PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */ > > PS3_DEV_TYPE_SB_GPIO = 6, > > - PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */ > > + PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */ > > This looks like you're just papering over the bug, by hardcoding the > same values that are in the scsi header. Or are they really independent, > in which case I'd say the comments are confusing. > > cheers > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
The new legacy_mem file in sysfs is causing problems with X on machines that don't support legacy memory access. The way I initially implemented it, we would fail with -ENXIO when trying to mmap it, thus exposing to X that we do support the API but there is no legacy memory. Unfortunately, X poor error handling is causing it to fail to start when it gets this error. This implements a workaround hack that instead maps anonymous memory instead (using shmem if VM_SHARED is set, just like /dev/zero does). Signed-off-by: Benjamin Herrenschmidt --- This fixes a regression in .29 and is the less ugly way we found to sort this problem out. I'll merge it ASAP so holler quick if you have an objection arch/powerpc/kernel/pci-common.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) --- linux-work.orig/arch/powerpc/kernel/pci-common.c2009-02-06 16:23:36.0 +1100 +++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.0 +1100 @@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc (unsigned long long)(offset + size - 1)); if (mmap_state == pci_mmap_mem) { - if ((offset + size) > hose->isa_mem_size) - return -ENXIO; + /* Hack alert ! +* +* Because X is lame and can fail starting if it gets an error trying +* to mmap legacy_mem (instead of just moving on without legacy memory +* access) we fake it here by giving it anonymous memory, effectively +* behaving just like /dev/zero +*/ + if ((offset + size) > hose->isa_mem_size) { + printk(KERN_DEBUG + "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n", + current->comm, current->pid, pci_domain_nr(bus), bus->number); + if (vma->vm_flags & VM_SHARED) + return shmem_zero_setup(vma); + return 0; + } offset += hose->isa_mem_phys; } else { unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add missing sparsemem.h include
arch/powerpc/platforms/pseries/hotplug-memory.c uses remove_section_mapping() but doesn't include sparsemem.h which defines it. This can cause compilation fails for some configs. Signed-off-by: Michael Neuling --- This is against mainline, so should be pushed up soon-ish... arch/powerpc/platforms/pseries/hotplug-memory.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-memory.c === --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-memory.c +++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-memory.c @@ -14,6 +14,7 @@ #include #include #include +#include static int pseries_remove_lmb(unsigned long base, unsigned int lmb_size) { ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc/ps3: Use hard coded values for LV1 device type
On Mon, 2009-02-09 at 11:11 +1100, Benjamin Herrenschmidt wrote: > On Sun, 2009-02-08 at 22:29 +1100, Michael Ellerman wrote: > > On Fri, 2009-02-06 at 18:42 -0800, Geoff Levand wrote: > > > Change the PS3 platform code to use hard coded numbers for its > > > LV1 device types. > > > > > > The PS3 platform code was incorrectly using some scsi block > > > constants for the device type returned from the LV1 hypervisor. > > > > > > Fixes build errors like these when CONFIG_BLOCK=n: > > > > > > In file included from include/scsi/scsi.h:12, > > >from arch/powerpc/platforms/ps3/platform.h:25, > > >from arch/powerpc/platforms/ps3/setup.c:36: > > > include/scsi/scsi_cmnd.h:27:25: warning: "BLK_MAX_CDB" is not defined > > > include/scsi/scsi_cmnd.h:28:3: error: #error MAX_COMMAND_SIZE can not > > > be bigger than BLK_MAX_CDB > > Adding Jens and James on CC since I think a proper fix lies in blkdev.h > or scsi*.h And cc'd linux-scsi > So basically, the whole of blkdev.h is inside a big ifdef > CONFIG_BLOCK... which means that scsi_cmnd.h can't build which in turn > makes scsi.h fail. Well, look at it from our point of view; it's impossible to build SCSI without block, so a little interdependence is easy to get. > The PS3 platform code wants to use some of the standard SCSI types from > there though, as they are part of the hypervisor ABI. (And in fact it > can be argued that non-block devices using SCSI do exist, such as > scanners, no ?) > > Any reason other than pre-historical to have blkdev.h shielded like > that ? Actually, I think the fix lies in scsi.h ... we can make that into a nicely independent protocol header file. Your current woes come because it pulls in scsi_cmnd.h ... perhaps just getting rid of this will fix it. Can the rest of linux-scsi verify that the fix below doesn't break something else? I found one cockup: block/cmd-filter.c is apparently not including linuc/blkdev.h directly but via scsi/scsi.h ... I fixed this up. > Cheers, > Ben. > > > > Signed-off-by: Geoff Levand > > > --- > > > Ben, > > > > > > Please send upstream for 2.6.29. > > > > > > -Geoff > > > > > > arch/powerpc/platforms/ps3/platform.h |8 +++- > > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > > > --- a/arch/powerpc/platforms/ps3/platform.h > > > +++ b/arch/powerpc/platforms/ps3/platform.h > > > @@ -22,8 +22,6 @@ > > > #define _PS3_PLATFORM_H > > > > > > #include > > > -#include > > > - > > > #include > > > > > > /* htab */ > > > @@ -83,12 +81,12 @@ enum ps3_bus_type { > > > }; > > > > > > enum ps3_dev_type { > > > - PS3_DEV_TYPE_STOR_DISK = TYPE_DISK, /* 0 */ > > > + PS3_DEV_TYPE_STOR_DISK = 0, /* TYPE_DISK */ > > > PS3_DEV_TYPE_SB_GELIC = 3, > > > PS3_DEV_TYPE_SB_USB = 4, > > > - PS3_DEV_TYPE_STOR_ROM = TYPE_ROM, /* 5 */ > > > + PS3_DEV_TYPE_STOR_ROM = 5, /* TYPE_ROM */ > > > PS3_DEV_TYPE_SB_GPIO = 6, > > > - PS3_DEV_TYPE_STOR_FLASH = TYPE_RBC, /* 14 */ > > > + PS3_DEV_TYPE_STOR_FLASH = 14, /* TYPE_RBC */ > > > > This looks like you're just papering over the bug, by hardcoding the > > same values that are in the scsi header. Or are they really independent, > > in which case I'd say the comments are confusing. > > > > cheers James --- diff --git a/block/cmd-filter.c b/block/cmd-filter.c index 504b275..572bbc2 100644 --- a/block/cmd-filter.c +++ b/block/cmd-filter.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index 80d7f60..084478e 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -9,7 +9,8 @@ #define _SCSI_SCSI_H #include -#include + +struct scsi_cmnd; /* * The maximum number of SG segments that we will put inside a @@ -439,22 +440,6 @@ static inline int scsi_is_wlun(unsigned int lun) #define host_byte(result) (((result) >> 16) & 0xff) #define driver_byte(result) (((result) >> 24) & 0xff) -static inline void set_msg_byte(struct scsi_cmnd *cmd, char status) -{ - cmd->result |= status << 8; -} - -static inline void set_host_byte(struct scsi_cmnd *cmd, char status) -{ - cmd->result |= status << 16; -} - -static inline void set_driver_byte(struct scsi_cmnd *cmd, char status) -{ - cmd->result |= status << 24; -} - - #define sense_class(sense) (((sense) >> 4) & 0x7) #define sense_error(sense) ((sense) & 0xf) #define sense_valid(sense) ((sense) & 0x80); diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h index 855bf95..43b50d3 100644 --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -291,4 +291,19 @@ static inline struct scsi_data_buffer *scsi_prot(struct scsi_cmnd *cmd) #define scsi_for_each_prot_sg(cmd, sg, nseg, __i) \ for_each_sg(scsi_prot_sglist(cmd), sg, nseg, __i) +static inline void set_msg_byte(struct scsi_cmnd *cmd, char status) +{ + cmd->result |= status << 8; +} + +static inline void set_host
2.6.29-rc4-git1 build break : cell/spu_profiler.o
2.6.29-rc4-git1 randconfig build on powerpc fails with CALLarch/powerpc/kernel/prom_init_check.sh CC [M] arch/powerpc/oprofile/cell/spu_profiler.o arch/powerpc/oprofile/cell/spu_profiler.c: In function set_spu_profiling_frequency: arch/powerpc/oprofile/cell/spu_profiler.c:52: error: ppc_proc_freq undeclared (first use in this function) arch/powerpc/oprofile/cell/spu_profiler.c:52: error: (Each undeclared identifier is reported only once arch/powerpc/oprofile/cell/spu_profiler.c:52: error: for each function it appears in.) make[1]: *** [arch/powerpc/oprofile/cell/spu_profiler.o] Error 1 make: *** [arch/powerpc/oprofile] Error 2 .config attached. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29-rc4-git1 # Mon Feb 9 13:45:17 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y # CONFIG_VIRT_CPU_ACCOUNTING is not set CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_MM_OWNER=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_PPC_PSERIES is not set CONFIG_LPARCFG=y CON
Re: 2.6.29-rc4-git1 build break : cell/spu_profiler.o
Hi Sachin, On Mon, 09 Feb 2009 12:13:41 +0530 "Sachin P. Sant" wrote: > > 2.6.29-rc4-git1 randconfig build on powerpc fails with > > CALLarch/powerpc/kernel/prom_init_check.sh > CC [M] arch/powerpc/oprofile/cell/spu_profiler.o > arch/powerpc/oprofile/cell/spu_profiler.c: In function > set_spu_profiling_frequency: > arch/powerpc/oprofile/cell/spu_profiler.c:52: error: ppc_proc_freq undeclared > (first use in this function) > arch/powerpc/oprofile/cell/spu_profiler.c:52: error: (Each undeclared > identifier is reported only once > arch/powerpc/oprofile/cell/spu_profiler.c:52: error: for each function it > appears in.) > make[1]: *** [arch/powerpc/oprofile/cell/spu_profiler.o] Error 1 > make: *** [arch/powerpc/oprofile] Error 2 See http://patchwork.ozlabs.org/patch/22628/ -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpSJ9j3KYky3.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.29-rc4-git1 build break : cell/spu_profiler.o
Stephen Rothwell wrote: See http://patchwork.ozlabs.org/patch/22628/ Thanks Stephen. The above patch fixed this build break. Regards -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/83xx: Fix TSEC0 workability on MPC8313E-RDB boards
On Fri, Feb 6, 2009 at 4:10 AM, Anton Vorontsov wrote: > TSEC0 is connected to Vitesse 7385 5-port switch. The switch > isn't connected to any mdio bus, the link to the switch is fixed > to Full-duplex 1000 Mb/s (no pause). It's a complex case for RDB boards. The revision A and revision B boards DO always connect TSEC0 to Vitesse switch. While the latest revision C board has one setting to connect TSEC0 to a Marvell PHY and MDIO bus. In BSP we have several DTS's for each setting of the board, shouldn't we do the same for upstream? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev