* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-23 13:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
> -----Original Message-----
> From: daniel.vetter@ffwll.ch [mailto:daniel.vetter@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, May 23, 2013 8:56 PM
> To: Inki Dae
> Cc: Rob Clark; linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham;
> YoungJun Cho; linux-arm-kernel@lists.infradead.org; linux-
> media@vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
>
> On Tue, May 21, 2013 at 11:22 AM, Inki Dae <inki.dae@samsung.com> wrote:
> >> -----Original Message-----
> >> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> >> Vetter
> >> Sent: Tuesday, May 21, 2013 4:45 PM
> >> To: Inki Dae
> >> Cc: 'Daniel Vetter'; 'Rob Clark'; 'linux-fbdev'; 'DRI mailing list';
> >> 'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> >> kernel@lists.infradead.org; linux-media@vger.kernel.org
> >> Subject: Re: Introduce a new helper framework for buffer
> synchronization
> >>
> >> On Tue, May 21, 2013 at 04:03:06PM +0900, Inki Dae wrote:
> >> > > - Integration of fence syncing into dma_buf. Imo we should have a
> >> > > per-attachment mode which decides whether map/unmap (and the new
> >> sync)
> >> > > should wait for fences or whether the driver takes care of
> syncing
> >> > > through the new fence framework itself (for direct hw sync).
> >> >
> >> > I think it's a good idea to have per-attachment mode for buffer sync.
> >> But
> >> > I'd like to say we make sure what is the purpose of map
> >> > (dma_buf_map_attachment)first. This interface is used to get a sgt;
> >> > containing pages to physical memory region, and map that region with
> >> > device's iommu table. The important thing is that this interface is
> >> called
> >> > just one time when user wants to share an allocated buffer with dma.
> But
> >> cpu
> >> > will try to access the buffer every time as long as it wants.
> Therefore,
> >> we
> >> > need cache control every time cpu and dma access the shared buffer:
> >> cache
> >> > clean when cpu goes to dma and cache invalidate when dma goes to cpu.
> >> That
> >> > is why I added new interfaces, DMA_BUF_GET_FENCE and
> DMA_BUF_PUT_FENCE,
> >> to
> >> > dma buf framework. Of course, Those are ugly so we need a better way:
> I
> >> just
> >> > wanted to show you that in such way, we can synchronize the shared
> >> buffer
> >> > between cpu and dma. By any chance, is there any way that kernel can
> be
> >> > aware of when cpu accesses the shared buffer or is there any point I
> >> didn't
> >> > catch up?
> >>
> >> Well dma_buf_map/unmap_attachment should also flush/invalidate any
> caches,
> >> and with the current dma_buf spec those two functions are the _only_
> means
> >
> > I know that dma buf exporter should make sure that cache
> clean/invalidate
> > are done when dma_buf_map/unmap_attachement is called. For this, already
> we
> > do so. However, this function is called when dma buf import is requested
> by
> > user to map a dmabuf fd with dma. This means that
> dma_buf_map_attachement()
> > is called ONCE when user wants to share the dmabuf fd with dma.
Actually,
> in
> > case of exynos drm, dma_map_sg_attrs(), performing cache operation
> > internally, is called when dmabuf import is requested by user.
> >
> >> you have to do so. Which strictly means that if you interleave device
> dma
> >> and cpu acccess you need to unmap/map every time.
> >>
> >> Which is obviously horribly inefficient, but a known gap in the dma_buf
> >
> > Right, and also this has big overhead.
> >
> >> interface. Hence why I proposed to add dma_buf_sync_attachment similar
> to
> >> dma_sync_single_for_device:
> >>
> >> /**
> >> * dma_buf_sync_sg_attachment - sync caches for dma access
> >> * @attach: dma-buf attachment to sync
> >> * @sgt: the sg table to sync (returned by dma_buf_map_attachement)
> >> * @direction: dma direction to sync for
> >> *
> >> * This function synchronizes caches for device dma through the given
> >> * dma-buf attachment when interleaving dma from different devices and
> the
> >> * cpu. Other device dma needs to be synced also by calls to this
> >> * function (or a pair of dma_buf_map/unmap_attachment calls), cpu
> access
> >> * needs to be synced with dma_buf_begin/end_cpu_access.
> >> */
> >> void dma_buf_sync_sg_attachment(struct dma_buf_attachment *attach,
> >> struct sg_table *sgt,
> >> enum dma_data_direction direction)
> >>
> >> Note that "sync" here only means to synchronize caches, not wait for
> any
> >> outstanding fences. This is simply to be consistent with the
> established
> >> lingo of the dma api. How the dma-buf fences fit into this is imo a
> >> different topic, but my idea is that all the cache coherency barriers
> >> (i.e. dma_buf_map/unmap_attachment, dma_buf_sync_sg_attachment and
> >> dma_buf_begin/end_cpu_access) would automatically block for any
> attached
> >> fences (i.e. block for write fences when doing read-only access, block
> for
> >> all fences otherwise).
> >
> > As I mentioned already, kernel can't aware of when cpu accesses a shared
> > buffer: user can access a shared buffer after mmap anytime and the
> shared
> > buffer should be synchronized between cpu and dma. Therefore, the above
> > cache coherency barriers should be called every time cpu and dma tries
> to
> > access a shared buffer, checking before and after of cpu and dma access.
> And
> > exactly, the proposed way do such thing. For this, you can refer to the
> > below link,
> >
> > http://www.mail-archive.com/linux-media@vger.kernel.org/msg62124.html
> >
> > My point is that how kernel can aware of when those cache coherency
> barriers
> > should be called to synchronize caches and buffer access between cpu and
> > dma.
> >
> >>
> >> Then we could do a new dma_buf_attach_flags interface for special cases
> >> (might also be useful for other things, similar to the recently added
> >> flags in the dma api for wc/no-kernel-mapping/...). A new flag like
> >> DMA_BUF_ATTACH_NO_AUTOFENCE would then mean that the driver takes care
> of
> >> all
> >> fencing for this attachment and the dma-buf functions should not do the
> >> automagic fence blocking.
> >>
> >> > In Linux kernel, especially embedded system, we had tried to
> implement
> >> > generic interfaces for buffer management; how to allocate a buffer
> and
> >> how
> >> > to share a buffer. As a result, now we have CMA (Contiguous Memory
> >> > Allocator) for buffer allocation, and we have DMA-BUF for buffer
> sharing
> >> > between cpu and dma. And then how to synchronize a buffer between cpu
> >> and
> >> > dma? I think now it's best time to discuss buffer synchronization
> >> mechanism,
> >> > and that is very natural.
> >>
> >> I think it's important to differentiate between the two meanings of
> sync:
> >> - synchronize caches (i.e. cpu cache flushing in most cases)
> >> - and synchronize in-flight dma with fences.
> >>
> >
> > Agree, and I meant that the buffer synchronization mechanism includes
> the
> > above two things. And I think the two things should be addressed
> together.
>
> I'm still confused about what you're trying to achive in the big
> picture here exactly. I think the key point is your statement above
> that the kernel can't know when the cpu access a dma-buf. That's not
> true though:
>
> For userspace mmaps the kernel can shoot down ptes and so prevent
> userspace from accessing a buffer.
In this case, cpu access to user space will incur page fault. However, cpu
accesses user space region after mmap in user mode and every time user
wants. And user needs something before passing a buffer accessed into device
driver and also vice versa.
> Since that's pretty inefficient
> gem/ttm have additional ioctls for cache coherency transitions.
Yes, that's the something, and that's a way now we are using if I understood
surely. User side calls those ioctls for cache coherency between cpu and
dma: cache clean after cpu access and before dma access, and cache
invalidate after dma access and before cpu access. I thought it's better to
control cache in kernel side than user because I had found some Linux based
platforms overuse cache operations. So I thought the best place for it is
the proposed fence helper or similar thing: we would need interfaces to
notify the moment, 'before and after of cpu access', into kernel side. My
proposal is to couple those two things, synchronizing caches and in-flight
dma with fences, in kernel side. With this approach, user doesn't need to
care when dma and cpu access will be started, and when dma and cpu access
will be completed anymore when user wants to access a buffer and share it
with dma. All things, cache coherency and buffer fencing between dma and
cpu, will be done in kernel side.
> dma_buf currently has no support for explicit coherency transitions
> from userpsace, so if pte shootdown is an issue we need to improve
> that.
>
> If I read your proposal correctly you instead suggest to _alway_ flush
> cache before/after each dma. That will _completely_ kill performance
> (been there with i915, trust me).
>
In case of using a cachable mapped buffer and sharing the buffer with dma,
we need to clean cache after cpu access and before dma access, and we need
to invalidate cache after dma access and before cpu access every time. Isn't
that we are doing so now? I have a little knowledge about Desktop world so
there might be my misunderstanding.
Could you please give me advices and more comments if there is my missing
point or misunderstanding?
> For cpu access from kernel space we already have explicit mappings all
> over the place (kmap&friends), so I don't see any issues with
> inserting the relevant begin/end_cpu_access calls just around the cpu
> access. The big exception is the framebuffer layer, but even that has
> the deferred io support. KMS otoh has a nice frontbuffer dirty
> interface to correctly support dumb clients, unfortunately fbcon does
> not (yet) use that.
>
> For these reasons I don't see a need to smash cache coherency and
> fencing into one problem, and hence why I've proposed to tackle each
> of them individually.
I might be really missing some points :)
Thanks,
Inki Dae
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] build some drivers only when compile-testing
From: Ben Hutchings @ 2013-05-23 14:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, jirislaby, linux-kernel, Andrew Morton,
Linus Torvalds, Jeff Mahoney, Alexander Shishkin, linux-usb,
Florian Tobias Schandinat, linux-geode, linux-fbdev,
Richard Cochran, netdev, Keller, Jacob E
In-Reply-To: <20130523022327.GB6159@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 4308 bytes --]
On Wed, 2013-05-22 at 19:23 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> > Some drivers can be built on more platforms than they run on. This
> > causes users and distributors packaging burden when they have to
> > manually deselect some drivers from their allmodconfigs. Or sometimes
> > it is even impossible to disable the drivers without patching the
> > kernel.
> >
> > Introduce a new config option COMPILE_TEST and make all those drivers
> > to depend on the platform they run on, or on the COMPILE_TEST option.
> > Now, when users/distributors choose COMPILE_TEST=n they will not have
> > the drivers in their allmodconfig setups, but developers still can
> > compile-test them with COMPILE_TEST=y.
>
> I understand the urge, and it's getting hard for distros to handle these
> drivers that just don't work on other architectures, but it's really
> valuable to ensure that they build properly, for those of us that don't
> have many/any cross compilers set up.
>
> > Now the drivers where we use this new option:
> > * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
> > processors so it should depend on x86.
> > * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> > * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
> > systems -- which do not actually support the hardware via that
> > method.
>
> This seems ripe to start to get really messy, really quickly. Shouldn't
> "default configs" handle if this "should" be enabled for a platform or
> not, and let the rest of us just build them with no problems?
Debian aims to provide a consistent feature set across all supported
architectures so far as possible, and I would expect other distributions
to do the same. I don't believe anyone is coordinating defconfigs
across architectures to ensure that.
Distributions may also have particular requirements from userland that a
distribution-agnostic defconfig obviously doesn't cover. (Isn't that
why we had the discussion about 'configure for my distribution' some
months back?)
For the driver configuration, what we provide in Debian is closer to
allmodconfig, only with some attempt to exclude those useless drivers.
Dependencies like this would make it easier to do that.
> What problems is this causing you? Are you running out of space in
> kernel packages with drivers that will never be actually used?
On most x86 systems this isn't going to be an issue. But if packages
are built natively (as they are for most distributions) then building
useless drivers for some architecture which doesn't have fast processors
available is a waste of precious resources.
This is particularly bad where the architecture doesn't support generic
kernels that boot on a wide range of machines and therefore we must
build many times over. These unfortunately tend to be among those with
slower processors (ARM[1], MIPS, SH, ...). Currently, Debian's linux
package takes ~48 hours to build for armel (ARM processors without FPU)
- and that's without building many of the PCI drivers we could for those
platforms which have PCI support. So that's a minimum of 2 days to
provide a security update across all architectures[2].
[1] I'm aware that ARM is getting better in this regard and most ARMv7
machines are likely to be supportable by a single kernel image soon.
That doesn't mean the whole problem is solved.
[2] We don't always wait for all builds before releasing/announcing an
update; for example <http://www.debian.org/security/2013/dsa-2669>. But
that's no comfort for those using the slower architecture.
> > +config COMPILE_TEST
> > + bool "Compile also drivers which will not load" if EXPERT
>
> EXPERT is getting to be the "let's hide it here" option, isn't it...
This little detail seems likely to reduce the usefulness of randconfig
as many drivers will become dependent on both EXPERT and COMPILE_TEST
being selected.
> I don't know, if no one else strongly objects, I can be convinced that
> this is needed, but so far, I don't see why it really is, or what this
> is going to help with.
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Stephen Warren @ 2013-05-23 16:27 UTC (permalink / raw)
To: Alexandre Courbot
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, Andrew Morton,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1369296231-26597-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 05/23/2013 02:03 AM, Alexandre Courbot wrote:
> The naming scheme of simplefb's mode is precise enough to allow building
> the mode structure from it instead of using a static list of modes. This
> patch introduces a function that does this. In case exotic modes that
> cannot be represented from their name alone are needed, the static list
> of modes is still available as a backup.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> Stephen, please note that the "r5g6b5" mode initially supported
> by the driver becomes "b5g6r5" with the new function. This is because
> the least significant bits are defined first in the string - this
> makes parsing much easier, notably for modes which do not fill whole
> bytes (e.g. 15 bit modes). I hope this is not a problem - it's probably
> better to do the change now while the driver is still new.
Hmm. searchin Google (and even looking at the VDPAU spec I myself wrote)
does imply that format names like this do typically list the LSBs first.
I guess the problem is that when I decided to change from rgb565 to a
machine-parsable r5g6b5, I didn't think enough to realize that the field
order in the name "rgb565" didn't follow the same convention as when you
write out the fields in the style "r5g6b5"/"b5g6r5":-(
I guess this driver and DT binding are only in linux-next and targeted
at 3.11, and didn't make 3.10, so I'd assert it's probably still OK to
change the DT binding, if this patch also gets into 3.11.
The only two users of it I know are:
a) From U-Boot on the Raspberry Pi, and those patches haven't been
accepted into U-Boot yet.
b) From U-Boot on the Samsung ARM Chromebook yet. I know Olof built a
U-Boot that uses them and it'd linked from the chromiumos.org web pages.
I assume it's not too horrible for him to update them. I don't know how
widely the patch that enables simple-fb in that binary is distributed
though. Olof, care to comment on how much pain it'd be to change?
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> -- format: The format of the framebuffer surface. Valid values are:
> - - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> +- format: The format of the framebuffer surface. Described as a sequence of
> + channel/nbbits pairs, where each pair describes how many bits are used
Change nbbits to bitcount, num-bits, nr-bits?
> + by a given color channel. Value channels are "r" (red), "g" (green),
> + "b" (blue) and "a" (alpha).
I think you'll need "x" too, to represent any gaps/unused bits.
> Channels are listed starting in bit-significance order.
I would explicitly add ", starting from the LSB." to the end there.
Perhaps drop "-significance" too?
> For instance, a format named "r5g6b5" describes
> + a 16-bit format where red is encoded in the 5 less significant bits,
> + green in the 6 following ones, and blue in the 5 last:
> + BBBBBGGG GGGRRRRR
> + ^ ^
> + MSB LSB
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> +static struct simplefb_format *simplefb_parse_format(struct device *dev,
> + const char *str)
> +{
> + struct simplefb_format *format;
> + unsigned int cpt = 0;
What does cpt mean? Something like bit or bitnum or bitindex might be
more descriptive.
> + unsigned int i = 0;
> +
> + format = devm_kzalloc(dev, sizeof(*format), GFP_KERNEL);
> + if (!format)
> + return ERR_PTR(-ENOMEM);
Can we just add some storage into the FB object itself for this, so we
don't need to make a special allocation? The first parameter to
framebuffer_alloc() allows allocating that, although you would have to
rejig the order of probe() a bit to do that:-( Perhaps it's fine as you
wrote it.
> + field->offset = cpt;
> + field->length = c - '0';
What about R10G10B10A2? Something like strtol() is needed here.
> +
> + cpt += field->length;
> + }
> +
> + format->bits_per_pixel = ((cpt + 7) / 8) * 8;
Should this error-check that isn't > 32?
> + if (!params->format || IS_ERR(params->format)) {
That's just saying IS_ERR_OR_NULL(params->format). It'd be better to
pick one thing to represent errors; either NULL or an error-pointer. I
think having simplefb_parse_format() just return NULL on error would be
best; the caller can't really do anything useful with the information
anyway.
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Geert Uytterhoeven @ 2013-05-23 16:57 UTC (permalink / raw)
To: Stephen Warren
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w, Linux Fbdev development list,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Alexandre Courbot,
Andrew Morton
In-Reply-To: <519E438A.9030408-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Thu, May 23, 2013 at 6:27 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> +
>> + cpt += field->length;
>> + }
>> +
>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8;
>
> Should this error-check that isn't > 32?
So pixels can't be larger than 32 bits?
IIRC, some SGI and Sun graphics cards had e.g. 80 bit pixels (incl. Z buffer).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 0/9] Clean up write-combining MTRR addition
From: Andy Lutomirski @ 2013-05-23 18:35 UTC (permalink / raw)
To: linux-kernel, dri-devel, linux-fbdev
Cc: Daniel Vetter, Jerome Glisse, Alex Deucher, Dave Airlie,
Andy Lutomirski
In-Reply-To: <cover.1368485053.git.luto@amacapital.net>
On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> A fair number of drivers (mostly graphics) add write-combining MTRRs.
> Most ignore errors and most add the MTRR even on PAT systems which don't
> need to use MTRRs.
>
> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
> otherwise. (Other architectures, if any, with a similar mechanism could
> implement them.)
That's the path to upstream for this? Should it go through drm-next?
(Sorry for possible noob question -- I've never sent in anything other
than trivial fixes to drm stuff before.)
--Andy
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Stephen Warren @ 2013-05-23 19:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w, Linux Fbdev development list,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Alexandre Courbot,
Andrew Morton
In-Reply-To: <CAMuHMdVs4hy7dWAGxN51XP3YuWBY6rk22Z6tCU+-HujZH4jL2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/23/2013 10:57 AM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 6:27 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> +
>>> + cpt += field->length;
>>> + }
>>> +
>>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8;
>>
>> Should this error-check that isn't > 32?
>
> So pixels can't be larger than 32 bits?
> IIRC, some SGI and Sun graphics cards had e.g. 80 bit pixels (incl. Z buffer).
That's a good point.
Out of curiosity, how does the FB core treat these format definitions?
Are they expected to fit into a 16-/32-/64-/128- bit power-of-two
bit-size, or are they treated as a string of bytes that get serialized
into memory LSB first (or perhaps MSB first on BE systems?)
The difference would be that from a CPU perspective only, if you pack
the RGB components into a u32, then write that to RAM as a u32, then the
in-memory byte-by-byte order is different on different endian systems,
whereas if the FB core treats it as a series of bytes only, then
presumably the in-memory byte-by-byte order is identical irrespective of
host CPU endianness.
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Geert Uytterhoeven @ 2013-05-23 19:42 UTC (permalink / raw)
To: Stephen Warren
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w, Linux Fbdev development list,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Alexandre Courbot,
Andrew Morton
In-Reply-To: <519E6C37.2010706-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Thu, May 23, 2013 at 9:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/23/2013 10:57 AM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 6:27 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> +
>>>> + cpt += field->length;
>>>> + }
>>>> +
>>>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8;
>>>
>>> Should this error-check that isn't > 32?
>>
>> So pixels can't be larger than 32 bits?
>> IIRC, some SGI and Sun graphics cards had e.g. 80 bit pixels (incl. Z buffer).
>
> That's a good point.
>
> Out of curiosity, how does the FB core treat these format definitions?
> Are they expected to fit into a 16-/32-/64-/128- bit power-of-two
> bit-size, or are they treated as a string of bytes that get serialized
> into memory LSB first (or perhaps MSB first on BE systems?)
>
> The difference would be that from a CPU perspective only, if you pack
> the RGB components into a u32, then write that to RAM as a u32, then the
> in-memory byte-by-byte order is different on different endian systems,
> whereas if the FB core treats it as a series of bytes only, then
> presumably the in-memory byte-by-byte order is identical irrespective of
> host CPU endianness.
I don't think any of the current FB drivers support these.
Conceptually, a (packed) frame buffer is just a block of memory,
containing lines
of line_length bytes.
Each line contains xres_virtual pixels, each of bits_per_pixel bits.
As long as bits_per_pixel is an integer multiple of 8, it's
more-or-less well-defined.
We did have issues with endianness on e.g. bits_per_pixel = 4 (2 pixels in
one byte, which order?), bits_per_pixel = 16 (byteswapped RGB565), etc.
If bits_per_pixel is larger than 32, and not an integer multiple of 32,
you indeed can have more of them...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] build some drivers only when compile-testing
From: Rob Landley @ 2013-05-24 4:50 UTC (permalink / raw)
To: Ben Hutchings
Cc: Greg Kroah-Hartman, Jiri Slaby, jirislaby, linux-kernel,
Andrew Morton, Linus Torvalds, Jeff Mahoney, Alexander Shishkin,
linux-usb, Florian Tobias Schandinat, linux-geode, linux-fbdev,
Richard Cochran, netdev, Keller, Jacob E
In-Reply-To: <20130523022327.GB6159@kroah.com>
On 05/23/2013 09:01:40 AM, Ben Hutchings wrote:
> On Wed, 2013-05-22 at 19:23 -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> > > Some drivers can be built on more platforms than they run on. This
> > > causes users and distributors packaging burden when they have to
> > > manually deselect some drivers from their allmodconfigs. Or
> sometimes
> > > it is even impossible to disable the drivers without patching the
> > > kernel.
> > >
> > > Introduce a new config option COMPILE_TEST and make all those
> drivers
> > > to depend on the platform they run on, or on the COMPILE_TEST
> option.
> > > Now, when users/distributors choose COMPILE_TEST=n they will not
> have
> > > the drivers in their allmodconfig setups, but developers still can
> > > compile-test them with COMPILE_TEST=y.
> >
> > I understand the urge, and it's getting hard for distros to handle
> these
> > drivers that just don't work on other architectures, but it's really
> > valuable to ensure that they build properly, for those of us that
> don't
> > have many/any cross compilers set up.
In http://landley.net/aboriginal/bin grab the cross-compiler-*.tar.bz2
tarballs, extract them, add the "bin" subdirectory of each to the
$PATH. Congratulations, you have cross compilers set up. (They're
statically linked and relocatable, so should run just about anywhere.
If they don't, let me know and I'll fix it.)
Example build:
make ARCH=sparc sparc32_defconfig
PATH=/home/landley/simple-cross-compiler-sparc/bin:$PATH \
make ARCH=sparc CROSS_COMPILE=sparc-
Rob
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Alex Courbot @ 2013-05-24 7:30 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Andrew Morton,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <519E438A.9030408-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 05/24/2013 01:27 AM, Stephen Warren wrote:
>> Stephen, please note that the "r5g6b5" mode initially supported
>> by the driver becomes "b5g6r5" with the new function. This is because
>> the least significant bits are defined first in the string - this
>> makes parsing much easier, notably for modes which do not fill whole
>> bytes (e.g. 15 bit modes). I hope this is not a problem - it's probably
>> better to do the change now while the driver is still new.
>
> Hmm. searchin Google (and even looking at the VDPAU spec I myself wrote)
> does imply that format names like this do typically list the LSBs first.
>
> I guess the problem is that when I decided to change from rgb565 to a
> machine-parsable r5g6b5, I didn't think enough to realize that the field
> order in the name "rgb565" didn't follow the same convention as when you
> write out the fields in the style "r5g6b5"/"b5g6r5":-(
>
> I guess this driver and DT binding are only in linux-next and targeted
> at 3.11, and didn't make 3.10, so I'd assert it's probably still OK to
> change the DT binding, if this patch also gets into 3.11.
Great, keeping it like that then.
>> -- format: The format of the framebuffer surface. Valid values are:
>> - - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
>> +- format: The format of the framebuffer surface. Described as a sequence of
>> + channel/nbbits pairs, where each pair describes how many bits are used
>
> Change nbbits to bitcount, num-bits, nr-bits?
Ok.
>> + by a given color channel. Value channels are "r" (red), "g" (green),
>> + "b" (blue) and "a" (alpha).
>
> I think you'll need "x" too, to represent any gaps/unused bits.
Are there such formats? 15-bit formats do exist but AFAIK they just drop
the MSB. Anyway, this can be done easily, so I won't argue. :)
>> Channels are listed starting in bit-significance order.
>
> I would explicitly add ", starting from the LSB." to the end there.
> Perhaps drop "-significance" too?
Agreed, sounds better.
>> +static struct simplefb_format *simplefb_parse_format(struct device *dev,
>> + const char *str)
>> +{
>> + struct simplefb_format *format;
>> + unsigned int cpt = 0;
>
> What does cpt mean? Something like bit or bitnum or bitindex might be
> more descriptive.
Fixed.
>> + unsigned int i = 0;
>> +
>> + format = devm_kzalloc(dev, sizeof(*format), GFP_KERNEL);
>> + if (!format)
>> + return ERR_PTR(-ENOMEM);
>
> Can we just add some storage into the FB object itself for this, so we
> don't need to make a special allocation? The first parameter to
> framebuffer_alloc() allows allocating that, although you would have to
> rejig the order of probe() a bit to do that:-( Perhaps it's fine as you
> wrote it.
The less allocations the better - if using framebuffer_alloc does not
make things more confusing, I'll gladly use that solution.
>> + field->offset = cpt;
>> + field->length = c - '0';
>
> What about R10G10B10A2? Something like strtol() is needed here.
True. That's probably more color depth than humans can perceive, but
will make the mantis shrimp happy.
>> +
>> + cpt += field->length;
>> + }
>> +
>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8;
>
> Should this error-check that isn't > 32?
That would make the mantis shrimp sad.
>> + if (!params->format || IS_ERR(params->format)) {
>
> That's just saying IS_ERR_OR_NULL(params->format). It'd be better to
> pick one thing to represent errors; either NULL or an error-pointer. I
> think having simplefb_parse_format() just return NULL on error would be
> best; the caller can't really do anything useful with the information
> anyway.
Weird - I actually removed that NULL check since the parse function can
only return a valid pointed an error code. Probably forgot to
format-patch again after that.
It seems more customary to let the function that fails decide the error
code and have it propagated by its caller (even though in the current
case there is no much variety in the returned error codes). If you see
no problem with it, I will stick to that way of doing.
Thanks for the review - will send an update soon.
Alex.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] video: simplefb: add mode parsing function
From: Stephen Warren @ 2013-05-24 15:37 UTC (permalink / raw)
To: Alex Courbot
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Andrew Morton,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <519F1729.2050003-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 05/24/2013 01:30 AM, Alex Courbot wrote:
> On 05/24/2013 01:27 AM, Stephen Warren wrote:
>>> Stephen, please note that the "r5g6b5" mode initially supported
>>> by the driver becomes "b5g6r5" with the new function. This is because
>>> the least significant bits are defined first in the string - this
>>> makes parsing much easier, notably for modes which do not fill whole
>>> bytes (e.g. 15 bit modes). I hope this is not a problem - it's probably
>>> better to do the change now while the driver is still new.
...
>>> + by a given color channel. Value channels are "r" (red), "g"
>>> (green),
>>> + "b" (blue) and "a" (alpha).
>>
>> I think you'll need "x" too, to represent any gaps/unused bits.
>
> Are there such formats? 15-bit formats do exist but AFAIK they just drop
> the MSB. Anyway, this can be done easily, so I won't argue. :)
Yes, I believe there are e.g. both a2r10g10b10 and b10g10r10a2 for
example, and it's quite common to replace a with x, especially for
scanout buffers. Google certainly has hits for that.
>>> + if (!params->format || IS_ERR(params->format)) {
>>
>> That's just saying IS_ERR_OR_NULL(params->format). It'd be better to
>> pick one thing to represent errors; either NULL or an error-pointer. I
>> think having simplefb_parse_format() just return NULL on error would be
>> best; the caller can't really do anything useful with the information
>> anyway.
>
> Weird - I actually removed that NULL check since the parse function can
> only return a valid pointed an error code. Probably forgot to
> format-patch again after that.
>
> It seems more customary to let the function that fails decide the error
> code and have it propagated by its caller (even though in the current
> case there is no much variety in the returned error codes). If you see
> no problem with it, I will stick to that way of doing.
Using just an error-return is probably fine. I was going to say that the
table lookup might propagate a NULL all the way through to that check,
and hence require both checks above, but I guess that case can't happen,
since if there is no table entry, then simplefb_parse_format() will
always be called, so that's fine.
^ permalink raw reply
* [RFC] Add co-maintainer for fbdev
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-24 15:38 UTC (permalink / raw)
To: linux-fbdev; +Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Tomi Valkeinen
Hi Florian,
As you seems very busy I'd like to propose the help you to handle the
fbdev subsystem to easier the rich of the fbdev patch to Linus
As I'm working on fbdev on at91 and others and already Co-Maintain the
at91 mach on ARM
And if you are not willing to continue I could take over
Best Regards,
J.
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Olof Johansson @ 2013-05-24 17:30 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-fbdev, Arnd Bergmann, Linus Torvalds,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Andrew Morton
In-Reply-To: <20130524153835.GF15839@game.jcrosoft.org>
[+akpm]
On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Hi Florian,
>
> As you seems very busy I'd like to propose the help you to handle the
> fbdev subsystem to easier the rich of the fbdev patch to Linus
>
> As I'm working on fbdev on at91 and others and already Co-Maintain the
> at91 mach on ARM
>
> And if you are not willing to continue I could take over
Andrew has been fallback fbdev maintainer for a while, we have the
option of formalizing that as well. Adding him on cc so he sees this.
-Olof
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Arnd Bergmann @ 2013-05-24 18:56 UTC (permalink / raw)
To: Olof Johansson
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev, Linus Torvalds,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Andrew Morton,
Florian Tobias Schandinat
In-Reply-To: <CAOesGMj26_=6eQk+=0MPCoobymqrHPwwtiUnv63hz0a9Ou_VMw@mail.gmail.com>
On Friday 24 May 2013, Olof Johansson wrote:
> [+akpm]
[+florian]
> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > Hi Florian,
> >
> > As you seems very busy I'd like to propose the help you to handle the
> > fbdev subsystem to easier the rich of the fbdev patch to Linus
> >
> > As I'm working on fbdev on at91 and others and already Co-Maintain the
> > at91 mach on ARM
> >
> > And if you are not willing to continue I could take over
>
> Andrew has been fallback fbdev maintainer for a while, we have the
> option of formalizing that as well. Adding him on cc so he sees this.
It seems that Florian himself was missing on Cc too, probably by accident.
I would certainly welcome Jean-Christophe to step in for fbdev, since I
frequently have trivial patches for the subsystem, either from myself
or one of the subarch maintainers, and it would be helpful to get feedback
on them in order to merge them through arm-soc when they depend on other
patches we carry, or to have them picked up into a git tree.
Arnd
^ permalink raw reply
* [PATCH v6] video: imxfb: Add DT support
From: Markus Pargmann @ 2013-05-26 10:35 UTC (permalink / raw)
To: linux-arm-kernel
Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
Notes:
Changed in v6:
- Rebased onto v3.10-rc2
- Dropped alpha support patch in this series
Changed in v5:
- Fix compatible property of the example
- Rename property fsl,bpp to bits-per-pixel
- Add selects for FB_MODE_HELPERS and VIDEOMODE_HELPERS to Kconfig FB_IMX
Changes in v4:
- Remove eukrea specific dmacr property.
- Add optional dmacr property. If not present, the dmacr reset value is not
changed.
Changes in v3:
- Fix returncodes of of_read_mode function and print error messages
- Introduce a lower bound check for bits per pixel
- Calculate correct bytes per pixel value before using it for the calculation of
memory size
- Change DT property names
Changes in v2:
- Removed pwmr register property
- Cleanup of devicetree binding documentation
- Use default values for pwmr and lscr1
.../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++++++
drivers/video/Kconfig | 2 +
drivers/video/imxfb.c | 194 +++++++++++++++++----
3 files changed, 212 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..46da08d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+ Documentation/devicetree/bindings/video/display-timing.txt
+ Additional, the display node has to define properties:
+ - bits-per-pixel: Bits per pixel
+ - fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+ register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+ imxfb: fb@10021000 {
+ compatible = "fsl,imx21-fb";
+ interrupts = <61>;
+ reg = <0x10021000 0x1000>;
+ display = <&display0>;
+ };
+
+ ...
+
+ display0: display0 {
+ model = "Primeview-PD050VL1";
+ native-mode = <&timing_disp0>;
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xf0c88080>; /* non-standard but required */
+ display-timings {
+ timing_disp0: 640x480 {
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <112>;
+ hfront-porch = <36>;
+ hsync-len = <32>;
+ vback-porch = <33>;
+ vfront-porch = <33>;
+ vsync-len = <2>;
+ clock-frequency = <25000000>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d71d60f..588af1d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -367,6 +367,8 @@ config FB_IMX
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ select VIDEOMODE_HELPERS
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..a2ed71d 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,12 @@
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/math64.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
#include <linux/platform_data/video-imxfb.h>
@@ -112,10 +118,11 @@
#define LCDISR_EOF (1<<1)
#define LCDISR_BOF (1<<0)
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
-
/*
* These are the bitfields for each
* display depth that we support.
@@ -187,6 +194,19 @@ static struct platform_device_id imxfb_devtype[] = {
};
MODULE_DEVICE_TABLE(platform, imxfb_devtype);
+static struct of_device_id imxfb_of_dev_id[] = {
+ {
+ .compatible = "fsl,imx1-fb",
+ .data = &imxfb_devtype[IMX1_FB],
+ }, {
+ .compatible = "fsl,imx21-fb",
+ .data = &imxfb_devtype[IMX21_FB],
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
static inline int is_imx1_fb(struct imxfb_info *fbi)
{
return fbi->devtype = IMX1_FB;
@@ -319,6 +339,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
struct imx_fb_videomode *m;
int i;
+ if (!fb_mode)
+ return &fbi->mode[0];
+
for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
if (!strcmp(m->mode.name, fb_mode))
return m;
@@ -474,6 +497,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
struct imxfb_info *fbi = bl_get_data(bl);
int brightness = bl->props.brightness;
+ if (!fbi->pwmr)
+ return 0;
+
if (bl->props.power != FB_BLANK_UNBLANK)
brightness = 0;
if (bl->props.fb_blank != FB_BLANK_UNBLANK)
@@ -684,10 +710,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
writel(fbi->pcr, fbi->regs + LCDC_PCR);
#ifndef PWMR_BACKLIGHT_AVAILABLE
- writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
+ if (fbi->pwmr)
+ writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
#endif
writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
- writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+
+ /* dmacr = 0 is no valid value, as we need DMA control marks. */
+ if (fbi->dmacr)
+ writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
return 0;
}
@@ -723,13 +753,12 @@ static int imxfb_resume(struct platform_device *dev)
#define imxfb_resume NULL
#endif
-static int __init imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev)
{
struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
struct fb_info *info = dev_get_drvdata(&pdev->dev);
struct imxfb_info *fbi = info->par;
- struct imx_fb_videomode *m;
- int i;
+ struct device_node *np;
pr_debug("%s\n",__func__);
@@ -760,41 +789,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
info->fbops = &imxfb_ops;
info->flags = FBINFO_FLAG_DEFAULT |
FBINFO_READS_FAST;
- info->var.grayscale = pdata->cmap_greyscale;
- fbi->cmap_inverse = pdata->cmap_inverse;
- fbi->cmap_static = pdata->cmap_static;
- fbi->lscr1 = pdata->lscr1;
- fbi->dmacr = pdata->dmacr;
- fbi->pwmr = pdata->pwmr;
- fbi->lcd_power = pdata->lcd_power;
- fbi->backlight_power = pdata->backlight_power;
-
- for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
- info->fix.smem_len = max_t(size_t, info->fix.smem_len,
- m->mode.xres * m->mode.yres * m->bpp / 8);
+ if (pdata) {
+ info->var.grayscale = pdata->cmap_greyscale;
+ fbi->cmap_inverse = pdata->cmap_inverse;
+ fbi->cmap_static = pdata->cmap_static;
+ fbi->lscr1 = pdata->lscr1;
+ fbi->dmacr = pdata->dmacr;
+ fbi->pwmr = pdata->pwmr;
+ fbi->lcd_power = pdata->lcd_power;
+ fbi->backlight_power = pdata->backlight_power;
+ } else {
+ np = pdev->dev.of_node;
+ info->var.grayscale = of_property_read_bool(np,
+ "cmap-greyscale");
+ fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
+ fbi->cmap_static = of_property_read_bool(np, "cmap-static");
+
+ fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
+ of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
+
+ of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+
+ /* These two function pointers could be used by some specific
+ * platforms. */
+ fbi->lcd_power = NULL;
+ fbi->backlight_power = NULL;
+ }
+
+ return 0;
+}
+
+static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
+ struct imx_fb_videomode *imxfb_mode)
+{
+ int ret;
+ struct fb_videomode *of_mode = &imxfb_mode->mode;
+ u32 bpp;
+ u32 pcr;
+
+ ret = of_property_read_string(np, "model", &of_mode->name);
+ if (ret)
+ of_mode->name = NULL;
+
+ ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
+ if (ret) {
+ dev_err(dev, "Failed to get videomode from DT\n");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "bits-per-pixel", &bpp);
+ ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
+
+ if (ret) {
+ dev_err(dev, "Failed to read bpp and pcr from DT\n");
+ return -EINVAL;
+ }
+
+ if (bpp < 1 || bpp > 255) {
+ dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
+ return -EINVAL;
+ }
+
+ imxfb_mode->bpp = bpp;
+ imxfb_mode->pcr = pcr;
return 0;
}
-static int __init imxfb_probe(struct platform_device *pdev)
+static int imxfb_probe(struct platform_device *pdev)
{
struct imxfb_info *fbi;
struct fb_info *info;
struct imx_fb_platform_data *pdata;
struct resource *res;
+ struct imx_fb_videomode *m;
+ const struct of_device_id *of_id;
int ret, i;
+ int bytes_per_pixel;
dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
+ of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = of_id->data;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENODEV;
pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev,"No platform_data available\n");
- return -ENOMEM;
- }
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
@@ -802,15 +885,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
fbi = info->par;
- if (!fb_mode)
- fb_mode = pdata->mode[0].mode.name;
-
platform_set_drvdata(pdev, info);
ret = imxfb_init_fbinfo(pdev);
if (ret < 0)
goto failed_init;
+ if (pdata) {
+ if (!fb_mode)
+ fb_mode = pdata->mode[0].mode.name;
+
+ fbi->mode = pdata->mode;
+ fbi->num_modes = pdata->num_modes;
+ } else {
+ struct device_node *display_np;
+ fb_mode = NULL;
+
+ display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+ if (!display_np) {
+ dev_err(&pdev->dev, "No display defined in devicetree\n");
+ ret = -EINVAL;
+ goto failed_of_parse;
+ }
+
+ /*
+ * imxfb does not support more modes, we choose only the native
+ * mode.
+ */
+ fbi->num_modes = 1;
+
+ fbi->mode = devm_kzalloc(&pdev->dev,
+ sizeof(struct imx_fb_videomode), GFP_KERNEL);
+ if (!fbi->mode) {
+ ret = -ENOMEM;
+ goto failed_of_parse;
+ }
+
+ ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
+ if (ret)
+ goto failed_of_parse;
+ }
+
+ /* Calculate maximum bytes used per pixel. In most cases this should
+ * be the same as m->bpp/8 */
+ m = &fbi->mode[0];
+ bytes_per_pixel = (m->bpp + 7) / 8;
+ for (i = 0; i < fbi->num_modes; i++, m++)
+ info->fix.smem_len = max_t(size_t, info->fix.smem_len,
+ m->mode.xres * m->mode.yres * bytes_per_pixel);
+
res = request_mem_region(res->start, resource_size(res),
DRIVER_NAME);
if (!res) {
@@ -843,7 +966,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
goto failed_ioremap;
}
- if (!pdata->fixed_screen_cpu) {
+ /* Seems not being used by anyone, so no support for oftree */
+ if (!pdata || !pdata->fixed_screen_cpu) {
fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
fbi->map_size, &fbi->map_dma, GFP_KERNEL);
@@ -868,18 +992,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
info->fix.smem_start = fbi->screen_dma;
}
- if (pdata->init) {
+ if (pdata && pdata->init) {
ret = pdata->init(fbi->pdev);
if (ret)
goto failed_platform_init;
}
- fbi->mode = pdata->mode;
- fbi->num_modes = pdata->num_modes;
INIT_LIST_HEAD(&info->modelist);
- for (i = 0; i < pdata->num_modes; i++)
- fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
+ for (i = 0; i < fbi->num_modes; i++)
+ fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
/*
* This makes sure that our colour bitfield
@@ -909,10 +1031,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
failed_register:
fb_dealloc_cmap(&info->cmap);
failed_cmap:
- if (pdata->exit)
+ if (pdata && pdata->exit)
pdata->exit(fbi->pdev);
failed_platform_init:
- if (!pdata->fixed_screen_cpu)
+ if (pdata && !pdata->fixed_screen_cpu)
dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
fbi->map_dma);
failed_map:
@@ -921,6 +1043,7 @@ failed_ioremap:
failed_getclock:
release_mem_region(res->start, resource_size(res));
failed_req:
+failed_of_parse:
kfree(info->pseudo_palette);
failed_init:
platform_set_drvdata(pdev, NULL);
@@ -945,7 +1068,7 @@ static int imxfb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
pdata = pdev->dev.platform_data;
- if (pdata->exit)
+ if (pdata && pdata->exit)
pdata->exit(fbi->pdev);
fb_dealloc_cmap(&info->cmap);
@@ -974,6 +1097,7 @@ static struct platform_driver imxfb_driver = {
.shutdown = imxfb_shutdown,
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = imxfb_of_dev_id,
},
.id_table = imxfb_devtype,
};
--
1.8.2.1
^ permalink raw reply related
* [PATCH v8, part3 06/14] mm, acornfb: use free_reserved_area() to simplify code
From: Jiang Liu @ 2013-05-26 13:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Jiang Liu, David Rientjes, Wen Congyang, Mel Gorman, Minchan Kim,
KAMEZAWA Hiroyuki, Michal Hocko, James Bottomley, Sergei Shtylyov,
David Howells, Mark Salter, Jianguo Wu, linux-mm, linux-arch,
linux-kernel, Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1369575522-26405-1-git-send-email-jiang.liu@huawei.com>
Use common help function free_reserved_area() to simplify code.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/acornfb.c | 45 ++++++---------------------------------------
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..8f7374f 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1180,42 +1180,6 @@ static int acornfb_detect_monitortype(void)
return 4;
}
-/*
- * This enables the unused memory to be freed on older Acorn machines.
- * We are freeing memory on behalf of the architecture initialisation
- * code here.
- */
-static inline void
-free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
-{
- int mb_freed = 0;
-
- /*
- * Align addresses
- */
- virtual_start = PAGE_ALIGN(virtual_start);
- virtual_end = PAGE_ALIGN(virtual_end);
-
- while (virtual_start < virtual_end) {
- struct page *page;
-
- /*
- * Clear page reserved bit,
- * set count to 1, and free
- * the page.
- */
- page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
-
- virtual_start += PAGE_SIZE;
- mb_freed += PAGE_SIZE / 1024;
- }
-
- printk("acornfb: freed %dK memory\n", mb_freed);
-}
-
static int acornfb_probe(struct platform_device *dev)
{
unsigned long size;
@@ -1312,10 +1276,13 @@ static int acornfb_probe(struct platform_device *dev)
#endif
#if defined(HAS_VIDC)
/*
- * Archimedes/A5000 machines use a fixed address for their
- * framebuffers. Free unused pages
+ * We are freeing memory on behalf of the architecture initialisation
+ * code here. Archimedes/A5000 machines use a fixed address for their
+ * framebuffers.
*/
- free_unused_pages(PAGE_OFFSET + size, PAGE_OFFSET + MAX_SIZE);
+ free_reserved_area((void *)(PAGE_OFFSET + size),
+ (void *)PAGE_ALIGN(PAGE_OFFSET + MAX_SIZE),
+ -1, "acornfb");
#endif
fb_info.fix.smem_len = size;
--
1.8.1.2
^ permalink raw reply related
* Re: [RFC] Add co-maintainer for fbdev
From: Florian Tobias Schandinat @ 2013-05-26 23:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev,
Linus Torvalds, linux-kernel@vger.kernel.org, Tomi Valkeinen,
Andrew Morton
In-Reply-To: <201305242056.42482.arnd@arndb.de>
Hi Jean-Christophe,
On 05/24/2013 06:56 PM, Arnd Bergmann wrote:
> On Friday 24 May 2013, Olof Johansson wrote:
>> [+akpm]
>
> [+florian]
Thanks for CC'ing me. Lately I got dropped frequently from the
mailinglist (after 1 or 2 days). Guess I should try subscribing via my
own mail server.
>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>>> Hi Florian,
>>>
>>> As you seems very busy I'd like to propose the help you to handle the
>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
>>>
>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
>>> at91 mach on ARM
>>>
>>> And if you are not willing to continue I could take over
Yeah, it would be great if you could help, at the moment I get barely
any sleep, let alone that I could keep up with the majority of mail I
get. I'll let you decide whether you want to be sole maintainer or not.
I still have interest in the subsystem, but it looks like VIA won't
provide any information for their new VX11 chipset IGP for any open
source driver and I'm still looking for a small, quiet mobile device as
a replacement for my precious netbook that broke down last autumn to
allow me working when I'm not at home.
>> Andrew has been fallback fbdev maintainer for a while, we have the
>> option of formalizing that as well. Adding him on cc so he sees this.
At this point I'd like to thank all people who have helped out so far,
especially Tomi and Andrew.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Thank you from Google.
From: Google+ @ 2013-05-27 0:37 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
Dear Google User.
Attached to this email is your anniversary notification for being an active user of Google.
Sincerely.
Dr. Donald Lloyd.
Google Promotion Award Team.
----------------------------------------------------------------
This message was sent using Google Messaging Program (GMP).
[-- Attachment #2: GPA Notification.pdf --]
[-- Type: application/pdf, Size: 54226 bytes --]
^ permalink raw reply
* [PATCH] video: mxsfb: Let device core handle pinctrl
From: Fabio Estevam @ 2013-05-27 1:48 UTC (permalink / raw)
To: linux-fbdev
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
we can rely on device core for handling pinctrl, so remove
devm_pinctrl_get_select_default() from the driver.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/mxsfb.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..9d6a286 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -46,7 +46,6 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
-#include <linux/pinctrl/consumer.h>
#include <linux/fb.h>
#include <linux/regulator/consumer.h>
#include <video/of_display_timing.h>
@@ -877,7 +876,6 @@ static int mxsfb_probe(struct platform_device *pdev)
struct mxsfb_info *host;
struct fb_info *fb_info;
struct fb_modelist *modelist;
- struct pinctrl *pinctrl;
int ret;
if (of_id)
@@ -909,12 +907,6 @@ static int mxsfb_probe(struct platform_device *pdev)
host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto fb_release;
- }
-
host->clk = devm_clk_get(&host->pdev->dev, NULL);
if (IS_ERR(host->clk)) {
ret = PTR_ERR(host->clk);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2] video: simplefb: add mode parsing function
From: Alexandre Courbot @ 2013-05-27 3:53 UTC (permalink / raw)
To: linux-arm-kernel
The naming scheme of simplefb's mode is precise enough to allow building
the mode structure from it instead of using a static list of modes. This
patch introduces a function that does this. In case exotic modes that
cannot be represented from their name alone are needed, the static list
of modes is still available as a backup.
It also changes the order in which colors are declared from MSB first to
the more standard LSB first.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Changes from v1:
- amended documentation following Stephen's suggestion
- allow parsing of bitfields larger than 9 bits
- made it clear that the parsing order of bits is changed with respect
to the original patch
Andrew, since this patch introduces a (small) change in the DT bindings,
could we try to merge it during the -rc cycle so we don't have to come
with a more complex solution in the future?
.../bindings/video/simple-framebuffer.txt | 12 +++-
drivers/video/simplefb.c | 72 +++++++++++++++++++++-
2 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 3ea4605..18d03e2 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -10,8 +10,16 @@ Required properties:
- width: The width of the framebuffer in pixels.
- height: The height of the framebuffer in pixels.
- stride: The number of bytes in each line of the framebuffer.
-- format: The format of the framebuffer surface. Valid values are:
- - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+- format: The format of the framebuffer surface. Described as a sequence of
+ channel/num-bits pairs, where each pair describes how many bits are used
+ by a given color channel. Value channels are "r" (red), "g" (green),
+ "b" (blue), "a" (alpha) and "x" (unused). Channels are listed in bit
+ order, starting from the LSB. For instance, a format named "r5g6b5"
+ describes a 16-bit format where red is encoded in the 5 less significant
+ bits, green in the 6 following ones, and blue in the 5 last:
+ BBBBBGGG GGGRRRRR
+ ^ ^
+ MSB LSB
Example:
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..1430752 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -21,6 +21,7 @@
*/
#include <linux/errno.h>
+#include <linux/ctype.h>
#include <linux/fb.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -82,8 +83,72 @@ struct simplefb_format {
struct fb_bitfield transp;
};
+static struct simplefb_format *simplefb_parse_format(struct device *dev,
+ const char *str)
+{
+ struct simplefb_format *format;
+ unsigned int offset = 0;
+ unsigned int i = 0;
+
+ format = devm_kzalloc(dev, sizeof(*format), GFP_KERNEL);
+ if (!format)
+ return ERR_PTR(-ENOMEM);
+
+ while (str[i] != 0) {
+ struct fb_bitfield *field = NULL;
+ int length = 0;
+
+ switch (str[i++]) {
+ case 'r':
+ case 'R':
+ field = &format->red;
+ break;
+ case 'g':
+ case 'G':
+ field = &format->green;
+ break;
+ case 'b':
+ case 'B':
+ field = &format->blue;
+ break;
+ case 'a':
+ case 'A':
+ field = &format->transp;
+ break;
+ case 'x':
+ case 'X':
+ break;
+ default:
+ goto error;
+ }
+
+ if (!isdigit(str[i]))
+ goto error;
+
+ while (isdigit(str[i])) {
+ length = length * 10 + (str[i++] - '0');
+ }
+
+ if (field) {
+ field->offset = offset;
+ field->length = length;
+ }
+
+ offset += length;
+ }
+
+ format->bits_per_pixel = (offset + 7) & ~0x7;
+ format->name = str;
+ return format;
+
+error:
+ dev_err(dev, "Invalid format string\n");
+ return ERR_PTR(-EINVAL);
+}
+
+/* if you use exotic modes that simplefb_parse_format cannot decode, you can
+ specify them here. */
static struct simplefb_format simplefb_formats[] = {
- { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
};
struct simplefb_params {
@@ -131,7 +196,10 @@ static int simplefb_parse_dt(struct platform_device *pdev,
params->format = &simplefb_formats[i];
break;
}
- if (!params->format) {
+ if (!params->format)
+ params->format = simplefb_parse_format(&pdev->dev, format);
+
+ if (IS_ERR(params->format)) {
dev_err(&pdev->dev, "Invalid format value\n");
return -EINVAL;
}
--
1.8.3
^ permalink raw reply related
* Re: [PATCH] video: mxsfb: Let device core handle pinctrl
From: Shawn Guo @ 2013-05-27 7:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369619294-10362-1-git-send-email-festevam@gmail.com>
On Sun, May 26, 2013 at 10:48:14PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
> we can rely on device core for handling pinctrl, so remove
> devm_pinctrl_get_select_default() from the driver.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Tomi Valkeinen @ 2013-05-27 7:49 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Florian Tobias Schandinat, Arnd Bergmann, Olof Johansson,
linux-fbdev, Linus Torvalds, linux-kernel@vger.kernel.org,
Andrew Morton
In-Reply-To: <51A29DB9.7030505@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi Jean-Christophe,
>>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
>>> <plagnioj@jcrosoft.com> wrote:
>>>> Hi Florian,
>>>>
>>>> As you seems very busy I'd like to propose the help you to handle the
>>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
>>>>
>>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
>>>> at91 mach on ARM
>>>>
>>>> And if you are not willing to continue I could take over
I've been collecting fbdev patches for the latest merge windows, so that
Linus doesn't get tons of small separate pull requests. But I haven't
been very proactive with that, and I don't think I have time to really
maintain fbdev.
So I'd also welcome somebody stepping up and taking taking on the
maintainership of fbdev.
Tomi
Ps. I already have a few patches for 3.10 and for 3.11. I'll send them
to you.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Jingoo Han @ 2013-05-27 8:19 UTC (permalink / raw)
To: 'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD'
Cc: 'Florian Tobias Schandinat', 'Arnd Bergmann',
'Olof Johansson', linux-fbdev, 'Linus Torvalds',
linux-kernel, 'Andrew Morton'
In-Reply-To: <51A31013.9010701@ti.com>
On Monday, May 27, 2013 4:50 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> Hi Jean-Christophe,
>
> >>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> >>> <plagnioj@jcrosoft.com> wrote:
> >>>> Hi Florian,
> >>>>
> >>>> As you seems very busy I'd like to propose the help you to handle the
> >>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
> >>>>
> >>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
> >>>> at91 mach on ARM
> >>>>
> >>>> And if you are not willing to continue I could take over
>
> I've been collecting fbdev patches for the latest merge windows, so that
> Linus doesn't get tons of small separate pull requests. But I haven't
> been very proactive with that, and I don't think I have time to really
> maintain fbdev.
Hi Tomi,
I really thank you for your previous efforts.
Actually, I thought that you're a good fit for fbdev.
>
> So I'd also welcome somebody stepping up and taking taking on the
> maintainership of fbdev.
Hi Jean-Christophe PLAGNIOL-VILLARD,
I agree with Tomi's opinion.
If you take the maintainership of fbdev, it will be very helpful.
Best regards,
Jingoo Han
>
> Tomi
>
> Ps. I already have a few patches for 3.10 and for 3.11. I'll send them
> to you.
>
^ permalink raw reply
* [PATCH] console/dummy: Move screen size selection from CPP to Kconfig
From: Geert Uytterhoeven @ 2013-05-27 8:36 UTC (permalink / raw)
To: linux-arm-kernel
PA-RISC already handled the dummy console screen size selection in Kconfig,
so generalize this to other platforms.
ARM keeps on using screen_info, which is filled in by platform-specific
code, or from ATAGS.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/video/console/Kconfig | 16 ++++++++++------
drivers/video/console/dummycon.c | 5 +----
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 8af6ad3..7bfe7e1 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -76,18 +76,22 @@ config DUMMY_CONSOLE
config DUMMY_CONSOLE_COLUMNS
int "Initial number of console screen columns"
- depends on PARISC && DUMMY_CONSOLE
- default "160"
+ depends on DUMMY_CONSOLE && !ARM
+ default 160 if PARISC
+ default 80
help
- The default value is 160, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 160, which should fit a 1280x1024
+ monitor.
Select 80 if you use a 640x480 resolution by default.
config DUMMY_CONSOLE_ROWS
int "Initial number of console screen rows"
- depends on PARISC && DUMMY_CONSOLE
- default "64"
+ depends on DUMMY_CONSOLE && !ARM
+ default 64 if PARISC
+ default 25
help
- The default value is 64, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 64, which should fit a 1280x1024
+ monitor.
Select 25 if you use a 640x480 resolution by default.
config FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f..6b1a5d1 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -20,13 +20,10 @@
#if defined(__arm__)
#define DUMMY_COLUMNS screen_info.orig_video_cols
#define DUMMY_ROWS screen_info.orig_video_lines
-#elif defined(__hppa__)
+#else
/* set by Kconfig. Use 80x25 for 640x480 and 160x64 for 1280x1024 */
#define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS
#define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS
-#else
-#define DUMMY_COLUMNS 80
-#define DUMMY_ROWS 25
#endif
static const char *dummycon_startup(void)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v6] video: imxfb: Add DT support
From: Sascha Hauer @ 2013-05-27 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1369564538-21835-1-git-send-email-mpa@pengutronix.de>
On Sun, May 26, 2013 at 12:35:38PM +0200, Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-27 10:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
Hi all,
I have been removed previous branch and added new one with more cleanup.
This time, the fence helper doesn't include user side interfaces and cache
operation relevant codes anymore because not only we are not sure that
coupling those two things, synchronizing caches and buffer access between
CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
good idea yet but also existing codes for user side have problems with badly
behaved or crashing userspace. So this could be more discussed later.
The below is a new branch,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
ence-helper
And fence helper codes,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dma-fence-helper&idcbc0fe7e285ce866e5816e5e21443dcce01005
And example codes for device driver,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dma-fence-helper&idÒce7af23835789602a99d0ccef1f53cdd5caaae
I think the time is not yet ripe for RFC posting: maybe existing dma fence
and reservation need more review and addition work. So I'd glad for somebody
giving other opinions and advices in advance before RFC posting.
Thanks,
Inki Dae
^ 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