* Re: [PATCH 00/18] Export SPI and OF module aliases in missing drivers
From: Javier Martinez Canillas @ 2015-08-20 21:50 UTC (permalink / raw)
To: Brian Norris
Cc: linux-kernel, Andrzej Hajda, linux-fbdev, Michael Hennerich,
linux-iio, linux-wireless, Lee Jones,
Jean-Christophe Plagniol-Villard, linux-mtd, Lauro Ramos Venancio,
Søren Andersen, devel, Randy Dunlap, Masanari Iida,
Jiri Kosina, Devendra Naga, Tomi Valkeinen, Kyungmin Park,
Krzysztof Kozlowski, Greg Kroah-Hartman, Aloisio Almeida Jr,
Jonathan Cameron, Stephen Warren, Urs Fässler, Adrian Hunter,
Mauro Carvalho Chehab, Aya Mahfouz, George McCollister,
Samuel Ortiz, Manfred Schlaegl, linux-omap, Hartmut Knaack,
Ulf Hansson, Antonio Borneo, Andrea Galbusera, Michael Welling,
Fabian Frederick, Mark Brown, linux-mmc, linux-spi,
Lars-Peter Clausen, David Woodhouse, netdev, linux-media,
Peter Meerwald
In-Reply-To: <20150820211152.GI74600@google.com>
Hello Brian,
On 08/20/2015 11:11 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 09:07:13AM +0200, Javier Martinez Canillas wrote:
>> Patches #1 and #2 solves a), patches #3 to #8 solves b) and patches
>
> ^^^ I'm dying to know how this sentence ends :)
>
Sigh, I did some last minute restructuring of the cover letter and
seems I missed a sentence. I meant to said:
"and patches #9 to #17 solves c)."
>> Patch #18 changes the logic of spi_uevent() to report an OF modalias if
>> the device was registered using OF. But this patch is included in the
>> series only as an RFC for illustration purposes since changing that
>> without first applying all the other patches in this series, will break
>> module autoloading for the drivers of devices registered using OF but
>> that lacks an of_match_table. I'll repost patch #18 once all the patches
>> in this series have landed.
>
> On a more productive note, the patches I've looked at look good to me.
> The missing aliases are a problem enough that should be fixed (i.e.,
> part (b)). I'll leave the SPI framework changes to others to comment on.
>
Great, thanks a lot for your feedback.
> Brian
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-08-21 1:46 UTC (permalink / raw)
To: Tomi Valkeinen, Jingoo Han
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <55D59AE2.7090201@ti.com>
On 20.08.2015 18:16, Tomi Valkeinen wrote:
>
>
> On 24/07/15 09:12, Krzysztof Kozlowski wrote:
>> 2015-07-08 13:34 GMT+09:00 Jingoo Han <jingoohan1@gmail.com>:
>>>
>>> On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski <k.kozlowski.k@gmail.com> wrote:
>>>>
>>>> The platform_device_id is not modified by the driver and core uses it as
>>>> const.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
>>>
>>> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>>>
>>> Best regards,
>>> Jingoo Han
>>
>> Seems nobody is picking it up, so I merge it through Samsung-SoC tree.
>> If there are any objections please let me know.
>
> I can pick this up if you didn't already do that.
Could you? It would be great.
Kukjin did not pick it up so it is still waiting for some attention. :)
Best regards,
Krzysztof
^ permalink raw reply
* [RFC V2] fbdev/nvidia:change reverse_order() macro
From: yalin wang @ 2015-08-21 3:36 UTC (permalink / raw)
To: adaplas, plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: yalin wang
This change reverse_order() to swab32(bitrev32()), so that
it can have better performance on some platforms.
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/video/fbdev/nvidia/nv_local.h | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_local.h b/drivers/video/fbdev/nvidia/nv_local.h
index 68e508d..2c6baa1 100644
--- a/drivers/video/fbdev/nvidia/nv_local.h
+++ b/drivers/video/fbdev/nvidia/nv_local.h
@@ -97,18 +97,19 @@
#ifdef __LITTLE_ENDIAN
+#include <linux/swab.h>
#include <linux/bitrev.h>
+static inline void reverse_order(u32 *data)
+{
+ *data = swab32(bitrev32(*data));
+}
-#define reverse_order(l) \
-do { \
- u8 *a = (u8 *)(l); \
- a[0] = bitrev8(a[0]); \
- a[1] = bitrev8(a[1]); \
- a[2] = bitrev8(a[2]); \
- a[3] = bitrev8(a[3]); \
-} while(0)
#else
-#define reverse_order(l) do { } while(0)
-#endif /* __LITTLE_ENDIAN */
+static inline void reverse_order(u32 *data)
+{
+
+}
+
+#endif /* __LITTLE_ENDIAN */
#endif /* __NV_LOCAL_H__ */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Tomi Valkeinen @ 2015-08-21 5:57 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jingoo Han
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <55D682F3.5090800@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On 21/08/15 04:46, Krzysztof Kozlowski wrote:
> On 20.08.2015 18:16, Tomi Valkeinen wrote:
>>
>>
>> On 24/07/15 09:12, Krzysztof Kozlowski wrote:
>>> 2015-07-08 13:34 GMT+09:00 Jingoo Han <jingoohan1@gmail.com>:
>>>>
>>>> On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski <k.kozlowski.k@gmail.com> wrote:
>>>>>
>>>>> The platform_device_id is not modified by the driver and core uses it as
>>>>> const.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
>>>>
>>>> Acked-by: Jingoo Han <jingoohan1@gmail.com>
>>>>
>>>> Best regards,
>>>> Jingoo Han
>>>
>>> Seems nobody is picking it up, so I merge it through Samsung-SoC tree.
>>> If there are any objections please let me know.
>>
>> I can pick this up if you didn't already do that.
>
> Could you? It would be great.
> Kukjin did not pick it up so it is still waiting for some attention. :)
Ok. I've queued this for 4.3.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [RFC V2] fbdev/riva:change to use generice function to implement reverse_order()
From: yalin wang @ 2015-08-21 5:59 UTC (permalink / raw)
To: adaplas, plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel; +Cc: yalin wang
This change to use swab32(bitrev32()) to implement reverse_order()
function, have better performance on some platforms.
Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
---
drivers/video/fbdev/riva/fbdev.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index f1ad274..ccf0f82 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -40,6 +40,7 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/backlight.h>
+#include <linux/swab.h>
#include <linux/bitrev.h>
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/machdep.h>
@@ -453,11 +454,7 @@ static inline unsigned char MISCin(struct riva_par *par)
static inline void reverse_order(u32 *l)
{
- u8 *a = (u8 *)l;
- a[0] = bitrev8(a[0]);
- a[1] = bitrev8(a[1]);
- a[2] = bitrev8(a[2]);
- a[3] = bitrev8(a[3]);
+ *l = swab32(bitrev32(*l));
}
/* ------------------------------------------------------------------------- *
--
1.9.1
^ permalink raw reply related
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Tomi Valkeinen @ 2015-08-21 6:41 UTC (permalink / raw)
To: yalin wang; +Cc: adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <867D66CD-9A3B-4536-B537-8C065C85E497@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 20/08/15 14:30, yalin wang wrote:
>
>> On Aug 20, 2015, at 19:02, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>>
>> On 10/08/15 13:12, yalin wang wrote:
>>> This change to use swab32(bitrev32()) to implement reverse_order()
>>> function, have better performance on some platforms.
>>
>> Which platforms? Presuming you tested this, roughly how much better
>> performance? If you didn't, how do you know it's faster?
>
> i investigate on arm64 platforms:
Ok. So is any arm64 platform actually using these devices? If these
devices are mostly used by 32bit x86 platforms, optimizing them for
arm64 doesn't make any sense.
Possibly the patches are still good for x86 also, but that needs to be
proven.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v1, TRIVIAL] Fix pxafb nonstd field documentation and add errata info
From: Tomi Valkeinen @ 2015-08-21 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55D63391.3080403@tul.cz>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On 20/08/15 23:07, Petr Cvek wrote:
> Dne 20.8.2015 v 12:55 Tomi Valkeinen napsal(a):
>>
>>
>> On 08/08/15 21:20, Petr Cvek wrote:
>>
>>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>>> index 2d98de5..8f485ec 100644
>>> --- a/drivers/video/fbdev/Kconfig
>>> +++ b/drivers/video/fbdev/Kconfig
>>> @@ -1893,6 +1893,11 @@ config FB_PXA_OVERLAY
>>> bool "Support PXA27x/PXA3xx Overlay(s) as framebuffer"
>>> default n
>>> depends on FB_PXA && (PXA27x || PXA3xx)
>>> + ---help---
>>> + Using the overlay 2 and YUV420 mode on a PXA27x C0 chip revision will
>>> + hang the LCD until the next SoC restart (errata E24).
>>
>> Shouldn't the driver handle this? It should not allow the combination to
>> be used.
>>
>> Tomi
>>
>
> Probably, but I don't know which revisions are OK and which are not. Errata document:
>
> Marvell® PXA270M Processor Specification Update
> MV-S900957-00
>
> has only 3 revisions, but PXA Manual lists 6 (2.2.5.1 Processor ID Register) and one revision from errata is not shown in my PXA Manual. I can exclude mine revision (from "system_rev" variable), but there should be some warning somewhere in configuration.
No, configuration or kernel docs is not the right place for this. The
user is not going to see that. And a single kernel image is supposed to
run on different soc/board versions, so you can't do selections like
this in the kernel config.
The driver should detect the bad revision, and then apply the
workaround, or if that's not possible, refuse the use of the
configuration that leads to the HW bug. Or if even that's not possible,
the driver should print a warning when starting, so that the user is
able to see it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: yalin wang @ 2015-08-21 7:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <55D6C812.6080400@ti.com>
> On Aug 21, 2015, at 14:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
>
>
> On 20/08/15 14:30, yalin wang wrote:
>>
>>> On Aug 20, 2015, at 19:02, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>
>>>
>>> On 10/08/15 13:12, yalin wang wrote:
>>>> This change to use swab32(bitrev32()) to implement reverse_order()
>>>> function, have better performance on some platforms.
>>>
>>> Which platforms? Presuming you tested this, roughly how much better
>>> performance? If you didn't, how do you know it's faster?
>>
>> i investigate on arm64 platforms:
>
> Ok. So is any arm64 platform actually using these devices? If these
> devices are mostly used by 32bit x86 platforms, optimizing them for
> arm64 doesn't make any sense.
>
> Possibly the patches are still good for x86 also, but that needs to be
> proven.
>
not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
i compile by test :
use the patch:
use swab32(bitrev32()):
2775: 0f b6 d0 movzbl %al,%edx
2778: 0f b6 c4 movzbl %ah,%eax
277b: 0f b6 92 00 00 00 00 movzbl 0x0(%rdx),%edx
2782: 0f b6 80 00 00 00 00 movzbl 0x0(%rax),%eax
2789: c1 e2 08 shl $0x8,%edx
278c: 09 d0 or %edx,%eax
278e: 0f b6 d5 movzbl %ch,%edx
2791: 0f b6 c9 movzbl %cl,%ecx
2794: 0f b6 89 00 00 00 00 movzbl 0x0(%rcx),%ecx
279b: 0f b6 92 00 00 00 00 movzbl 0x0(%rdx),%edx
27a2: 0f b7 c0 movzwl %ax,%eax
27a5: c1 e1 08 shl $0x8,%ecx
27a8: 09 ca or %ecx,%edx
27aa: c1 e2 10 shl $0x10,%edx
27ad: 09 d0 or %edx,%eax
27af: 45 85 ff test %r15d,%r15d
27b2: 0f c8 bswap %eax
4 memory access instructions,
without the patch:
use
do { \
- u8 *a = (u8 *)(l); \
- a[0] = bitrev8(a[0]); \
- a[1] = bitrev8(a[1]); \
- a[2] = bitrev8(a[2]); \
- a[3] = bitrev8(a[3]); \
-} while(0)
277b: 45 0f b6 80 00 00 00 movzbl 0x0(%r8),%r8d
2782: 00
2783: c1 ee 10 shr $0x10,%esi
2786: 89 f2 mov %esi,%edx
2788: 0f b6 f4 movzbl %ah,%esi
278b: c1 e8 18 shr $0x18,%eax
278e: 0f b6 d2 movzbl %dl,%edx
2791: 48 98 cltq
2793: 45 85 ed test %r13d,%r13d
2796: 0f b6 92 00 00 00 00 movzbl 0x0(%rdx),%edx
279d: 0f b6 80 00 00 00 00 movzbl 0x0(%rax),%eax
27a4: 44 88 85 54 ff ff ff mov %r8b,-0xac(%rbp)
27ab: 44 0f b6 86 00 00 00 movzbl 0x0(%rsi),%r8d
27b2: 00
27b3: 88 95 56 ff ff ff mov %dl,-0xaa(%rbp)
27b9: 88 85 57 ff ff ff mov %al,-0xa9(%rbp)
27bf: 44 88 85 55 ff ff ff mov %r8b,-0xab(%rbp)
6 memory access instructions, and generate more code that the patch .
because the original code use byte access 4 times , i don’t
think have better performance. :)
Thanks
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Tomi Valkeinen @ 2015-08-21 8:01 UTC (permalink / raw)
To: yalin wang; +Cc: adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <4DCC50F3-9B6D-4A3A-9693-E7A7196564A8@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On 21/08/15 10:46, yalin wang wrote:
>>> i investigate on arm64 platforms:
>>
>> Ok. So is any arm64 platform actually using these devices? If these
>> devices are mostly used by 32bit x86 platforms, optimizing them for
>> arm64 doesn't make any sense.
>>
>> Possibly the patches are still good for x86 also, but that needs to be
>> proven.
>>
> not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
> i compile by test :
For old drivers i386 may be more relevant than x86_64.
So you don't have the actual HW?
These kind of optimizations should have some real world measurements,
not just compiling, looking at the assembly and guessing whether it's
faster or not.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: omapdss: Division by zero in kernel
From: Tomi Valkeinen @ 2015-08-21 8:42 UTC (permalink / raw)
To: Pali Rohár, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <201507241803.42891@pali>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On 24/07/15 19:03, Pali Rohár wrote:
> Hello,
>
> when on N900 (real HW or qemu) I run this command
>
> / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
>
> then kernel crash with this error message
>
> / # [ 29.904113] Division by zero in kernel.
The problem is that fb console uses the kernel mmapped framebuffer, but
omapfb is not aware of the fb console. So the above commands free the
framebuffer, as omapfb thinks no one is using it, and then fb console
tries to touch the fb.
omapfb tracks mmaps from userspace, and refuses to free a fb it it's
mmapped.
I don't know how to fix it straight away. Maybe there's a way for omapfb
to check if the fbcon uses the fb in question, and if so, refuses to
release/resize the memory.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-08-21 8:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, Jyri Sarha, linux-omap,
linux-fbdev, linux-kernel, Pavel Machek, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <55D6E466.5060706@ti.com>
On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:
>
>
> On 24/07/15 19:03, Pali Rohár wrote:
> > Hello,
> >
> > when on N900 (real HW or qemu) I run this command
> >
> > / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
> >
> > then kernel crash with this error message
> >
> > / # [ 29.904113] Division by zero in kernel.
>
Hi! Thanks for explaining.
> The problem is that fb console uses the kernel mmapped framebuffer, but
> omapfb is not aware of the fb console. So the above commands free the
> framebuffer, as omapfb thinks no one is using it, and then fb console
> tries to touch the fb.
>
What about refusing those calls from fb console? So fb console will not
know about this problem and omapfb will just ignore drawn functions?
> omapfb tracks mmaps from userspace, and refuses to free a fb it it's
> mmapped.
>
> I don't know how to fix it straight away. Maybe there's a way for omapfb
> to check if the fbcon uses the fb in question, and if so, refuses to
> release/resize the memory.
>
> Tomi
>
Maemo userspace (on Nokia N900) uses above commands to initialize
graphic and Xserver. So it would be nice if disabling framebuffer would
work even if fbcon.ko is loaded (or compiled directly into zImage).
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [patch] fbdev: fix snprintf() limit in show_bl_curve()
From: Dan Carpenter @ 2015-08-21 8:53 UTC (permalink / raw)
To: linux-fbdev
The limit should be "PAGE_SIZE - len" instead of PAGE_SIZE.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 60c3f0a..827098d 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -485,7 +485,7 @@ static ssize_t show_bl_curve(struct device *device,
mutex_lock(&fb_info->bl_curve_mutex);
for (i = 0; i < FB_BACKLIGHT_LEVELS; i += 8)
- len += snprintf(&buf[len], PAGE_SIZE, "%8ph\n",
+ len += snprintf(&buf[len], PAGE_SIZE - len, "%8ph\n",
fb_info->bl_curve + i);
mutex_unlock(&fb_info->bl_curve_mutex);
^ permalink raw reply related
* Re: omapdss: Division by zero in kernel
From: Tomi Valkeinen @ 2015-08-21 9:17 UTC (permalink / raw)
To: Pali Rohár
Cc: Jean-Christophe Plagniol-Villard, Jyri Sarha, linux-omap,
linux-fbdev, linux-kernel, Pavel Machek, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <20150821084807.GD27391@pali>
[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]
On 21/08/15 11:48, Pali Rohár wrote:
> On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:
>>
>>
>> On 24/07/15 19:03, Pali Rohár wrote:
>>> Hello,
>>>
>>> when on N900 (real HW or qemu) I run this command
>>>
>>> / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
>>>
>>> then kernel crash with this error message
>>>
>>> / # [ 29.904113] Division by zero in kernel.
>>
>
> Hi! Thanks for explaining.
>
>> The problem is that fb console uses the kernel mmapped framebuffer, but
>> omapfb is not aware of the fb console. So the above commands free the
>> framebuffer, as omapfb thinks no one is using it, and then fb console
>> tries to touch the fb.
>>
>
> What about refusing those calls from fb console? So fb console will not
> know about this problem and omapfb will just ignore drawn functions?
Hmm, I'm not sure I understand what you mean... omapfb is not drawing
anything, fbcon is doing the drawing independently to the fb. And the fb
suddenly disappears without fbcon realizing that.
>> omapfb tracks mmaps from userspace, and refuses to free a fb it it's
>> mmapped.
>>
>> I don't know how to fix it straight away. Maybe there's a way for omapfb
>> to check if the fbcon uses the fb in question, and if so, refuses to
>> release/resize the memory.
>>
>> Tomi
>>
>
> Maemo userspace (on Nokia N900) uses above commands to initialize
> graphic and Xserver. So it would be nice if disabling framebuffer would
> work even if fbcon.ko is loaded (or compiled directly into zImage).
Ok. And N900 has fbcon enabled? I wonder how it survives...
fbcon can be unbound from userspace with something like:
echo 0 > /sys/class/vtconsole/vtcon1/bind
After that I think the memory can be freed.
But obviously the kernel should not crash here, no question about that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] fbdev: fix snprintf() limit in show_bl_curve()
From: Andy Shevchenko @ 2015-08-21 9:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150821085302.GE25369@mwanda>
On Fri, 2015-08-21 at 11:53 +0300, Dan Carpenter wrote:
> The limit should be "PAGE_SIZE - len" instead of PAGE_SIZE.
>
Besides that was in the original code, the problem still might happen
when FB_BACKLIGHT_LEVELS is set to 171+ since snprintf() returns
desired length. I suppose you would change this to check len on each
iteration or change to scnprintf() if I get it correct.
> diff --git a/drivers/video/fbdev/core/fbsysfs.c
> b/drivers/video/fbdev/core/fbsysfs.c
> index 60c3f0a..827098d 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -485,7 +485,7 @@ static ssize_t show_bl_curve(struct device
> *device,
>
> mutex_lock(&fb_info->bl_curve_mutex);
> for (i = 0; i < FB_BACKLIGHT_LEVELS; i += 8)
> - len += snprintf(&buf[len], PAGE_SIZE, "%8ph\n",
> + len += snprintf(&buf[len], PAGE_SIZE - len,
> "%8ph\n",
> fb_info->bl_curve + i);
> mutex_unlock(&fb_info->bl_curve_mutex);
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [patch] fbdev: fix snprintf() limit in show_bl_curve()
From: Dan Carpenter @ 2015-08-21 9:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150821085302.GE25369@mwanda>
On Fri, Aug 21, 2015 at 12:22:03PM +0300, Andy Shevchenko wrote:
> On Fri, 2015-08-21 at 11:53 +0300, Dan Carpenter wrote:
> > The limit should be "PAGE_SIZE - len" instead of PAGE_SIZE.
> >
>
> Besides that was in the original code, the problem still might happen
> when FB_BACKLIGHT_LEVELS is set to 171+ since snprintf() returns
> desired length. I suppose you would change this to check len on each
> iteration or change to scnprintf() if I get it correct.
>
Yeah, you're right.
If you pass a negative size to snprintf() it won't overflow, but it will
print an error. I will send a v2 and change it to scnprintf(). I don't
think we will have 171 levels so it's not worth adding the check?
regards,
dan carpenter
^ permalink raw reply
* Re: [patch] fbdev: fix snprintf() limit in show_bl_curve()
From: Andy Shevchenko @ 2015-08-21 11:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150821085302.GE25369@mwanda>
On Fri, 2015-08-21 at 12:53 +0300, Dan Carpenter wrote:
> On Fri, Aug 21, 2015 at 12:22:03PM +0300, Andy Shevchenko wrote:
> > On Fri, 2015-08-21 at 11:53 +0300, Dan Carpenter wrote:
> > > The limit should be "PAGE_SIZE - len" instead of PAGE_SIZE.
> > >
> >
> > Besides that was in the original code, the problem still might
> > happen
> > when FB_BACKLIGHT_LEVELS is set to 171+ since snprintf() returns
> > desired length. I suppose you would change this to check len on
> > each
> > iteration or change to scnprintf() if I get it correct.
> >
>
> Yeah, you're right.
>
> If you pass a negative size to snprintf() it won't overflow, but it
> will
> print an error. I will send a v2 and change it to scnprintf(). I
> don't
> think we will have 171 levels so it's not worth adding the check?
I think there is no need to check for that. Especially it might be
changed in the future (if, for example, they decide to have 16 levels
per line instead of 8).
>
> regards,
> dan carpenter
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Afzal Mohammed @ 2015-08-22 7:53 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: yalin wang, adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <55D6DAE5.20304@ti.com>
Hi,
On Fri, Aug 21, 2015 at 11:01:41AM +0300, Tomi Valkeinen wrote:
> >> Possibly the patches are still good for x86 also, but that needs to be
> >> proven.
> >>
> > not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
> > i compile by test :
>
> For old drivers i386 may be more relevant than x86_64.
It seems asm bit reversal is supported in Kernel on arm & arm64 only,
not sure whether any other arch even provide asm bit reversal
instruction.
> These kind of optimizations should have some real world measurements,
Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
reversal as compared to doing it in C was taking 1 cycle as opposed to
~225 cycles!, of course writing optimized C could have made it fare
better, but still would reach no-way near asm bit reversal.
Regards
Afzal
^ permalink raw reply
* halo
From: barr lewis @ 2015-08-22 11:38 UTC (permalink / raw)
let us talk
^ permalink raw reply
* [PATCH 00/11] fix error return code
From: Julia Lawall @ 2015-08-23 0:11 UTC (permalink / raw)
To: linux-samsung-soc
Cc: kernel-janitors, linux-fbdev, linux-arm-kernel, linux-kernel,
linux-omap, linux-mmc, netdev, dri-devel, linux-input, linux-gpio
The complate semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@ok exists@
identifier f,ret,i;
expression e;
constant c;
@@
// identify a function that returns a negative return value at least once.
f(...) {
... when any
(
return -c@i;
|
ret = -c@i;
... when != ret = e
return ret;
|
if (ret < 0) { ... return ret; }
)
... when any
}
@r exists@
identifier ret,ok.f,fn;
expression e1,e2,e3,e4,e5,e6,x;
statement S,S1;
position p1,p2,p3;
@@
// identify a case where the return variable is set to a non-negative value
// and then returned in error-handling code
f(...) {
... when any
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != \(ret = e1\|ret++\|ret--\|ret+á\|ret-á\)
when != &ret
when any
(
if (<+... ret = e5 ...+>) S1
|
if (<+... &ret ...+>) S1
|
if@p2(<+...x = fn(...)...+>)
{
... when != ret = e6
when forall
return@p3 ret;
}
|
break;
|
x = fn(...)
... when != \(ret = e4\|ret++\|ret--\|ret+ä\|ret-ä\)
when != &ret
(
if (<+... ret = e3 ...+>) S
|
if (<+... &ret ...+>) S
|
if@p2(<+...\(x != 0\|x < 0\|x = NULL\|IS_ERR(x)\)...+>)
{
... when != ret = e2
when forall
return@p3 ret;
}
)
)
... when any
}
@printer depends on r@
position p;
identifier ok.f,pr;
constant char [] c;
@@
f(...) { <...pr@p(...,c,...)...> }
@bad0 exists@
identifier r.ret,ok.f,g != {ERR_PTR,IS_ERR};
position p != printer.p;
@@
f(...) { ... when any
g@p(...,ret,...)
... when any
}
@bad depends on !bad0 exists@
position r.p1,r.p2;
statement S1,S2;
identifier r.ret;
expression e1;
@@
// ignore the above if there is some path where the variable is set to
// something else
(
if@p1 (\(ret < 0\|ret != 0\)) S1
|
ret@p1 = 0
)
... when any
\(ret = e1\|ret++\|ret--\|ret+á\|ret-á\|&ret\)
... when any
if@p2(...) S2
@bad1 depends on !bad0 && !bad exists@
position r.p2;
statement S2;
identifier r.ret;
expression e1;
constant c;
@@
ret = -c
... when != \(ret = e1\|ret++\|ret--\|ret+á\|ret-á\)
when != &ret
when any
if@p2(...) S2
@bad2 depends on !bad0 && !bad && !bad1 exists@
position r.p1,r.p2;
identifier r.ret;
expression e1;
statement S2;
constant c;
@@
// likewise ignore it if there has been an intervening return
ret@p1 = 0
... when != if (...) { ... ret = e1 ... return ret; }
when != if (...) { ... return -c; }
when any
if@p2(...) S2
@script:python depends on !bad0 && !bad && !bad1 && !bad2@
p1 << r.p1;
p2 << r.p2;
p3 << r.p3;
@@
cocci.print_main("",p1)
cocci.print_secs("",p2)
cocci.print_secs("",p3)
// </smpl>
^ permalink raw reply
* [PATCH 04/11] fbdev: ssd1307fb: fix error return code
From: Julia Lawall @ 2015-08-23 0:11 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, Tomi Valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1440288682-12732-1-git-send-email-Julia.Lawall@lip6.fr>
Propagate error code on failure. Also changed %ld to %d in dev_err to use
ret variable rather than putting two calls to PTR_ERR.
A simplified version of the semantic match that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/ssd1307fb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3e153c0..1611215 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -656,8 +656,9 @@ static int ssd1307fb_probe(struct i2c_client *client,
bl = backlight_device_register(bl_name, &client->dev, par,
&ssd1307fb_bl_ops, NULL);
if (IS_ERR(bl)) {
- dev_err(&client->dev, "unable to register backlight device: %ld\n",
- PTR_ERR(bl));
+ ret = PTR_ERR(bl);
+ dev_err(&client->dev, "unable to register backlight device: %d\n",
+ ret);
goto bl_init_error;
}
^ permalink raw reply related
* [RFC v6 12/25] powerpc: Cleanup nvram includes
From: Finn Thain @ 2015-08-23 10:41 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150823104129.517600532@telegraphics.com.au>
The nvram_read_byte() and nvram_write_byte() definitions in asm/nvram.h
duplicate those in linux/nvram.h. Get rid of the former to prepare for
adoption of struct arch_nvram_ops (which is defined in linux/nvram.h for
general use).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Changes since v4:
- Fix possible git bisect build failure with CONFIG_PPC_PMAC=n.
---
arch/powerpc/include/asm/nvram.h | 3 ---
arch/powerpc/kernel/setup_32.c | 1 +
drivers/char/generic_nvram.c | 1 +
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
4 files changed, 3 insertions(+), 4 deletions(-)
Index: linux/arch/powerpc/include/asm/nvram.h
=================================--- linux.orig/arch/powerpc/include/asm/nvram.h 2015-08-23 20:40:53.000000000 +1000
+++ linux/arch/powerpc/include/asm/nvram.h 2015-08-23 20:41:07.000000000 +1000
@@ -101,7 +101,4 @@ extern int nvram_write_os_partition(stru
/* Determine NVRAM size */
extern ssize_t nvram_get_size(void);
-/* Normal access to NVRAM */
-extern unsigned char nvram_read_byte(int i);
-extern void nvram_write_byte(unsigned char c, int i);
#endif /* _ASM_POWERPC_NVRAM_H */
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-08-23 20:41:07.000000000 +1000
@@ -16,6 +16,7 @@
#include <linux/cpu.h>
#include <linux/console.h>
#include <linux/memblock.h>
+#include <linux/nvram.h>
#include <asm/io.h>
#include <asm/prom.h>
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:41:07.000000000 +1000
@@ -111,12 +111,12 @@
#include "matroxfb_g450.h"
#include <linux/matroxfb.h>
#include <linux/interrupt.h>
+#include <linux/nvram.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
#ifdef CONFIG_PPC_PMAC
#include <asm/machdep.h>
-unsigned char nvram_read_byte(int);
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
#endif
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-08-23 20:41:07.000000000 +1000
@@ -20,6 +20,7 @@
#include <linux/fcntl.h>
#include <linux/init.h>
#include <linux/mutex.h>
+#include <linux/nvram.h>
#include <asm/uaccess.h>
#include <asm/nvram.h>
#ifdef CONFIG_PPC_PMAC
^ permalink raw reply
* [RFC v6 16/25] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 and CONFIG_PPC_PMAC
From: Finn Thain @ 2015-08-23 10:41 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150823104129.517600532@telegraphics.com.au>
This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.
Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs,
there is no NR partition and MacOS stores display mode settings in PRAM**.
Early model Macs are the ones most likely to benefit from these settings,
since they are more likely to have one display: a fixed-frequency monitor
connected to the built-in framebuffer device. Moreover, a single NV_CMODE
value and a single NV_VMODE value provide for only one display.
The NV_CMODE and NV_VMODE constants are apparently offsets into the NR
partition for Old World machines and not New World, which also suggests
that these defaults are not useful on later models.
All this argues for limiting NVRAM support in PowerMac fbdev drivers to
PPC32 and indeed this is already the case, since CONFIG_NVRAM cannot be
enabled on PPC64 at present.
For matroxfb, make the CONFIG_PPC32 condition explicit. That way the
driver won't crash on PPC64 when CONFIG_NVRAM becomes available there.
In imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure,
since PPC64 does not implement nvram_read_byte(). Also add a missing
machine_is(powermac) check. Change the inconsistent CONFIG_PPC dependency
and the matching #ifdef tests to CONFIG_PPC_PMAC. Drop unused #includes.
In valkyriefb, for clarity and consistency with the other PowerMac fbdev
drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a
bogus comment regarding PRAM.
* See GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".
** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/imsttfb.c | 13 +++++--------
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/valkyriefb.c | 14 ++++++--------
4 files changed, 13 insertions(+), 18 deletions(-)
Index: linux/drivers/video/fbdev/Kconfig
=================================--- linux.orig/drivers/video/fbdev/Kconfig 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/Kconfig 2015-08-23 20:41:13.000000000 +1000
@@ -544,7 +544,7 @@ config FB_IMSTT
bool "IMS Twin Turbo display support"
depends on (FB = y) && PCI
select FB_CFB_IMAGEBLIT
- select FB_MACMODES if PPC
+ select FB_MACMODES if PPC_PMAC
help
The IMS Twin Turbo is a PCI-based frame buffer card bundled with
many Macintosh and compatible computers.
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-08-23 20:41:13.000000000 +1000
@@ -30,10 +30,8 @@
#include <asm/io.h>
#include <linux/uaccess.h>
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
#include <linux/nvram.h>
-#include <asm/prom.h>
-#include <asm/pci-bridge.h>
#include "macmodes.h"
#endif
@@ -328,14 +326,13 @@ enum {
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
static int inverse = 0;
static char fontname[40] __initdata = { 0 };
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
static signed char init_vmode = -1, init_cmode = -1;
#endif
@@ -1391,8 +1388,8 @@ static void init_imstt(struct fb_info *i
}
}
-#if USE_NV_MODES && defined(CONFIG_PPC32)
- {
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
+ if (machine_is(powermac)) {
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
@@ -1566,7 +1563,7 @@ imsttfb_setup(char *options)
inverse = 1;
fb_invert_cmaps();
}
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
else if (!strncmp(this_opt, "vmode:", 6)) {
int vmode = simple_strtoul(this_opt+6, NULL, 0);
if (vmode > 0 && vmode <= VMODE_MAX)
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:41:07.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:41:13.000000000 +1000
@@ -1876,7 +1876,7 @@ static int initMatrox2(struct matrox_fb_
struct fb_var_screeninfo var;
if (default_vmode <= 0 || default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-08-23 20:41:13.000000000 +1000
@@ -65,14 +65,12 @@
#include "macmodes.h"
#include "valkyriefb.h"
-#ifdef CONFIG_MAC
-/* We don't yet have functions to read the PRAM... perhaps we can
- adapt them from the PPC code? */
-static int default_vmode = VMODE_CHOOSE;
-static int default_cmode = CMODE_8;
-#else
+#ifdef CONFIG_PPC_PMAC
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
+#else
+static int default_vmode = VMODE_CHOOSE;
+static int default_cmode = CMODE_8;
#endif
struct fb_par_valkyrie {
@@ -285,7 +283,7 @@ static void __init valkyrie_choose_mode(
printk(KERN_INFO "Monitor sense value = 0x%x\n", p->sense);
/* Try to pick a video mode out of NVRAM if we have one. */
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
default_vmode = nvram_read_byte(NV_VMODE);
if (default_vmode <= 0
@@ -298,7 +296,7 @@ static void __init valkyrie_choose_mode(
default_vmode = mac_map_monitor_sense(p->sense);
if (!valkyrie_reg_init[default_vmode - 1])
default_vmode = VMODE_640_480_67;
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
^ permalink raw reply
* [RFC v6 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_wri
From: Finn Thain @ 2015-08-23 10:41 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150823104129.517600532@telegraphics.com.au>
Make use of arch_nvram_ops in device drivers so that the nvram_* function
exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Changed since v4:
- Split off the CONFIG_PPC32, CONFIG_PPC_PMAC and CONFIG_NVRAM tests into
a separate patch.
---
arch/powerpc/kernel/setup_32.c | 8 ++++----
drivers/char/generic_nvram.c | 4 ++--
drivers/video/fbdev/controlfb.c | 4 ++--
drivers/video/fbdev/imsttfb.c | 4 ++--
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/platinumfb.c | 4 ++--
drivers/video/fbdev/valkyriefb.c | 4 ++--
7 files changed, 15 insertions(+), 15 deletions(-)
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-08-23 20:41:11.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-08-23 20:41:14.000000000 +1000
@@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-08-23 20:41:11.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-08-23 20:41:14.000000000 +1000
@@ -63,7 +63,7 @@ static ssize_t read_nvram(struct file *f
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
return -EFAULT;
*ppos = i;
return p - buf;
@@ -83,7 +83,7 @@ static ssize_t write_nvram(struct file *
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
Index: linux/drivers/video/fbdev/controlfb.c
=================================--- linux.orig/drivers/video/fbdev/controlfb.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/controlfb.c 2015-08-23 20:41:14.000000000 +1000
@@ -415,7 +415,7 @@ static int __init init_control(struct fb
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -423,7 +423,7 @@ static int __init init_control(struct fb
cmodeÞfault_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode = VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-08-23 20:41:13.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-08-23 20:41:14.000000000 +1000
@@ -1393,12 +1393,12 @@ static void init_imstt(struct fb_info *i
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode <= 0 || vmode > VMODE_MAX)
vmode = VMODE_640_480_67;
}
if (cmode = -1) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if (cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
}
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:41:13.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-08-23 20:41:14.000000000 +1000
@@ -1878,7 +1878,7 @@ static int initMatrox2(struct matrox_fb_
default_vmode = VMODE_640_480_60;
#if defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/platinumfb.c
=================================--- linux.orig/drivers/video/fbdev/platinumfb.c 2015-08-23 20:40:53.000000000 +1000
+++ linux/drivers/video/fbdev/platinumfb.c 2015-08-23 20:41:14.000000000 +1000
@@ -349,7 +349,7 @@ static int platinum_init_fb(struct fb_in
printk(KERN_INFO "platinumfb: Monitor sense value = 0x%x, ", sense);
if (default_vmode = VMODE_NVRAM) {
#ifdef CONFIG_NVRAM
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0 || default_vmode > VMODE_MAX ||
!platinum_reg_init[default_vmode-1])
#endif
@@ -362,7 +362,7 @@ static int platinum_init_fb(struct fb_in
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-08-23 20:41:13.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-08-23 20:41:14.000000000 +1000
@@ -285,7 +285,7 @@ static void __init valkyrie_choose_mode(
/* Try to pick a video mode out of NVRAM if we have one. */
#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0
|| default_vmode > VMODE_MAX
|| !valkyrie_reg_init[default_vmode - 1])
@@ -298,7 +298,7 @@ static void __init valkyrie_choose_mode(
default_vmode = VMODE_640_480_67;
#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
/*
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: yalin wang @ 2015-08-24 8:31 UTC (permalink / raw)
To: Afzal Mohammed; +Cc: Tomi Valkeinen, adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <20150822075310.GA2337@afzalpc>
> On Aug 22, 2015, at 15:53, Afzal Mohammed <afzal.mohd.ma@gmail.com> wrote:
>
> Hi,
>
> On Fri, Aug 21, 2015 at 11:01:41AM +0300, Tomi Valkeinen wrote:
>
>>>> Possibly the patches are still good for x86 also, but that needs to be
>>>> proven.
>>>>
>>> not exactly, because x86_64 don’t have hardware instruction to do rbit OP,
>>> i compile by test :
>>
>> For old drivers i386 may be more relevant than x86_64.
>
> It seems asm bit reversal is supported in Kernel on arm & arm64 only,
> not sure whether any other arch even provide asm bit reversal
> instruction.
i only submit the bit reverse patch for arm / arm64 arch,
i am not sure if there are some other arch also have hard ware bit reverse
instructions, need arch maintainers to submit if their arch also have these hard
ware instructions . :)
>
>> These kind of optimizations should have some real world measurements,
>
> Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
> reversal as compared to doing it in C was taking 1 cycle as opposed to
> ~225 cycles!, of course writing optimized C could have made it fare
> better, but still would reach no-way near asm bit reversal.
>
^ permalink raw reply
* Re: [RFC] fbdev/riva:change to use generice function to implement reverse_order()
From: Afzal Mohammed @ 2015-08-24 13:53 UTC (permalink / raw)
To: yalin wang; +Cc: Tomi Valkeinen, adaplas, plagnioj, linux-fbdev, open list
In-Reply-To: <F9B74F97-EF3F-4051-B54B-B6CDD2946374@gmail.com>
Hi,
On Mon, Aug 24, 2015 at 04:31:13PM +0800, yalin wang wrote:
>
> i only submit the bit reverse patch for arm / arm64 arch,
yes, saw later git blaming it on you :)
> > Not for this case, but once measured on ARM, iirc, a 32-bit asm bit
> > reversal as compared to doing it in C was taking 1 cycle as opposed to
> > ~225 cycles!, of course writing optimized C could have made it fare
> > better, but still would reach no-way near asm bit reversal.
The above measurement was done not in Linux, rather on a baremetal
code, but seeing the efficient Kernel C implementation, realized that
the gain would not be that much, it would be good to know if there are
measurements for Kernel bitreversal in C & asm (on supported arch)
Regards
afzal
^ 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