Hi Hector,
On Thu, Jul 11, 2013 at 09:30:34AM +0200, Hector Palacios wrote:
> Greetings,
>
> Linux 2.6.35 had a driver for sysfs access to the MXS persistent
> bits (drivers/misc/mxs-persistent.c).
Freescale's 2.6.35 I suspect, right?
> I haven't seen this is supported upstream. Is anybody work
Hi Hector,
On Thu, Jul 11, 2013 at 10:56:42AM +0200, Hector Palacios wrote:
> On 07/11/2013 10:24 AM, maxime.rip...@free-electrons.com wrote:
> >>I haven't seen this is supported upstream. Is anybody working on that?
> >>Where would such a driver fit?
> >
>
On Wed, Jul 03, 2013 at 10:55:05AM +0200, maxime.rip...@free-electrons.com
wrote:
> Hi Jean-Christophe,
>
> On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote:
> > For a combination of 18bit LCD data bus width and a color
> > mode of 32bpp, the driver was sett
Hi Marc, Fan,
On Fri, Sep 13, 2013 at 10:30:49AM +0100, Marc Zyngier wrote:
> On 13/09/13 09:49, cinifr wrote:
> > On 13 September 2013 00:39, Marc Zyngier wrote:
> > I am wondering what is the principle between kernel and bootload?
> > What should be done in bootloader and what should be don
Hi,
On Mon, Sep 23, 2013 at 10:43:55PM +0800, cinifr wrote:
> > In which case this kernel patch needs instead to speak the bootloader
> > wakeup protocol instead of speaking to the h/w directly like you've done
> > here, right?
> >
> > Or is it possible for the bootloader to set these things up an
Hi Hector,
On Fri, May 24, 2013 at 03:33:19PM +0200, Juergen Beisert wrote:
> Someone told me, Qt5 cannot handle this special RGB666 mode (even not the
> def_rgb666_shift memory layout mentioned above). My test are based on Qt4.
> Qt5 needs a regular RGB888 mode, which should silently be convert
On Fri, Jun 07, 2013 at 09:28:32AM +0200, Hector Palacios wrote:
> I wasn't sure that everybody involved agreed with the patch.
> @Juergen, would the patch break your platform?
> Additionally, the guys from Crystalfontz didn't comment on it, but
> their platform is also using a 18bit data bus width
Hi Hector,
On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote:
> For a combination of 18bit LCD data bus width and a color
> mode of 32bpp, the driver was setting the color mapping to
> rgb666, which is wrong, as the color in memory realy has an
> rgb888 layout.
>
> This patch also r
Hi Hector,
On Fri, Jun 07, 2013 at 11:02:28AM +0200, maxime.rip...@free-electrons.com
wrote:
> On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote:
> > For a combination of 18bit LCD data bus width and a color
> > mode of 32bpp, the driver was setting the color mappin
Hi Jean-Christophe,
On Tue, Jun 18, 2013 at 10:44:17AM +0200, Hector Palacios wrote:
> For a combination of 18bit LCD data bus width and a color
> mode of 32bpp, the driver was setting the color mapping to
> rgb666, which is wrong, as the color in memory realy has an
> rgb888 layout.
>
> This pat
Hi Hector,
On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
> Hello,
>
> I'm using an i.MX28 based board with lcd connected with 18bits data bus.
> My platform uses 32 bits per pixel:
>
> mxsfb_pdata.default_bpp = 32;
> mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
>
>
Hi Juergen,
On Thu, May 23, 2013 at 03:31:31PM +0200, Juergen Beisert wrote:
> Hi Maxime,
>
> maxime.rip...@free-electrons.com wrote:
> > On Thu, May 23, 2013 at 01:55:28PM +0200, Hector Palacios wrote:
> > > I'm using an i.MX28 based board with lcd connected w
On Sat, Jul 30, 2016 at 10:52:45PM +0800, Icenowy Zheng wrote:
> > + if (of_device_is_compatible(pdev->dev.of_node,
> > + "allwinner,sun6i-a31-spdif")) {
> > + host->rst = devm_reset_control_get_optional(&pdev->dev, NULL);
> > + if (IS_ERR(host->rst) && PTR_ERR(host->rst) == -EPROBE_DEFER) {
> > +
Hi,
On Fri, Dec 11, 2015 at 05:50:22PM +0530, Vineet Gupta wrote:
> >> (2) It seems that disabling autoen by default for percpu irq makes sense as
> >> evident from drivers/net/ethernet/marvell/mvneta.c where users want to
> >> control
> >> this. However the comment there is misleading
> >>
> >>
On Tue, Jul 05, 2016 at 04:33:31PM +0800, Icenowy Zheng wrote:
>
>
> 05.07.2016, 13:26, "Michael Haas" :
> > Hi,
> >
> > nice work! Is this in any way related to Bruno Prémonts driver for the
> > axp20x?
> >
> > I've got a reworked version of that lying around, but it's not quite
> > ready for su
Hi,
On Sat, Mar 11, 2017 at 03:07:55PM +0100, Quentin Schulz wrote:
> Hi Icenowy,
>
> On 10/03/2017 20:25, Icenowy Zheng wrote:
> >
> >
> > 10.03.2017, 18:56, "Quentin Schulz" :
> >> This patch adds documentation for the A33 GPADC binding.
> >>
> >> Signed-off-by: Quentin Schulz
> >> ---
> >>
On Thu, Mar 02, 2017 at 11:13:53PM +0800, Icenowy Zheng wrote:
>
>
> 02.03.2017, 22:09, "Maxime Ripard" :
> > On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote:
> >> > I'm a bit worried by that to be honest. You claim to support the A31,
> >> > yet jugdging by the current state of t
17 matches
Mail list logo
