Hey Rob!
On Wed, Aug 31, 2016 at 1:01 AM, Rob Herring wrote:
> On Tue, Aug 30, 2016 at 4:12 PM, David Herrmann
> wrote:
>> Currently I see at least 3 paths that might add such nodes:
>>
>> - of_platform_populate()
>
> If we assume the node is only under chosen, then that would require a
> call
Hi
On Tue, Aug 30, 2016 at 10:58 PM, Rob Herring wrote:
> On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann
> wrote:
>> Sure, all those functions are not meant to be called in parallel by
>> multiple tasks. They are rather meant to have a single holder which
>> preferably is the one instantiating
Hi David,
On Tue, Aug 30, 2016 at 09:30:44PM +0200, David Herrmann wrote:
> Hi Rob
> IOW the device handover code somehow needs to know who was responsible
> for the instantiation of the simple-framebuffer device, so it can tell
> them to remove it again. On x86 there is only one place where those
Hi Rob
On Fri, Aug 26, 2016 at 2:36 PM, Rob Herring wrote:
> On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann
> wrote:
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evict_firmware(), and takes a flagset
On Tue, Aug 30, 2016 at 4:12 PM, David Herrmann
wrote:
> Hi
>
> On Tue, Aug 30, 2016 at 10:58 PM, Rob Herring wrote:
>> On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann
>> wrote:
>>> Sure, all those functions are not meant to be called in parallel by
>>> multiple tasks. They are rather meant to
On Tue, Aug 30, 2016 at 2:30 PM, David Herrmann
wrote:
> Hi Rob
>
> On Fri, Aug 26, 2016 at 2:36 PM, Rob Herring wrote:
>> On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann
>> wrote:
>>> Provide a generic DRM helper that evicts all conflicting firmware
>>> framebuffers, devices, and drivers. The
On Fri, Aug 26, 2016 at 02:58:51PM +0200, Hans de Goede wrote:
> Hi,
>
> On 26-08-16 14:52, Maxime Ripard wrote:
> >On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 26-08-16 10:58, Maxime Ripard wrote:
> >>>Hi,
> >>>
> >>>On Fri, Aug 26, 2016 at 10:43:55AM +0200,
Hi,
On Fri, Aug 26, 2016 at 02:00:56AM +0200, David Herrmann wrote:
> Also: Does any platform make use the of 'display:' entry in
> 'simple-framebuffer'
> DT nodes? If yes, how do I get access to it? And why don't vc4/sun4i make use
> of
> it, rather than falling back to remove_conflicting_frame
Hi,
On 26-08-16 14:52, Maxime Ripard wrote:
> On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 26-08-16 10:58, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
>> I'm not sure we would want to remove the device at
On Fri, Aug 26, 2016 at 11:02:17AM +0200, Hans de Goede wrote:
> Hi,
>
> On 26-08-16 10:58, Maxime Ripard wrote:
> >Hi,
> >
> >On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
> I'm not sure we would want to remove the device at all, we
> certainly should not be removing the
On Fri, 26 Aug 2016, David Herrmann wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.
Reading the subject, I thought this w
Hi,
On 26-08-16 10:58, Maxime Ripard wrote:
> Hi,
>
> On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
I'm not sure we would want to remove the device at all, we
certainly should not be removing the dt_node from the devicetree
IMHO. Having that around to see how the bo
Hi,
On Fri, Aug 26, 2016 at 10:43:55AM +0200, Hans de Goede wrote:
> >>I'm not sure we would want to remove the device at all, we
> >>certainly should not be removing the dt_node from the devicetree
> >>IMHO. Having that around to see how the bootloader set things up
> >>is really useful for debug
Hi,
On 26-08-16 10:01, David Herrmann wrote:
> Hi
>
> On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 26-08-16 02:00, David Herrmann wrote:
>>>
>>> Provide a generic DRM helper that evicts all conflicting firmware
>>> framebuffers, devices, and drivers. The new helper is cal
Hi
On Fri, Aug 26, 2016 at 9:57 AM, Hans de Goede wrote:
> Hi,
>
> On 26-08-16 02:00, David Herrmann wrote:
>>
>> Provide a generic DRM helper that evicts all conflicting firmware
>> framebuffers, devices, and drivers. The new helper is called
>> drm_evict_firmware(), and takes a flagset controll
Hi,
On 26-08-16 02:00, David Herrmann wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.
>
> This is meant to be used by driv
On Fri, Aug 26, 2016 at 2:00 AM, David Herrmann
wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.
>
> This is meant to be u
On Thu, Aug 25, 2016 at 7:00 PM, David Herrmann
wrote:
> Provide a generic DRM helper that evicts all conflicting firmware
> framebuffers, devices, and drivers. The new helper is called
> drm_evict_firmware(), and takes a flagset controlling which firmware to
> kick out.
>
> This is meant to be u
Provide a generic DRM helper that evicts all conflicting firmware
framebuffers, devices, and drivers. The new helper is called
drm_evict_firmware(), and takes a flagset controlling which firmware to
kick out.
This is meant to be used by drivers in their ->probe() callbacks of their
parent bus, bef
19 matches
Mail list logo
