On Wed, 17 Jul 2013 11:50:11 -0600
Daniel Drake wrote:
> I am now facing a problem with i2c/TDA998x which Russell already noted:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
>What *can't* be done without a rewrite of the DRM slave encoder backend
>is to have
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer wrote:
> You don't have to call drm_irq_install(). Both the exynos and i.MX
> driver do without it and at least the i.MX driver uses multiple irqs per
> drm_device.
Good point, thanks. That unblocks that item.
>> Secondly, devm. I understand from the
On Wed, 17 Jul 2013 11:50:11 -0600
Daniel Drake wrote:
> I am now facing a problem with i2c/TDA998x which Russell already noted:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039632.html
>What *can't* be done without a rewrite of the DRM slave encoder backend
>is to have
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer wrote:
> You don't have to call drm_irq_install(). Both the exynos and i.MX
> driver do without it and at least the i.MX driver uses multiple irqs per
> drm_device.
Good point, thanks. That unblocks that item.
>> Secondly, devm. I understand from the
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> > Based on the outcomes of the "Best practice device tree design for display
> > subsystems" discussion I have drafted a DT binding. Comments much
> > appreciated.
> >
> > At a
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to,
Hi,
On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote:
> On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> >>> I wasn't aware of
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the driver to bind
> to,
On Mon, Jul 15, 2013 at 02:23:30PM -0600, Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> > Based on the outcomes of the "Best practice device tree design for display
> > subsystems" discussion I have drafted a DT binding. Comments much
> > appreciated.
> >
> > At a
Hi,
On Sunday 14 of July 2013 00:09:55 Russell King - ARM Linux wrote:
> On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> > On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> >> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> >>> I wasn't aware of
On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
>>> they're working on v
On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
they're working on v4 with clock object reference counting. Presumably we
need both clk_get() to b
On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
> they're working on v4 with clock object reference counting. Presumably we
> need both clk_get() to be taking reference on the module and reference
> coun
On Sat, Jul 13, 2013 at 07:44:58PM +0200, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>> You'll see some eviden
On 07/13/2013 07:44 PM, Sebastian Hesselbarth wrote:
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Ju
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
On 07/13/2013 04:25 PM, Daniel Drake wrote:
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
modules. I set 3 clocks in the DT for the LCD0: lcdcl
On Sat, Jul 13, 2013 at 08:25:15AM -0600, Daniel Drake wrote:
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.
I don't see much need at the moment for IRE. IRE isn't going to be
useful for general graphics r
On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
>> they're working on v4 with clock object reference counting. Presumably we
>> need both clk_ge
On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
>>> they're working on v
On 07/13/2013 07:44 PM, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
>>> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>>
On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
> they're working on v4 with clock object reference counting. Presumably we
> need both clk_get() to be taking reference on the module and reference
> coun
On Sat, Jul 13, 2013 at 07:44:58PM +0200, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>> You'll see some eviden
On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
> On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
>> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
On 07/13/2013 04:25 PM, Daniel Drake wrote:
> On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine
> wrote:
>> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
>> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
>> modules. I set 3 clocks in the DT for the
On Sat, Jul 13, 2013 at 08:25:15AM -0600, Daniel Drake wrote:
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.
I don't see much need at the moment for IRE. IRE isn't going to be
useful for general graphics r
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
>> wrote:
>>> - the phandles to the clocks does not tell how the clock may be set by
>>>the driver (it is an array index in th
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
>>> wrote:
>
- the phandles to the clocks does not tel
On Fri, 12 Jul 2013 13:00:23 -0600
Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
> wrote:
> > - the phandles to the clocks does not tell how the clock may be set by
> > the driver (it is an array index in the 510).
>
> In the other threads on clock selection,
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
> (si5351). Normally,
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
>>> wrote:
>
- the phandles to the clocks does not tel
On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
- the phandles to the clocks does not tell how the clock may be set by
the driver (it is an array index in the 510).
In
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
> (si5351). Normally,
On Fri, 12 Jul 2013 13:00:23 -0600
Daniel Drake wrote:
> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
> > - the phandles to the clocks does not tell how the clock may be set by
> > the driver (it is an array index in the 510).
>
> In the other threads on clock selection, we
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
> sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
> named in the spec.
I agree it is worth keeping the spec-defined names, if they do
On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake wrote:
> Hi,
>
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the dri
Hi,
Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls a
On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake wrote:
> Hi,
>
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the dri
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
> sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
> named in the spec.
I agree it is worth keeping the spec-defined names, if they do
Hi,
Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls a
40 matches
Mail list logo
