[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > I haven't checked all architectures, but I assume what happens is that > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > to provide three sets of functions. > > scratch that, I just looked at all the architectures and found that it's > just completely arbitrary, even within one architecture you get a mix > of 'long' and 'long long', plus this gem from MIPS: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > which truncates the result to 32 bit. Eh... The result is 0/1 so nothing is truncated. Alpha, MIPS, PARISC and PowerPC are using the same prototype and x86 only differs in the use of inline instead __inline__. And anyway, that function on MIPS is only built for CONFIG_64BIT. What's wrong on MIPS is the comment describing the function's return value which was changed by f24219b4e90cf70ec4a211b17fbabc725a0ddf3c (atomic: move atomic_add_unless to generic code) and I've queued up a patch to fix that since a few days. I guess that was a cut and paste error from __atomic_add_unless which indeed does return the old value. Ralf
[PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).
On Sat, Aug 11, 2012 at 05:32:18PM +0800, Huacai Chen wrote: > Subject: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = > 16KB). But your code doesn't define it just for Loongsson as the log message claims but rather for all MIPS. > diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h > index ee5389d..1d1a858 100644 > --- a/include/drm/drm_sarea.h > +++ b/include/drm/drm_sarea.h > @@ -37,6 +37,8 @@ > /* SAREA area needs to be at least a page */ > #if defined(__alpha__) > #define SAREA_MAX 0x2000U > +#elif defined(__mips__) > +#define SAREA_MAX 0x4000U How about replacing this whole #ifdef mess with something like: #include #include /* Intel 830M driver needs at least 8k SAREA */ #define SAREA_MAX max(PAGE_SIZE, 0x2000U) MIPS also uses 64K page size and your patch as posted would break with 64k pages. Ralf
Re: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB).
On Sat, Aug 11, 2012 at 05:32:18PM +0800, Huacai Chen wrote: Subject: [PATCH V5 13/18] drm: Define SAREA_MAX for Loongson (PageSize = 16KB). But your code doesn't define it just for Loongsson as the log message claims but rather for all MIPS. diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h index ee5389d..1d1a858 100644 --- a/include/drm/drm_sarea.h +++ b/include/drm/drm_sarea.h @@ -37,6 +37,8 @@ /* SAREA area needs to be at least a page */ #if defined(__alpha__) #define SAREA_MAX 0x2000U +#elif defined(__mips__) +#define SAREA_MAX 0x4000U How about replacing this whole #ifdef mess with something like: #include linux/kernel.h #include asm/page.h /* Intel 830M driver needs at least 8k SAREA */ #define SAREA_MAX max(PAGE_SIZE, 0x2000U) MIPS also uses 64K page size and your patch as posted would break with 64k pages. Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fri, Jun 22, 2012 at 06:55:40PM +0800, Huacai Chen wrote: > > btw, would it be a good idea to use uncached accelerated instead ? > I have tried uncached accelerated, there will be random points in the > monitor, it seems a hw issue... Have you flushed the pages from memory before switching their cache mode to uncached accelerated? The MIPS architecture defines the result of mixing cache modes as UNPREDICTABLE so be careful to flush caches before switching cache mode of a page. Ralf
[PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fri, Jun 22, 2012 at 11:39:19AM +0200, Arnaud Patard wrote: > > --- a/drivers/gpu/drm/drm_vm.c > > +++ b/drivers/gpu/drm/drm_vm.c > > @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct > > vm_area_struct *vma) > > tmp = pgprot_writecombine(tmp); > > else > > tmp = pgprot_noncached(tmp); > > -#elif defined(__sparc__) || defined(__arm__) > > +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) > > tmp = pgprot_noncached(tmp); > > btw, would it be a good idea to use uncached accelerated instead ? Not unconditionally. Only some MIPS cores support uncached accelerated. Basically you can only assume that cache modes 2 (uncached) (3 cachable non-coherent) are supported. On a SMP system use of 2 and 3 may be unwise (SGI IP27 and IP35 may throw obscure exceptions to indicate their dislike of these.) and on multi-processor systems there is mode 5, which is cachable coherent. The necessary logic is too complex to got into drm_io_prot() which already is an #ifdef mess anyway so that function should be changed to call some sort of architecutre specific hook so that function should be changed to call some sort of architecture specific hook... Ralf
Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fri, Jun 22, 2012 at 06:55:40PM +0800, Huacai Chen wrote: btw, would it be a good idea to use uncached accelerated instead ? I have tried uncached accelerated, there will be random points in the monitor, it seems a hw issue... Have you flushed the pages from memory before switching their cache mode to uncached accelerated? The MIPS architecture defines the result of mixing cache modes as UNPREDICTABLE so be careful to flush caches before switching cache mode of a page. Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fri, Jun 22, 2012 at 11:39:19AM +0200, Arnaud Patard wrote: --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) tmp = pgprot_writecombine(tmp); else tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) tmp = pgprot_noncached(tmp); btw, would it be a good idea to use uncached accelerated instead ? Not unconditionally. Only some MIPS cores support uncached accelerated. Basically you can only assume that cache modes 2 (uncached) (3 cachable non-coherent) are supported. On a SMP system use of 2 and 3 may be unwise (SGI IP27 and IP35 may throw obscure exceptions to indicate their dislike of these.) and on multi-processor systems there is mode 5, which is cachable coherent. The necessary logic is too complex to got into drm_io_prot() which already is an #ifdef mess anyway so that function should be changed to call some sort of architecutre specific hook so that function should be changed to call some sort of architecture specific hook... Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] Fix various section mismatches and build errors.
On Wed, Jun 29, 2011 at 08:14:24AM -0700, Greg KH wrote: > > On Wed, Jun 29, 2011 at 08:58:19AM -0500, James Bottomley wrote: > > I think we should simply concentrate on __init and __exit; that's where > > most of the discard value lies and stop expending huge efforts on the > > __devX stuff which adds huge complexity for no real gain. > > I have long felt that those __devX markings should just go away as they > cause nothing but problems and have no real gain as you point out. The suggestion to do that has been floated around before but seems to have missed sufficient thrust. I'm all for it; the manual tagging with __devX has not been very efficient on developer time. I just want to see meaningful warnings again over all that noise the current mechanisn may produce. Ralf
[PATCH 00/12] Fix various section mismatches and build errors.
On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote: > commit 948252cb9e01d65a89ecadf67be5018351eee15e > Author: David S. Miller > Date: Tue May 31 19:27:48 2011 -0700 > > Revert "net: fix section mismatches" > > This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. > > It causes new build regressions with gcc-4.2 which is > pretty common on non-x86 platforms. > > Reported-by: James Bottomley > Signed-off-by: David S. Miller > > and postings that led to this revert including: > > http://marc.info/?l=linux-netdev=130653748205263=2 Thanks for the pointers; I looked into it a bit deeper and found that the construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of const and __devinitconst __devinitdata. My patches are minimalistic and don't do any constification and seem to work fine for PA-RISC. A possible alternative to allow the use of Micha?'s reverted patch would be to conditionalize the definition of __devinitconst. There is no user of __devexitconst so I left that unchanged. Ralf Signed-off-by: Ralf Baechle include/linux/init.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index 577671c..e12fd85 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -84,7 +84,15 @@ /* Used for HOTPLUG */ #define __devinit__section(.devinit.text) __cold #define __devinitdata__section(.devinit.data) +#if defined __GNUC__ && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2) +/* + * GCC 4.2 will sometimes throw an error if the combination of const and + * __devinitconst is being used. As a workaround make __devinitconst a noop + */ +#define __devinitconst +#else #define __devinitconst __section(.devinit.rodata) +#endif #define __devexit__section(.devexit.text) __exitused __cold #define __devexitdata__section(.devexit.data) #define __devexitconst __section(.devexit.rodata)
Re: [PATCH 00/12] Fix various section mismatches and build errors.
On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote: commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller da...@davemloft.net Date: Tue May 31 19:27:48 2011 -0700 Revert net: fix section mismatches This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. It causes new build regressions with gcc-4.2 which is pretty common on non-x86 platforms. Reported-by: James Bottomley james.bottom...@hansenpartnership.com Signed-off-by: David S. Miller da...@davemloft.net and postings that led to this revert including: http://marc.info/?l=linux-netdevm=130653748205263w=2 Thanks for the pointers; I looked into it a bit deeper and found that the construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of const and __devinitconst __devinitdata. My patches are minimalistic and don't do any constification and seem to work fine for PA-RISC. A possible alternative to allow the use of Michał's reverted patch would be to conditionalize the definition of __devinitconst. There is no user of __devexitconst so I left that unchanged. Ralf Signed-off-by: Ralf Baechle r...@linux-mips.org include/linux/init.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h index 577671c..e12fd85 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -84,7 +84,15 @@ /* Used for HOTPLUG */ #define __devinit__section(.devinit.text) __cold #define __devinitdata__section(.devinit.data) +#if defined __GNUC__ (__GNUC__ == 4) (__GNUC_MINOR__ == 2) +/* + * GCC 4.2 will sometimes throw an error if the combination of const and + * __devinitconst is being used. As a workaround make __devinitconst a noop + */ +#define __devinitconst +#else #define __devinitconst __section(.devinit.rodata) +#endif #define __devexit__section(.devexit.text) __exitused __cold #define __devexitdata__section(.devexit.data) #define __devexitconst __section(.devexit.rodata) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] DRM: Radeon: Fix section mismatch.
WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in
reference from the function radeon_get_clock_info() to the function
.devinit.text:radeon_read_clocks_OF()
The function radeon_get_clock_info() references
the function __devinit radeon_read_clocks_OF().
This is often because radeon_get_clock_info lacks a __devinit
annotation or the annotation of radeon_read_clocks_OF is wrong.
Signed-off-by: Ralf Baechle r...@linux-mips.org
To: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---
drivers/gpu/drm/radeon/radeon_clocks.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c
b/drivers/gpu/drm/radeon/radeon_clocks.c
index 2d48e7a..dcd0863e 100644
--- a/drivers/gpu/drm/radeon/radeon_clocks.c
+++ b/drivers/gpu/drm/radeon/radeon_clocks.c
@@ -96,7 +96,7 @@ uint32_t radeon_legacy_get_memory_clock(struct radeon_device
*rdev)
* Read XTAL (ref clock), SCLK and MCLK from Open Firmware device
* tree. Hopefully, ATI OF driver is kind enough to fill these
*/
-static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+static bool radeon_read_clocks_OF(struct drm_device *dev)
{
struct radeon_device *rdev = dev-dev_private;
struct device_node *dp = rdev-pdev-dev.of_node;
@@ -166,7 +166,7 @@ static bool __devinit radeon_read_clocks_OF(struct
drm_device *dev)
return true;
}
#else
-static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+static bool radeon_read_clocks_OF(struct drm_device *dev)
{
return false;
}
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] Fix various section mismatches and build errors.
I'm getting screen and screens full of section mismatches from my test builds of the current kernel to the point where it's sometimes more meaningful messages get hidden by the bulk of mismatches. This is the first round of fixes with more to come. Ralf drivers/gpu/drm/radeon/radeon_clocks.c |4 ++-- drivers/leds/leds-lp5521.c |4 ++-- drivers/leds/leds-lp5523.c |4 ++-- drivers/misc/ioc4.c|2 +- drivers/net/3c509.c|2 +- drivers/net/3c59x.c|2 +- drivers/net/depca.c| 25 + drivers/net/hp100.c|2 +- drivers/net/ne3210.c | 12 +++- drivers/net/tulip/de4x5.c |2 +- drivers/scsi/sim710.c |2 +- drivers/tty/serial/Kconfig |2 +- 12 files changed, 33 insertions(+), 30 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] DRM: Radeon: Fix section mismatch.
WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in
reference from the function radeon_get_clock_info() to the function
.devinit.text:radeon_read_clocks_OF()
The function radeon_get_clock_info() references
the function __devinit radeon_read_clocks_OF().
This is often because radeon_get_clock_info lacks a __devinit
annotation or the annotation of radeon_read_clocks_OF is wrong.
Signed-off-by: Ralf Baechle
To: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-mips at linux-mips.org
---
drivers/gpu/drm/radeon/radeon_clocks.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c
b/drivers/gpu/drm/radeon/radeon_clocks.c
index 2d48e7a..dcd0863e 100644
--- a/drivers/gpu/drm/radeon/radeon_clocks.c
+++ b/drivers/gpu/drm/radeon/radeon_clocks.c
@@ -96,7 +96,7 @@ uint32_t radeon_legacy_get_memory_clock(struct radeon_device
*rdev)
* Read XTAL (ref clock), SCLK and MCLK from Open Firmware device
* tree. Hopefully, ATI OF driver is kind enough to fill these
*/
-static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+static bool radeon_read_clocks_OF(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
struct device_node *dp = rdev->pdev->dev.of_node;
@@ -166,7 +166,7 @@ static bool __devinit radeon_read_clocks_OF(struct
drm_device *dev)
return true;
}
#else
-static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+static bool radeon_read_clocks_OF(struct drm_device *dev)
{
return false;
}
--
1.7.4.4
[PATCH 00/12] Fix various section mismatches and build errors.
I'm getting screen and screens full of section mismatches from my test builds of the current kernel to the point where it's sometimes more meaningful messages get hidden by the bulk of mismatches. This is the first round of fixes with more to come. Ralf drivers/gpu/drm/radeon/radeon_clocks.c |4 ++-- drivers/leds/leds-lp5521.c |4 ++-- drivers/leds/leds-lp5523.c |4 ++-- drivers/misc/ioc4.c|2 +- drivers/net/3c509.c|2 +- drivers/net/3c59x.c|2 +- drivers/net/depca.c| 25 + drivers/net/hp100.c|2 +- drivers/net/ne3210.c | 12 +++- drivers/net/tulip/de4x5.c |2 +- drivers/scsi/sim710.c |2 +- drivers/tty/serial/Kconfig |2 +- 12 files changed, 33 insertions(+), 30 deletions(-)
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote: So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be. Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25 USB floppy drives ...) Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: > Can we drop most of MCA, EISA and ISA bus if we are going to have a big > version change ? A driver spring clean is much overdue and it's all in > git in case someone wishes to sneak out at midnight and bring some crawly > horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25" USB floppy drives ...) Ralf
(Short?) merge window reminder
On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote: > > So I'm toying with 3.0 (and in that case, it really would be "3.0", > > not "3.0.0" - the stable team would get the third digit rather than > > the fourth one. > > If we change from 2.6.X to 3.X, then if we don't change anything else, > then successive stable release will cause the LINUX_VERSION_CODE to be > incremented. This isn't necessary bad, but it would be a different > from what we have now. It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be. Ralf
