On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
NAK.
(I did write a better email explaining all the ins and outs of why thi
On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> A new atomic modeset/pagefli
On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
> warning when they try something like:
Definitely not. Ttype of access is controlled by the
On Mon, Nov 12, 2012 at 06:31:50PM -0600, Rob Clark wrote:
> right, that is what I was worried about.. but what about something
> along the lines of:
>
> case 8: { \
> if (sizeof(x) < 8)
On Tue, Nov 13, 2012 at 09:11:09AM +, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Rob Clark wrote:
> > right, that is what I was worried about.. but what about something
> > along the lines of:
> >
> > case 8: { \
> >
On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrj?l? wrote:
> On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote:
> > On Thursday 15 November 2012, Rob Clark wrote:
> > > > I still haven't heard a conclusive argument why we need to use
> > > > get_user()
> > > > rather than copy_from
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
Not everything is finished off perfectly in this driver; there's quite
a number of ragged edges (particularly with page flipping, which is
completely un
On Fri, May 17, 2013 at 08:38:03AM +0200, Jean-Francois Moine wrote:
> The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
> after irq or some parameter change and this aborts the i2c exchanges.
>
> The problem is solved by masking these signals.
NAK. The real problem is in th
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> Hi Russell,
>
> I quickly compared your dove drm driver and ours (Sebastian and me):
I already said - I don't support DT. I don't run any DT based ARM
devices, so I have no experience with DT. What I care more about
is a wor
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> On Fri, 17 May 2013 13:01:15 +0100
> Russell King - ARM Linux wrote:
> > > - CMA helper
> > >
> > > You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> > >
On Fri, May 17, 2013 at 07:00:29PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I
On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
> The device for tda998x yes, but not the driver. Anyway, Russel decided
> to have tda998x probed by his drm_driver.
For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem
On Sat, May 18, 2013 at 07:45:02PM +0200, Jean-Francois Moine wrote:
> It seems we are moving backwards:
> - what about the display controller?
> - how do you clone the lcd 0 output to the port B?
> - what occurs when the si5351 and the tda998x are modules?
I've no idea why you keep bringing that
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> case. And, yes, I better like a hardware cursor: it asks for less
> computation, and
On Sat, May 18, 2013 at 08:56:59AM +0200, Jean-Francois Moine wrote:
> On Thu, 16 May 2013 20:26:18 +0100
> Russell King wrote:
>
> > When switching between various drivers for this device, it's possible
> > that some critical registers are left containing values which affect
> > the device opera
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> I quickly compared your dove drm driver and ours (Sebastian and me):
>
> - CMA helper
>
> You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> simplify some code.
Looking at the CMA helper code in DRM, it
So, while tinkering with my Dove DRM driver, I tripped over a BUG_ON()
in drm_mm_hole_node_start(), which was called from drm_mm_dump_table():
int drm_mm_dump_table(struct seq_file *m, struct drm_mm *mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, tot
On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
> This adds an irq handler for HPD to the tda998x slave encoder driver
> to trigger HPD change instead of polling. The gpio connected to int
> pin of tda998x is passed through platform_data of the i2c client. As
> HPD will ultim
On Sat, May 18, 2013 at 09:18:46PM +0200, Jean-Francois Moine wrote:
> The general hardware code of both drivers is close enough for merging
> may be done starting from anyone. But the general layout is not:
>
> - my driver is DT driven and has one card with 2 CTRC's and 2 connectors.
>
> - Russe
On Mon, May 20, 2013 at 09:36:02AM -0400, Alex Deucher wrote:
> You can tell the xserver what size cursor you support when you call
> xf86_cursors_init() in the ddx. Just expose a 32x64 or 64x32 ARGB
> cursor. Most apps don't use a 64x64 cursor anyway. I've used
> hardware with non-64x64 cursors
On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index fc2adb6..586c12f 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(
On Wed, Nov 13, 2013 at 08:53:18AM +0100, Eric B?nard wrote:
> Hi Russell,
>
> Le Tue, 12 Nov 2013 17:04:55 +,
> Russell King - ARM Linux a ?crit :
> > On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/
On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> On 11/13/2013 2:23 AM, Denis Carikli wrote:
>> + /* rgb666 */
>> +ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB
On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote:
> +static inline bool clk_is_match(struct clk *p, struct clk *q)
> +{
> + return p == q ? true : false;
When they created the C standard, they already taught the compiler that
p == q returns a true / false boolean value; there's n
On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> Would it be Ok to add a check that master->ops->add_components is defined,
> before calling it in find_componets() (drivers/base/component.c:120) and
> return 0 if it is not?
No:
http://ftp.arm.linux.org.uk/cgit/linux
On Fri, Mar 06, 2015 at 12:21:42PM +0200, Jyri Sarha wrote:
> On 03/06/15 11:58, Russell King - ARM Linux wrote:
> >On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> >>Would it be Ok to add a check that master->ops->add_components is defined,
> >>be
On Tue, Mar 10, 2015 at 12:21:21AM +0100, Heiko Stuebner wrote:
> At least the Rockchip variant of the dw_hdmi should control its supplying
> regulators. A cursory glance at the imx manual didn't any equivalent there,
> so I'm not sure if there are similar controllable regulators present.
>
> Patc
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> ARM randconfig build tests found a new error for configurations
> with COMMON_CLK disabled but HAS_CLK selected by the platform:
>
> ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
>
> This moves the declaratio
On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
> Hey Russell,
>
> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> > On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > > ARM randconfig build tests found a new
All,
This is a mini-series to try and move audio support for the Designware
HDMI bridge along.
There are two known versions of the Designware HDMI audio:
- The Rockchip version, which is based upon feeding the HDMI block I2S
stream(s), which doesn't have any on-board DMA support.
- The Freesca
On Mon, Mar 30, 2015 at 11:43:17AM +0200, Philipp Zabel wrote:
> Hi Russell,
>
> Am Freitag, den 27.03.2015, 11:13 + schrieb Russell King - ARM
> Linux:
> > All,
> >
> > This is a mini-series to try and move audio support for the Designware
> > HDMI bridg
I'm sending this series for comments, and to allow people to update
their code bases (for those who are using my AHB audio driver on
iMX6). This is really several series, and I'm not expecting this
to be ready for the upcoming merge window. That said, if anyone
wants to say that they're happy wit
On Tue, Mar 31, 2015 at 04:30:39AM -0400, Yang Kuankuan wrote:
> >+cs[0] = IEC958_AES0_CON_NOT_COPYRIGHT | IEC958_AES0_CON_EMPHASIS_NONE;
> >+cs[1] = IEC958_AES1_CON_GENERAL;
> >+cs[2] = IEC958_AES2_CON_SOURCE_UNSPEC | IEC958_AES2_CON_CHANNEL_UNSPEC;
> >+cs[3] = IEC958_AES3_CON_CLOC
On Tue, Mar 31, 2015 at 11:10:34AM +0200, Philipp Zabel wrote:
> This fails to build for me on 4.0-rc6:
> make[2]: *** No rule to make target 'sound/core/snd-pcm-iec958.o', needed by
> 'sound/core/snd-pcm.o'. Stop.
> scripts/Makefile.build:403: recipe for target 'sound/core' failed
Yes, I origin
On Tue, Mar 31, 2015 at 02:55:53AM -0400, Yang Kuankuan wrote:
> Hi Russell,
>
> I'm okay with this change, and also I am preparing that collect N/CTS
> setting to an array, like this :
>
> struct n_cts {
> unsigned int cts;
> unsigned int n;
> };
>
> struct tmds_n_ct
On Tue, Mar 31, 2015 at 05:02:20AM -0400, Yang Kuankuan wrote:
> Besides, as you are going an dw_hdmi cleanups, I want to point another bugs
> that relate to the HDMI CTS test. There are somethings wrong with General
> Control Pack, as for now the encoder color depth is 8-bit packing mode,
> so the
On Mon, Mar 09, 2015 at 05:42:21PM +0800, Yakir Yang wrote:
> RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
> and single-ended test would failed when display mode is 74.25MHz.
Has anyone reviewed these changes yet? I don't see any replies, nor
are they in David's git tree.
On Mon, Mar 09, 2015 at 05:43:19PM +0800, Yakir Yang wrote:
> As for 1920x1080 display resolution, we should turn on the
> Transmitter Trailer-B.
>
> Signed-off-by: Yakir Yang
> ---
BTW, one of:
drm/rockchip: dw_hdmi-rockchip: ...
drm/rockchip: dw_hdmi: ...
drm: rockchip: dw_hdmi-rockchip: .
On Wed, May 06, 2015 at 10:22:22AM -0400, Rob Clark wrote:
> Hey Russell,
>
> I just noticed a splat triggered by component_unbind_all() called from
> ->bind().. any opinions about whether component stuff should handle
> that case, or whether I should rearrange my error cleanup path to not
> comp
On Wed, May 06, 2015 at 12:45:04PM -0400, Rob Clark wrote:
> On Wed, May 6, 2015 at 12:01 PM, Russell King - ARM Linux
> wrote:
> > On Wed, May 06, 2015 at 10:22:22AM -0400, Rob Clark wrote:
> >> Hey Russell,
> >>
> >> I just noticed a splat triggere
On Wed, May 06, 2015 at 08:02:52PM +0300, Anssi Hannula wrote:
> 05.04.2015, 20:26, Russell King - ARM Linux kirjoitti:
> > On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
> >>
> >> One another question: don't we need to deal with the sample bits in
On Fri, May 08, 2015 at 01:56:02PM +0300, Jyri Sarha wrote:
> On 2015-04-05 20:26, Russell King - ARM Linux wrote:
> >On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote:
> >>At Sun, 5 Apr 2015 17:20:34 +0100,
> >>Russell King - ARM Linux wrote:
> >&g
On Fri, May 08, 2015 at 04:16:08PM +0300, Jyri Sarha wrote:
> On 2015-04-02 12:22, Russell King wrote:
> >+static const unsigned int eld_rates[] = {
> >+32000,
> >+44100,
> >+48000,
> >+88200,
> >+96000,
> >+176400,
> >+192000,
> >+};
> >+
>
> For what I can see, you ar
I'm sending this series again for comments, and to allow people to
update their code bases (for those who are using my AHB audio driver
on iMX6).
There have been very few changes from the previous posting, the
exception being the ELD helper in patch 10, which should be correctly
sorted now.
I wou
On Sat, May 09, 2015 at 07:49:44PM +0300, Anssi Hannula wrote:
> (Of course having userspace set them requires that the device has a
> proper entry in /usr/share/alsa/cards and the pcm device is accessed via
> the standard "hdmi" or "iec958" device names which perform the channel
> status word setu
On Sat, May 09, 2015 at 08:07:45PM +0300, Anssi Hannula wrote:
> 09.05.2015, 19:55, Russell King - ARM Linux kirjoitti:
> > On Sat, May 09, 2015 at 07:49:44PM +0300, Anssi Hannula wrote:
> >> (Of course having userspace set them requires that the device has a
> >> prop
On Sat, May 09, 2015 at 06:40:54PM +0100, Russell King - ARM Linux wrote:
> Even VLC _doesn't_ if it's outputting to a standard audio - in other
> words, if you don't tick the SPDIF direct output option which defaults
> to disabled (which, when enabled, opens the devic
On Sat, May 09, 2015 at 08:55:10PM +0300, Anssi Hannula wrote:
> 09.05.2015, 20:40, Russell King - ARM Linux kirjoitti:
> > Even VLC _doesn't_ if it's outputting to a standard audio - in other
> > words, if you don't tick the SPDIF direct output option which default
EC958_AES1_CON_PCM_CODER,
0, aes3) == -1)
Yes, technically an application bug, since VLC should allow the device
to be selectable and/or detect hdmi devices. I wonder if that's
something which has changed between 2.0.8 and the latest vlc.
I did consider having the hdmi outp
On Mon, Nov 16, 2015 at 02:44:52PM +, Liviu Dudau wrote:
> Rockchip DRM driver cannot use the same compare_of() function to match
> ports and remote ports (aka encoders) as their OF sub-trees look different.
> Add a second compare function to be used when encoders are added to the
> component f
I've tweaked your patch to make the above (buggy) change a little clearer.
On Mon, Nov 16, 2015 at 02:44:53PM +, Liviu Dudau wrote:
> - for (i = 0;; i++) {
> - port = of_parse_phandle(np, "ports", i);
> - if (!port)
> - break;
> -
> -
bother to reply if they have that kind of
additional work? Thanks.
On Mon, Nov 16, 2015 at 04:49:07PM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 04:22:41PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 16, 2015 at 02:44:52PM +, Liviu Dudau wrote:
> > > R
On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:22, Russell King - ARM Linux
> wrote:
> > Please sensibly wrap your messages. Your lines are longer than 80
> > characters which makes it exceedingly difficult for some people to reply
>
On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static one.
On Mon, Nov 16, 2015 at 05:48:32PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:43, Russell King - ARM Linux
> wrote:
> > On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> >> On 16 November 2015 at 17:22, Russell King - ARM Linux
> >> wrot
On Mon, Nov 16, 2015 at 09:17:35PM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 05:22:48PM +, Russell King - ARM Linux wrote:
> > Put those two sentences together and please think about it. If the
> > pointer type is unknown to component_match_add(), how could
On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux wrote:
> > > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> >
On Fri, Nov 20, 2015 at 04:44:55PM +, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 04:32:59PM +, Russell King - ARM Linux wrote:
> > On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> >
d for the next merge window. Please apply.
drivers/base/component.c | 281 --
include/linux/component.h | 33 --
2 files changed, 167 insertions(+), 147 deletions(-)
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/gpu/drm/armada/armada_gem.c
> index e3a86b96af2a..a43690ab18b9 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -46,7 +46
As of 3c3b177a9369 ("reservation: add suppport for read-only access
using rcu") linux/reservation.h uses lockdep macros:
+#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
This results in build errors when lockdep is disabled as lockdep_is_held()
is on
On Wed, Sep 30, 2015 at 11:49:44AM +0100, Emil Velikov wrote:
> Hi Russell,
>
> On 29 September 2015 at 19:10, Russell King
> wrote:
> > Rather than using a spinlock, use xchg() to atomically update
> > dplane->old_fb. This allows us to eliminate dplane->lock.
> >
> > Signed-off-by: Russell Kin
On Sat, Sep 26, 2015 at 05:32:12PM -0300, Fabio Estevam wrote:
> On Mon, Sep 21, 2015 at 11:15 AM, Russell King - ARM Linux
> wrote:
>
> > My current patch stack for imx-drm related stuff looks like this at
> > present:
> >
> > drm: bridge/dw_hdmi: place PHY
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + if (status & CEC_STATUS_TX_DONE) {
> + if (status & CEC_STATUS_TX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> + cec->tx = STATE_ERROR;
> + } else
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + cec->adap = cec_create_adapter(&s5p_cec_adap_ops, cec,
> + CEC_NAME, CEC_CAP_STATE |
> + CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
> + CEC_CAP_IS_SOURCE,
> + 0, THIS_MODU
mentation fixes, clenaup and expansion]
> [k.debski at samsung.com: reorder of API structs and add reserved fields]
> [k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
> problem]
> [k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild]
> [k.debski at
On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add handling of remote control events coming from the HDMI CEC bus.
> This patch includes a new keymap that maps values found in the CEC
> messages to the keys pressed and released. Also, a new protocol has
> b
he dts pieces. Are the dts patches available?
Sorry, I've been out for most of the day. There's no DT patches required.
The dw_hdmi bridge driver creates its own platform device for the audio,
which should then bind to the dw_hdmi-ahb-audio driver using normal Linux
methods.
I don&#
hought.
drivers/cec/Makefile | 1 +
drivers/cec/cec-dw_hdmi.c | 90
drivers/cec/hdmi-not.c | 61 +++
drivers/gpu/drm/bridge/dw_hdmi.c | 9
include/linux/hdmi-not.h | 39 +
5 files c
On Tue, Oct 06, 2015 at 03:45:32PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:18 PM, Russell King - ARM Linux
> wrote:
>
> > Sorry, I've been out for most of the day. There's no DT patches required.
> >
> > The dw_hdmi bridge driver creates
On Wed, Oct 07, 2015 at 09:48:42AM +0200, Arnaud Pouliquen wrote:
> Should ALSA bypasses or not the DRM core/API to access to DRM HDMI
> connector?
You don't need direct access to the connector - and actually, having
direct access to the connector is potentially racy. So no.
> Concerning bridge
On Wed, Oct 07, 2015 at 11:50:53AM +0800, Yakir Yang wrote:
>
>
> On 08/09/2015 12:04 AM, Russell King wrote:
> >On a mode set, DRM makes the following sequence of calls:
> >* for_each_encoder
> >* bridge mode_fixup
> >* encoder mode_fixup
> >* crtc mode_fixup
> >* for_each_e
On Wed, Oct 07, 2015 at 12:05:37PM +0800, Yakir Yang wrote:
>
>
> On 08/09/2015 12:04 AM, Russell King wrote:
> >The dw_hdmi enable/disable handling is particularly weak in several
> >regards:
> >* The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff()
> > while DRM is setting a mod
On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
> The virtgpu driver prints the last_seq variable using the %ld or
> %lu format string, which does not work correctly on all architectures
> and causes this compiler warning on ARM:
>
> drivers/gpu/drm/virtio/virtgpu_fence.c: In functi
On Wed, Oct 07, 2015 at 06:40:11PM +0800, Yakir Yang wrote:
>
>
> On 10/07/2015 05:48 PM, Russell King - ARM Linux wrote:
> >On Wed, Oct 07, 2015 at 12:05:37PM +0800, Yakir Yang wrote:
> >>
> >>On 08/09/2015 12:04 AM, Russell King wrote:
> >>>The dw
On Tue, Sep 29, 2015 at 07:08:43PM +0100, Russell King - ARM Linux wrote:
> Here are my queued changes for the Armada DRM driver, for the upcoming
> 4.4 merge window.
If there are no further comments (there was only one minor comment which
has been fixed), I'll send a pull request
On Tue, Sep 29, 2015 at 07:32:16PM +0100, Russell King - ARM Linux wrote:
> Hi,
>
> Here's my currently queued TDA998x development work for 4.4.
As there have been no comments against this series, I'll send David a
pull request later today.
>
> * Remove some useless N
On Tue, Oct 06, 2015 at 05:25:16PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:54 PM, Russell King - ARM Linux
> wrote:
>
> > Make sure you have the ALSA config file, as alsalib won't get on
> > with dw-hdmi only accepting 24-bit audio without this. A copy
On Fri, Oct 09, 2015 at 01:02:11PM -0300, Fabio Estevam wrote:
> On Fri, Oct 9, 2015 at 1:00 PM, Russell King - ARM Linux
> wrote:
>
> >> Thanks, Russell!
> >>
> >> Got audio to play on my HDMI TV :-)
> >>
> >> For the entire series:
>
On Mon, Oct 12, 2015 at 01:35:54PM +0200, Hans Verkuil wrote:
> On 10/06/2015 07:06 PM, Russell King - ARM Linux wrote:
> > Surely you aren't proposing that drivers should write directly to
> > adap->phys_addr without calling some notification function that the
> >
On Mon, Oct 12, 2015 at 01:50:47PM +0200, Hans Verkuil wrote:
> On 10/06/2015 08:05 PM, Russell King - ARM Linux wrote:
> > On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> >> From: Kamil Debski
> >>
> >> Add handling of remote control events com
On Mon, Oct 12, 2015 at 02:39:42PM +0200, Hans Verkuil wrote:
> On 10/12/2015 02:33 PM, Kamil Debski wrote:
> > The possible status values that are implemented in the CEC framework
> > are following:
> >
> > +/* cec status field */
> > +#define CEC_TX_STATUS_OK (0)
> > +#define CEC_T
On Sat, Jun 20, 2015 at 12:19:12AM +0800, Yakir Yang wrote:
> The exact relationship between the two clocks will be:
> 128 * SampleRate = TmdsClock * N / CTS.
> So this patch would generate the correct N/CTS values, add audio support
> for the below tmds clocks:
> 25.175MHz, 40MHz, 54MHz, 65
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Using types that differs on 32-bit and 64-bit machines for a kernel
> interface is indeed a rather bad idea. This not only includes longs, but
> pointers as well.
[cut standard stdint.h types argument which we've heard before]
Yo
But using the types from "include/linux/types.h" and especially including it
> into the uapi headers doesn't make the situation better, but rather worse.
>
> With this step we not only make the headers depend on another header that
> isn't part of the uapi, but also poll
e of, and then I thought I'd wait
> > for the merge window to get over before beginning to discuss this
> > again.
> >
> > On 11 February 2015 at 21:53, Russell King - ARM Linux
> > wrote:
> >> On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski
On Fri, Jun 05, 2015 at 07:56:38PM +0100, Chris Wilson wrote:
> On Fri, Jun 05, 2015 at 07:47:22PM +0100, Russell King wrote:
> > Writing to a file is supposed to return the number of bytes written.
> > Returning zero unfortunately causes bash to constantly spin trying
> > to write to the sysfs fil
On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote:
> Hi Thierry
>
> Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding:
> > If this is specific to the Rockchip implementation, shouldn't this go
> > into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It
> > could
On Mon, Jun 08, 2015 at 04:02:58PM +0200, Thierry Reding wrote:
> On Sat, Jun 06, 2015 at 12:10:58AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote:
> > > Hi Thierry
> > >
> > > Am Freitag, 5. Juni 2
On Mon, Jun 08, 2015 at 05:44:53PM +0200, Thierry Reding wrote:
> On Mon, Jun 08, 2015 at 03:29:26PM +0100, Russell King - ARM Linux wrote:
> > You're asking questions we have no real answers to - all we have is the
> > available documentation provided by Freescale - we
ritique on public mail, no need to keep things hidden. ;)
Unfortunately, a lot of discussion does happen on IRC - that's why there
exists a #etnaviv channel. It's not that it's hidden, it's just that
you're only there very rarely.
> Am Donnerstag, den 28.05.2015, 0
On Wed, Jun 10, 2015 at 01:29:43AM +0200, Heiko Stübner wrote:
> Allthough from the discussion and explanations I've now also got the "don't
> make it worse" feeling, so am somehow reluctant to add supplies that also
> might describe this inadequately.
>
> The Rockchip-specific documentation on
On Wed, Jun 10, 2015 at 01:07:08PM +0200, Nicholas Mc Guire wrote:
> The calling side seems to assume 0 as success and <0 as error so
> returning -ETIME should be fine here.
The idea here is to allow the remainder of the code to execute when
the condition succeeds _or_ times out. If it times out
On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
> If you plug in a DVI monitor to your HDMI port, you need to filter out
> clocks > 165MHz. That's because 165MHz is the maximum clock rate that
> we can run single-link DVI at.
>
> If you want to run high resolutions to DVI, you'd ne
On Wed, Jun 17, 2015 at 07:52:14PM -0700, Doug Anderson wrote:
> Russell,
>
> On Wed, Jun 17, 2015 at 4:30 PM, Russell King - ARM Linux
> wrote:
> > On Wed, Jun 17, 2015 at 04:14:07PM -0700, Doug Anderson wrote:
> >> If you plug in a DVI monitor to your HDMI p
On Thu, Jun 18, 2015 at 03:49:25PM +0800, Mark Yao wrote:
> We want to display a buffer allocated by other driver, need import
> the buffer to gem.
>
> Signed-off-by: Mark Yao
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c |1 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 45
> ++
Even with the oops fixed by a previous patch, the system still fails to
kexec, due to a stuck chained interrupt locking the system. We must
disable the child interrupts prior to setting up the irq chip to ensure
we don't get stuck here.
Signed-off-by: Russell King
---
Maybe this is all that's re
On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote:
> Russell,
>
> On Thu, Jun 18, 2015 at 1:53 AM, Russell King - ARM Linux
> wrote:
> >> OK, so clearly my patch won't work against mainline. I guess it's a
> >> good thing that I pointed ou
On Thu, Jun 18, 2015 at 04:55:45PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 18, 2015 at 08:26:39AM -0700, Doug Anderson wrote:
> > Perhaps you can try <https://patchwork.kernel.org/patch/5906771/>
>
> Something like that needs to be done, but let's get
On Sat, Jun 20, 2015 at 12:19:12AM +0800, Yakir Yang wrote:
> Just like HDMISpecification 1.4 document descripted, the soure shall
> determine the fractional relationship between the TMDS clock an an
> audio reference clock, the sink may then recreate the audio clock from
> the TMDS clock by using
1101 - 1200 of 1615 matches
Mail list logo
