k_prepare_enable(drc->mod_clk);
Am I reading this right: is this changing the init sequence so that
the clock is enabled before setting a rate?
This is the sort of thing that might cause glitches and issues in some
hardware, so it'd be polite to test such a change on the actual
hardware before posting it.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
eeds_mux;
> booldisable_strict_mode;
> - boolhas_io_bias_cfg;
> + int io_bias_cfg_variant;
Shouldn't we be defining this field using the enum rather than as an int?
Thanks,
--
Hi Jagan,
On Wed, Nov 7, 2018 at 5:13 AM Jagan Teki wrote:
>
> On Wed, Oct 31, 2018 at 2:46 PM Julian Calaby wrote:
> >
> > Hi Jagan,
> >
> > On Wed, Oct 31, 2018 at 7:58 PM Chen-Yu Tsai wrote:
> > >
> > > On Wed, Oct 31, 2018 at 4:53 PM Andrze
n a mystery and must be hard-coded
> to match the panel. That would work against having a generic bridge driver.
To me it seems logical that we'd model it as another step in the graph
between the DSI component and the panel. It's conceivable that some
other manufacturer will probab
>format->has_alpha ||
> + (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE)) &&
> + !backend->quirks->supports_lowest_plane_alpha)
From a readability perspective, it'd be fractionally nicer if the
quirk c
- pll-0: parent of phy clock
> + - pll-1: second possible phy clock parent (A64 only)
Maybe split this into two:
H3 HDMI PHY ...
- pll-0: ...
A64 HDMI PHY ...
- pll-0: ...
- pll-1: ...
At the moment a quick reading implies that H3 needs pll-1.
Thank
_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}
Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCO
Hi Jernej,
On Sun, May 20, 2018 at 11:57 AM, Julian Calaby wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mi
Hi Maxime,
On Tue, Feb 27, 2018 at 6:07 PM, Maxime Ripard
wrote:
> On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
>> Hi Jernej,
>>
>> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec
>> wrote:
>> > Hi,
>> >
>> > Dne ponedel
ut
>> >
>> >4k.
>> >
>> >> If this code is compatible with the H2+, could you please add the
>> >> necessary bits and pieces to the h2-plus DTSs too?
>> >
>> >There are only 3 H2+ boards in kernel and none of them has HDMI
>>
Hi Icenowy,
On Sun, Feb 25, 2018 at 7:43 PM, Icenowy Zheng wrote:
>
>
> 于 2018年2月25日 GMT+08:00 下午4:11:34, Julian Calaby 写到:
>>Hi Jernej,
>>
>>On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>> wrote:
>>> Enable HDMI output on all boards which have HDM
+
> 8 files changed, 199 insertions(+)
As I understand it, the H2+ is just a slightly trimmed down H3. In
terms of HDMI support, the difference is that the H2+ can't output 4k.
If this code is compatible with the H2+, could you please add the
necessary bits and pieces to the
& BIT(layer->id)) {
min_scale = 1;
max_scale = (1UL << 20) - 1;
}
However the compiler will probably sort it all out anyway, so it
probably doesn't matter that much, except for style.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www
Hi Chen-Yu,
On Tue, Oct 10, 2017 at 2:19 PM, Chen-Yu Tsai wrote:
> On systems with 2 TCONs such as the A31, it is possible to demux the
> output of the TCONs to one encoder.
>
> Add support for this for the A31.
>
> Signed-off-by: Chen-Yu Tsai
Thanks!
FWIW this is:
Reviewed
ed between
> the two TCONs. So there's no particular reason to look for TCON1 explicitly.
In that case: in the bizarre case where we're trying to use this mux
type and there is no TCON0, shouldn't we fail?
(Also, the code doesn't make sense if we have some TCON1
Hi Chen-Yu,
On Sat, Sep 30, 2017 at 3:58 PM, Chen-Yu Tsai wrote:
> On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby
> wrote:
>> Hi Chen-Yu,
>>
>> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai wrote:
>>> On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard
>>&g
_sync_sg_for_cpu,
> .sync_sg_for_device = sbus_sync_sg_for_device,
> + .dma_supported = sbus_dma_supported,
> };
>
> static int __init sparc_register_ioport(void)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles
for HDMI */
PLL_VIDEO*1*_2X, right?
> /* The CPU clock is exported */
>
> #define CLK_AXI18
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Julia,
On Mon, Dec 8, 2014 at 5:43 PM, Julia Lawall wrote:
> On Mon, 8 Dec 2014, Julian Calaby wrote:
>
>> Hi Julia,
>>
>> On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote:
>> > These patches replace what appears to be a reference to the name of the
>&g
there be any value in doing this for _all_ cases where the
function name is written in a format string?
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
/// matched code has to be contiguous
> ///
> /// Blatantly cribbed from: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
>
> @@
> type T, T2;
> expression x;
> expression E1,E2,E3;
> statement S;
> @@
>
> - x = (T)pci_alloc_consistent(E1,E2,E3);
> + x =
21 matches
Mail list logo
