On 06/24/2013 04:27 PM, David Herrmann wrote:
> If we create proper platform-devices in x86 boot-code, we can use simplefb
> for VBE or EFI framebuffers, too. However, there is normally no OF support
> so we introduce a platform_data object so x86 boot-code can pass the
> paramaters via plain old
On 06/24/2013 04:27 PM, David Herrmann wrote:
> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
> x86 causes troubles when loading multiple fbdev drivers. The global
> "struct screen_info" does not provide any state-tracking about which
> drivers use the FBs.
On 06/24/2013 04:27 PM, David Herrmann wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create one dumb-buffer and attach it to the CRTC. Only if
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
>
> fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
> a printk() causes NULL-derefs in hide_cursor() and other places in the
On 06/24/2013 04:27 PM, David Herrmann wrote:
> Hi
>
> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
> show the resemblence with the recently introduced simplefb.c fbdev driver. The
> driver is supposed to be the most basic DRM driver similar to efifb.c,
> vesafb.c,
On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
> On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
>> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
>>> Dropping Tegra ML, it's not the place where Nouveau mails should go.
>>
>> $ ./scripts/get_maintainer.pl -f
From: Stephen Warren <swar...@nvidia.com>
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K:
From: Stephen Warren <swar...@nvidia.com>
This causes the regex to be applied to filenames only, and not patch or
file content (such as comments). This should prevent e.g.
drivers/gpu/drm/nouveau/nv50_display.c from matching this entry.
Reported-by: Marcin Slusarz
Signed-off-by: Stephen
From: Stephen Warren <swar...@nvidia.com>
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K:
From: Stephen Warren <swar...@nvidia.com>
This causes the regex to be applied to filenames only, and not patch or
file content (such as comments). This should prevent e.g.
drivers/gpu/drm/nouveau/nv50_display.c from matching this entry.
Reported-by: Marcin Slusarz
Signed-off-by: Stephen
From: Stephen Warren <swar...@nvidia.com>
This reverts most of eb90d08 "get_maintainer: allow keywords to match
filenames"; all except the parts that are required to implement the new
N: entry type.
The rationale is that it's better to have K: match just patch or file
content
On 03/06/2013 05:30 PM, Joe Perches wrote:
> On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> This reverts most of eb90d08 "get_maintainer: allow keywords to match
>> filenames"; all except the parts that are required
On 03/06/2013 05:40 PM, Joe Perches wrote:
> On Wed, 2013-03-06 at 17:34 -0700, Stephen Warren wrote:
>> On 03/06/2013 05:30 PM, Joe Perches wrote:
>>> On Wed, 2013-03-06 at 17:29 -0700, Stephen Warren wrote:
>>>> From: Stephen Warren
>>>>
>>>&g
From: Stephen Warren <swar...@nvidia.com>
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K:
On 03/11/2013 03:36 PM, Marcin ?lusarz wrote:
>
> 11 mar 2013 21:19, "Stephen Warren" <mailto:swarren at wwwdotorg.org>> napisa?(a):
>> Create a new N: entry type in MAINTAINERS which performs a regex match
>> against filenames; either those extracted fro
From: Stephen Warren <swar...@nvidia.com>
ARCH_TEGRA always enabled OF, so there's no need for any driver to
depend on it.
Signed-off-by: Stephen Warren
---
drivers/gpu/drm/tegra/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kco
On 10/11/2015 06:39 AM, Stefan Wahren wrote:
> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>> This is a respin of the Raspberry Pi KMS series. Now that we've got a
>> real clock driver, I can actually set new video modes. Also in this
>> version, most of the custom DT stuff from before is gone,
n dtsi so we can paste the output as is and be sure that the kernel
> doesn't diverge from the canonical data.
At a quick glance this series looks OK,
Acked-by: Stephen Warren
On 08/23/2012 07:44 PM, Ricardo Neri wrote:
> On 08/22/2012 02:55 AM, Takashi Iwai wrote:
>> At Tue, 21 Aug 2012 19:58:02 -0500,
>> Ricardo Neri wrote:
...
>>> Maybe the lack of audio support in drm is because the audio users should
>>> not talk to drm directly but to a lower level component
On 11/30/2012 03:38 AM, Thierry Reding wrote:
> On Fri, Nov 30, 2012 at 10:56:39AM +0200, Terje Bergstr?m wrote:
>> On 29.11.2012 13:47, Thierry Reding wrote:
>>> On Thu, Nov 29, 2012 at 12:21:04PM +0200, Terje Bergstr?m
>>> wrote:
Tegra20 and Tegra30 are compatible, but future chips are not.
On 12/01/2012 07:58 AM, Thierry Reding wrote:
> On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergstr?m wrote:
...
>> I was thinking of definitions like this:
>>
>> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) {
>> return (v & 0x1ff) << 0; }
>>
>> versus
>>
>> #define
On 12/03/2012 08:00 PM, Mark Zhang wrote:
> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>>>> On 11/27/2012
On 12/06/2012 01:13 AM, Mark Zhang wrote:
> On 12/06/2012 04:00 PM, Lucas Stach wrote:
>> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang:
> [...]
>>>
>>> OK. So these relocation addresses are used to let userspace tells kernel
>>> which buffers mentioned in the command should be
On 12/13/2012 01:57 AM, Thierry Reding wrote:
> On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergstr?m wrote:
>> On 12.12.2012 18:08, Thierry Reding wrote:
>>> I've briefly discussed this with Stephen on IRC because I
>>> thought I had remembered him objecting to the idea of adding a
>>> dummy
On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have teg
On 12/16/2012 09:37 AM, Terje Bergstr?m wrote:
...
> ... Sure we could tell DC to ask its parent
> (host1x), and call host1x driver with platform_device pointer found that
> way, and host1x would return a pointer to tegradrm's data. Hanging the
> data onto host1x driver is just a more complicated
On 12/20/2012 02:17 AM, Terje Bergstr?m wrote:
> On 16.12.2012 14:16, Thierry Reding wrote:
>> Okay, so we're back on the topic of using globals. I need to assert
>> again that this is not an option. If we were to use globals, then we
>> could just as well leave out the dummy device and just do
On 12/20/2012 10:46 AM, Terje Bergstr?m wrote:
> On 20.12.2012 19:14, Stephen Warren wrote:
>> I'm not sure that sounds right. drvdata is something that a driver
>> should manage itself.
>>
>> What's wrong with just having each device ask the host1x (its parent)
>
On 12/20/2012 02:34 PM, Terje Bergstr?m wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
>> The problem with your proposed solution is that, even any of Stephen's
>> valid objections aside, it won't work. Once the tegra-drm module is
>> unloaded, the driver's data will be left in the current
On 12/20/2012 02:50 PM, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergstr?m wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of
>>> Stephen's valid objections aside, it won't work. Once the
>>>
On 12/21/2012 01:57 AM, Arto Merilainen wrote:
> On 12/20/2012 07:14 PM, Stephen Warren wrote:
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy) tegradrm device. That seems extremely
>>
>
> We are talk
On 12/21/2012 11:50 PM, Terje Bergstr?m wrote:
> On 21.12.2012 16:36, Thierry Reding wrote:
>> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>>> +static struct platform_driver tegra_drm_platform_driver = {
>>> + .driver = {
>>> + .name = "tegradrm",
>>
>> This should
On 04/11/2012 06:10 AM, Thierry Reding wrote:
> This commit adds device tree support for the GART hardware available on
> NVIDIA Tegra 20 SoCs.
>
> Signed-off-by: Thierry Reding
> ---
> arch/arm/boot/dts/tegra20.dtsi |6 ++
> arch/arm/mach-tegra/board-dt-tegra20.c |1 +
>
On 04/11/2012 06:10 AM, Thierry Reding wrote:
> This commit is taken from the Chromium tree and was originally written
> by Robert Morell.
Maybe just cherry-pick it from there? That way, the git authorship will
show up as Robert.
On 04/11/2012 06:10 AM, Thierry Reding wrote:
> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> currently has rudimentary GEM support and can run a console on the
> framebuffer as well as X using the xf86-video-modesetting driver.
> Only the RGB output is supported. Quite a
On 04/12/2012 12:50 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/11/2012 06:10 AM, Thierry Reding wrote:
>>> This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
>>> currently has rudimentary GEM support and can run a console on the
>>
On 04/12/2012 11:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 12:50 AM, Thierry Reding wrote:
>>> drm {
>>> compatible = "nvidia,tegra20-drm";
>>
>> I'm don't think having an explicit "drm"
On 04/13/2012 03:14 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/12/2012 11:44 AM, Thierry Reding wrote:
> [...]
>> And given that, I don't think we should name the node after some
>> OS-specific software concept. Device tree is intended to model hardwar
On 04/15/2012 02:39 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 04/13/2012 03:14 AM, Thierry Reding wrote:
>>> display-controllers = < >;
>>> outputs = < >;
>>
>> I don't think you need both the child node
On 04/16/2012 12:48 PM, Thierry Reding wrote:
> * Stephen Warren wrote:
...
>>> Has there been any discussion as to how EDID data would best be represented
>>> in DT? Should it just be a binary blob or rather some textual
>>> representation?
>>
>>
On 04/16/2012 01:03 PM, Thierry Reding wrote:
...
> I've been looking about for tools to generate EDID data but didn't find
> anything useful. Does anyone know of any tool that's more convenient than
> manually filling a struct edid and writing that to a file?
Sorry, no.
On 04/25/2012 03:45 AM, Thierry Reding wrote:
> This function resolves an OF device node to an I2C adapter registered
> with the I2C core.
I think this is doing the same thing as a patch I posted recently:
http://www.spinics.net/lists/linux-i2c/msg07808.html
What's the advantage of one way over
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> diff --git a/Documentation/devicetree/bindings/video/displaymode
>
On 07/05/2012 08:51 AM, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> diff --git
On 08/03/2012 01:38 AM, Sascha Hauer wrote:
> Hi Stephen,
>
> On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
>> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
>>> This patch adds a helper function for parsing videomodes from the
>>> devicetree
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some
Wu Fengguang wrote at Friday, August 05, 2011 6:50 AM:
> On Fri, Aug 05, 2011 at 02:03:41AM +0800, Keith Packard wrote:
> > On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang
> > wrote:
...
> > > You may wonder why the mode parameter is needed in intel_write_eld().
> > > This is because the ELD
301 - 347 of 347 matches
Mail list logo
