On Tue, 30 Aug 2011, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > > So, hypothetically speaking, hpa suggested then that we could pass
> > > firmware blobs over the linked list setup_data thing in t
On Tue, 30 Aug 2011, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > > So, hypothetically speaking, hpa suggested then that we could pass
> > > firmware blobs over the linked list setup_data th
On Mon, 2011-08-29 at 23:08 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > So, hypothetically speaking, hpa suggested then that we could pass
> > firmware blobs over the linked list setup_data thing in the real-mode
> > kernel header and parse_setup_data
On Mon, Aug 29, 2011 at 11:08:28PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Aug 2011, Borislav Petkov wrote:
> > So, hypothetically speaking, hpa suggested then that we could pass
> > firmware blobs over the linked list setup_data thing in the real-mode
> > kernel header and parse_set
On Mon, 29 Aug 2011, Borislav Petkov wrote:
> So, hypothetically speaking, hpa suggested then that we could pass
> firmware blobs over the linked list setup_data thing in the real-mode
> kernel header and parse_setup_data() can look at them and map them
> somewhere later for the driver to find. Thi
On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > > That would suck, suppose this radeon thing is the only console you've
> > > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > > up?
> >
> > Sa
On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > That would suck, suppose this radeon thing is the only console you've
> > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > up?
>
> Same is true for NICs and netconsole of course. Not being able to stick
> blob
On Mon, 2011-08-29 at 19:50 +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> > On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > > do you want something ala:
> > >
> > > config EXTRA_FIRMWARE
> > > string
> > > default ""
> > >
On Mon, 2011-08-29 at 19:21 +0200, Borislav Petkov wrote:
>
> Yeah, sounds much better than Kconfig actually aiding and abetting
> firmware blobs in the kernel and users needing to do stuff.
>
I would very much like to retain that option.. and having to manually
figure out what blob goes with wha
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > do you want something ala:
> >
> > config EXTRA_FIRMWARE
> > string
> > default ""
> > append "FOO" if BAR
> > append "FOZ" if BAZ
> >
> > or maybe a new
On Mon, 2011-08-29 at 19:17 +0200, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> > do you want something ala:
> >
> > config EXTRA_FIRMWARE
> > string
> > default ""
> > append "FOO" if BAR
> > append "FOZ" if BAZ
> >
> > or maybe a ne
On Mon, Aug 29, 2011 at 12:28:31PM -0400, Kyle Moffett wrote:
> No, Linus pushed back really hard last time this issue came up with
> something; a network driver if I recall correctly.
r8169 probably.
> The issue is that this happens *EVEN FOR MODULAR DRIVERS* during
> suspend/resume. The firmwa
On Mon, Aug 29, 2011 at 12:10:45PM -0400, Arnaud Lacombe wrote:
> do you want something ala:
>
> config EXTRA_FIRMWARE
> string
> default ""
> append "FOO" if BAR
> append "FOZ" if BAZ
>
> or maybe a new type "list" which would behave as a comma/space separated
> value.
>
> conf
On Mon, Aug 29, 2011 at 09:48, Alex Deucher wrote:
> 2011/8/29 Borislav Petkov :
>> On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
>>> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
>>> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>>> > > > l
Hi,
On Mon, Aug 29, 2011 at 11:55 AM, Borislav Petkov wrote:
> On Mon, Aug 29, 2011 at 11:47:24AM -0400, David Airlie wrote:
>> > On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
>> > > >> Should we make Kconfig pop up a dialog and ask for the
>> > > >> whereabouts of
>> > > >> these
On Mon, Aug 29, 2011 at 11:47:24AM -0400, David Airlie wrote:
> > On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
> > > >> Should we make Kconfig pop up a dialog and ask for the
> > > >> whereabouts of
> > > >> these firmware thingies when you mark the driver =y?
> > > >>
> > > >> Thi
- Original Message -
> From: "Borislav Petkov"
> To: "Alex Deucher" , "Dave Airlie"
> Cc: "Peter Zijlstra" , "Michel Dänzer"
> , "linux-kernel"
> , dri-devel@lists.freedesktop.org, "Pavel
> Ivanov&q
On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
> >> Should we make Kconfig pop up a dialog and ask for the whereabouts of
> >> these firmware thingies when you mark the driver =y?
> >>
> >> This all sounds like magic to me, having to know you need to add to
> >> EXTRA_FIRMWARE, havin
On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> > > > loaded from userspace, so it needs to be built into the kernel as well.
> > >
> > > How sho
On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
> > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> > > loaded from userspace, so it needs to be built into the kernel as well.
> >
> > How should I do that? I've tried to set all "m"s to "y" in .config and
> > still
2011/8/29 Borislav Petkov :
> On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
>> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
>> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>> > > > loaded from userspace, so it needs to be built into the ker
2011/8/29 Borislav Petkov :
> On Mon, Aug 29, 2011 at 03:20:21PM +0200, Peter Zijlstra wrote:
>> On Sun, 2011-08-28 at 07:36 +0200, Borislav Petkov wrote:
>> > > > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>> > > > loaded from userspace, so it needs to be built into the ker
On Mon, 2011-08-29 at 07:49 +0200, Borislav Petkov wrote:
> On Sun, Aug 28, 2011 at 05:47:59PM -0400, Pavel Ivanov wrote:
> > On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov wrote:
> > >> > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> > >> > loaded from userspace, so it n
On Sun, Aug 28, 2011 at 05:47:59PM -0400, Pavel Ivanov wrote:
> On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov wrote:
> >> > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
> >> > loaded from userspace, so it needs to be built into the kernel as well.
> >>
> >> How should I do
On Sun, Aug 28, 2011 at 1:36 AM, Borislav Petkov wrote:
>> > With CONFIG_DRM_RADEON=y, the microcode is needed before it can be
>> > loaded from userspace, so it needs to be built into the kernel as well.
>>
>> How should I do that? I've tried to set all "m"s to "y" in .config and
>> still saw thi
On Sat, Aug 27, 2011 at 06:50:37PM -0400, Pavel Ivanov wrote:
> 2011/8/27 Michel Dänzer :
> >> I observe very strange behavior dependent on value of
> >> CONFIG_DRM_RADEON parameter. When it's set to m everything works very
> >> good, no problem. When I set it to y I see kernel hang during boot. Or
2011/8/27 Michel Dänzer :
> On Sam, 2011-08-27 at 00:20 -0400, Pavel Ivanov wrote:
>> I observe very strange behavior dependent on value of
>> CONFIG_DRM_RADEON parameter. When it's set to m everything works very
>> good, no problem. When I set it to y I see kernel hang during boot. Or
>> I should
2011/8/27 Michel Dänzer :
>> I observe very strange behavior dependent on value of
>> CONFIG_DRM_RADEON parameter. When it's set to m everything works very
>> good, no problem. When I set it to y I see kernel hang during boot. Or
>> I should better say it "almost hangs" because during last boot att
On Sam, 2011-08-27 at 00:20 -0400, Pavel Ivanov wrote:
>
> I observe very strange behavior dependent on value of
> CONFIG_DRM_RADEON parameter. When it's set to m everything works very
> good, no problem. When I set it to y I see kernel hang during boot. Or
> I should better say it "almost hangs"
29 matches
Mail list logo
