On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote:
> I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> want.
That would be great, although given the potentially inconsistent
results we've been seeing so far it would be great if you could
additionally push a git bra
Hi Maxime,
On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so
> it
> seems that I fixed it along the way
Is your latest work available in a git branch anywhere that we could
test directly?
Thanks
Daniel
_
Hi Laurent,
On 11/06/2019 19:11, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:08PM +0100, Michael Drake wrote:
>> This may be used by userspace to determine the state
>>
Hi Laurent,
On 11/06/2019 19:13, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:09PM +0100, Michael Drake wrote:
>> Adds device tree bindings for:
>>
>> TI DS90UB949
Hi Laurent,
On 11/06/2019 19:07, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:04PM +0100, Michael Drake wrote:
>> The config property can be used to provide an array of
>>
Hi Laurent,
On 11/06/2019 19:10, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:07PM +0100, Michael Drake wrote:
>> If the alive check detects a transition to the alive st
Hi Laurent,
On 11/06/2019 19:03, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback! I'm sorry it's
taken me a while to respond to it.
> On Tue, Jun 11, 2019 at 03:04:02PM +0100, Michael Drake wrote:
>> A
This simply runs the function once every 5 seconds, while the
device is supposed to be active. The alive check function is
currently simply a stub, that logs it has been called, and
re-inserts itself into the work queue.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
/
ACPI nodes to set up any device dependency chain. (ACPI requiring
the special DT namespace link device ID, PRP0001.) The unified
device properties API is used to get board-specific config from
device tree / ACPI.
Cc: Patrick Glaser
Cc: Nate Case
Michael Drake (11):
dt-bindings: display
The config property can be used to provide an array of
register addresses and values to be written to configure
the device for the board.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
.../bindings/display/bridge/ti,ds90ub949.txt| 13 +
1 file changed
-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/ti948.c | 106 -
1 file changed, 105 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti948.c b/drivers/gpu/drm/bridge/ti948.c
index c22252036bbe..9cb37215f049 100644
If the alive check detects a transition to the alive state,
the device configuration is rewritten.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/ti948.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers
This may be used by userspace to determine the state
of the device.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/ti948.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti948.c
-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/ti949.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti949.c b/drivers/gpu/drm/bridge/ti949.c
index 04618ca5f25e..57dcecd10ace 100644
--- a/drivers
are enabled on probe and PM resume.
They are disabled on remove and PM suspend.
Datasheet: http://www.ti.com/lit/ds/symlink/ds90ub949-q1.pdf
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/Kconfig | 8 +
drivers/gpu/drm/bridge/Makefile | 1
Adds device tree bindings for:
TI DS90UB948-Q1 2K FPD-Link III to OpenLDI Deserializer
The device has the compatible string "ti,ds90ub948", and
and allows an arrray of strings to be provided as regulator
names to enable for operation of the device.
Signed-off-by: Michael Drake
C
The config property can be used to provide an array of
register addresses and values to be written to configure
the device for the board.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
.../bindings/display/bridge/ti,ds90ub948.txt | 21 +++
1 file changed
enabled on probe and PM resume.
They are disabled on remove and PM suspend.
Datasheet: http://www.ti.com/lit/ds/symlink/ds90ub948-q1.pdf
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
drivers/gpu/drm/bridge/Kconfig | 8 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers
enable for operation of the device.
Signed-off-by: Michael Drake
Cc: Patrick Glaser
Cc: Nate Case
---
.../bindings/display/bridge/ti,ds90ub949.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90ub949.txt
di
Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work
Hi,
Using libdrm-2.4.97, mesa fails to build on ARM with:
[ 456s] In file included from
../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
[ 456s] from
../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
[ 456s] from
../../../../.
Hi,
On Mon, Oct 8, 2018 at 1:48 PM Daniel Drake wrote:
> I recently filed a bug report regarding graphics corruption seen on
> Gemini Lake platforms:
> https://bugs.freedesktop.org/show_bug.cgi?id=108085
>
> This has been reproduced on multiple distros on products from at least
Hi,
I recently filed a bug report regarding graphics corruption seen on
Gemini Lake platforms:
https://bugs.freedesktop.org/show_bug.cgi?id=108085
This has been reproduced on multiple distros on products from at least
4 vendors. It seems to apply to every GeminiLake product that we have
seen.
Th
WHi Alex,
On Thu, Apr 19, 2018 at 4:13 PM, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=105684
>>>
>>> No progress made on that bug report so far.
>>> What can we do to help this advance?
>>
>> Ping, any news here? How can we help advance on this bug?
>
> Can you try one
On Tue, Apr 3, 2018 at 11:31 AM, Daniel Drake wrote:
> On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake wrote:
>> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>>>> It seems that we are not alone seeing amdgpu-induced stability
>>>> problems on multiple
On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake wrote:
> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>>> It seems that we are not alone seeing amdgpu-induced stability
>>> problems on multiple Raven Ridge platforms.
>>> https://www.phoronix.com/scan.php?pag
Hi Alex,
On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>> It seems that we are not alone seeing amdgpu-induced stability
>> problems on multiple Raven Ridge platforms.
>> https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven-Ridge-Mobo-Linux
>>
>> AMD, what can we do to help?
>
>
Hi,
> >>> We are working with new laptops that have the AMD Ravenl Ridge
> >>> chipset with this `/proc/cpuinfo`
> >>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
> >>>
> >>> With the latest kernel 4.15, there're lots of different
> >>> panics/oops during boot so no c
From: Yue Hin Lau
Signed-off-by: Yue Hin Lau
Reviewed-by: Eric Bernstein
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
[dr...@endlessm.com: backport to 4.15]
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 2 +-
drivers/gpu/drm/amd/display
Hi,
Thanks for the hard work on AMD DC development! Here are some new test
results - hope they are interesting/useful.
CONTEXT
We have been tracking DC for a while as we work with multiple products
where amdgpu previously was not able to support the HDMI audio output.
We are hoping to ship the
On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu wrote:
> We are working with new desktop that have the NVIDIA NV118
> chipset.
>
> During boot, the display becomes unusable at the point where the
> nouveau driver loads. We have reproduced on 4.8, 4.11 and linux
> master (4.12-rc3).
To save digging int
On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä
wrote:
> On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
>> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
>> wrote:
>> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
>>
Hi,
We are working with new laptops that have the AMD Bristol Ridge
chipset with this SoC:
AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
I think this is the Bristol Ridge chipset.
During boot, the display becomes unusable at the point where the
amdgpu driver loads. You can see at least two ho
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
wrote:
> Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference
when there is no VBT at all at which point
Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a
regression on Linux 4.9 where the VGA output is shown all-white.
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596
Author: Ville Syrjälä
Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: C
ne.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote:
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> Additionally the patch leaves cleanup o
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter wrote:
> On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote:
>> 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
>> drm_mode_set_config_internal() in order to turn off the CRTC, dropping
>> another ref
On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote:
> I think fb refcounting in exynos is just plain busted. If you look at
> other drivers the only place the refcount framebuffers or backing
> storage objects is for pageflips to make sure the memory doesn't go
> away while the hw is still scann
On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim
wrote:
> It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.
My patch moves that drm_framebuffer_reference() call to the plane
function which is called from crtc_mode_set context (and also called
in crtc pageflip path), s
,
but rather in the context of updating the plane, which also covers
flips. Like omapdrm we also unreference the old framebuffer here.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 8
2 files
Hi Sean,
While looking at the following commit I noticed something:
commit f041b257a8997c8472a1013e9f252c3e2a1d879e
Author: Sean Paul
Date: Thu Jan 30 16:19:15 2014 -0500
drm/exynos: Remove exynos_drm_hdmi shim
This commit changes how mixer_check_mode() is used. It used to just
exclude
Hi Sean,
In your commit "drm/exynos: hdmi: support extra resolutions using
drm_display_mode timings" you added several more HDMI PHY configs to
exynos-drm. Thanks for that.
Can you explain where these magic numbers came from?
I'm interested in adding 85.5MHz for 1366x768 support.
Thanks,
Danie
a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 insertion(+)
Replaces the patch titled "video: hdmi: request underscan by default"
This version moves the change to the DRM layer, as
a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake
---
drivers/video/hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..6c2d924 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/
that the underlying clock gating register has the
same value in both cases.
Anyway, the mixer clearly has some kind of dependency on the HDMI
component, so lets make sure we power that up first.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 -
1 file ch
On Wed, Dec 18, 2013 at 2:18 PM, Daniel Drake wrote:
> Yes, this looks very similar to the approach I tried earlier. I guess
> the patch was written for the same reasons as well.
> Sean, any objections to me taking your patch and sending it upstream?
>
> http://git.chromiu
On Wed, Dec 18, 2013 at 1:58 PM, Daniel Kurtz wrote:
> +seanpaul
>
> I think the problem is that the hdmi irq is really just an undebounced
> gpio interrupt, and thus, it is firing way too soon.
> The chromium kernel adds an excplicit 1.1 second timer to debounce hpd
> between the hdmi hpd-gpio ir
On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter wrote:
> I think we can do it simpler. When you get a hpd interrupt you eventually
> call drm_helper_hpd_irq_event which will update all the state and poke
> connectors. I'd just create a delay_work which you launch from
> hdmi_irq_thread with a 1 sec
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter wrote:
> Have a bit of logic in the exynos ->detect function to re-try a 2nd
> round of edid probing after each hdp interrupt if the first one
> returns an -ENXIO. Only tricky part is to be careful with edge
> detection so that userspace gets all the
On Mon, Dec 16, 2013 at 4:19 PM, Daniel Vetter wrote:
> This usually happens if the hpd isn't properly recessed and we start
> the i2c transaction while the physical connection hasn't been
> established properly yet. If you're _really_ slow and careful you can
> probably even break your current de
Resend with correct addresses for Eugeni and Chris...
On Mon, Dec 16, 2013 at 3:47 PM, Daniel Drake wrote:
> Hi,
>
> I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV.
>
> When I disconnect and then re-plug the TV, Exynos detects this event
> and tries to rea
Hi,
I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV.
When I disconnect and then re-plug the TV, Exynos detects this event
and tries to read the EDID from the DDC over I2C.
The DDC does not provide an ACK at this point, so the i2c-s3c2410
driver reports ENXIO, which seems to agree
On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake wrote:
> Lets just accept the fact that the first line of the output image is
> rendered badly. Specifically, it has 257 black pixels added onto the
> end of it. The following rows do not exhibit that problem.
>
> To accept and ignore
On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake wrote:
> What I feel we are missing here is an explanation for why the first
> row of pixels is treated differently from the rest. Every value that I
> tweak seems to have an effect on the first line (which was rendered
> OK) as well as al
On Wed, Dec 4, 2013 at 12:14 PM, Sean Paul wrote:
> I assume this is the "1024x768 at 60Hz" mode in drm_edid.c?
>
> hdisplay = 1024
> hsync_start = 1048
> hsync_end = 1184
> htotal = 1344
> vdisplay = 768
> vsync_start = 771
> vsync_end = 777
> vtotal = 806
That's the one.
> I don't have any doc
Hi,
Thanks a lot for this exynos-drm commit:
commit 62747fe0ad5169a767987d9009e3398466555cde
Author: Sean Paul
Date: Tue Jan 15 08:11:08 2013 -0500
drm/exynos: hdmi: support extra resolutions using drm_display_mode timings
As you probably know, many people had written off the Exynos4's
c
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 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 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 somet
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 somet
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 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, 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
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
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a
On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe. This is why I will not
> adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a
On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe. This is why I will not
> adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
>> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
>> aka PXA2128). After a bit of fighting, I have it running. Could you shar
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
I thought there was some agreemen
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
>> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
>> aka PXA2128). After a bit of fighting, I have it running. Could you shar
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine
wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
I thought there was some agreeme
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your wo
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your wo
89 matches
Mail list logo
