[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-sparc
Subject:    =?UTF-8?q?Re:_[PATCH]_cg3:_use_standard_fields_for_framebuffer_physical_address_and_length?=
From:       krzysztof.h1 () poczta ! fm
Date:       2009-05-05 8:45:05
Message-ID: 20090505084505.C94E615F7883 () f12 ! poczta ! interia ! pl
[Download RAW message or body]

David Miller napisał(a):
> From: Krzysztof Helt >krzysztof.h1@poczta.fm>
> Date: Mon, 4 May 2009 22:37:46 +0200
> 
> > Use standard fields fbinfo.fix.smem_start and fbinfo.fix.smem_len
> > for physical address and length of framebuffer.
> > 
> > This also fixes output of the 'fbset -i' command - address and length 
> > of the framebuffer is displayed correctly.
> > 
> > Signed-off-by: Krzysztof Helt >krzysztof.h1@wp.pl>
> 
> I think this is not appropriate.
> 
> The "physical address" of these framebuffers is composed of
> two values, the 32-bit physical offset and the "which_io"
> value.  The full physical I/O address is 36 bits.
> 
> Considering either seperately makes no sense.  And adjustments
> of one make no sense without consideration of the other.
> 
> 

I see. However, there is no adjustment to the smem_start outside 
the driver. It is used only to be displayed by the fbset (which is
general and does not understand the IO spaces).
Another usage is inside the fb_mmap but only if there is no local
fb_mmap function defined by the driver. It is not a case for all sbus 
drivers.

Regards,
Krzysztof



----------------------------------------------------------------------
Wygraj wycieczke do Eurodisneylandu!
Sprawdz >> http://link.interia.pl/f2153

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]