hy-fsl-usb.c | 2 +-
for the drivers above:
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nicolas Boichat writes:
> On Thu, Jul 23, 2020 at 9:17 PM Felipe Balbi wrote:
>>
>> Nicolas Boichat writes:
>>
>> > trace_printk should not be used in production code, replace it
>> > call with dev_dbg.
>> >
>> > Signed-off-b
Nicolas Boichat writes:
> trace_printk should not be used in production code, replace it
> call with dev_dbg.
>
> Signed-off-by: Nicolas Boichat
>
> ---
>
> Unclear why a trace_printk was used in the first place, it's
> possible that some rate-limiting is necessary here.
>
> drivers/usb/cdns3/g
Hi,
Noralf Trønnes writes:
>> I missed this completely until now.
>> Noralf Trønnes writes:
>>> This adds the gadget side support for the Generic USB Display. It presents
>>> a DRM display device as a USB Display configured through configfs.
>>>
>>> The display is implemented as a vendor type U
Hi,
I missed this completely until now.
Noralf Trønnes writes:
> This adds the gadget side support for the Generic USB Display. It presents
> a DRM display device as a USB Display configured through configfs.
>
> The display is implemented as a vendor type USB interface with one bulk
> out endpo
Hi,
Joe Perches writes:
> drivers/usb/phy/phy-tahvo.c| 2 +-
Acked-by: Felipe Balbi
--
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Nov 19, 2014 at 03:13:20PM +0100, Julien CHAUVEAU wrote:
> We need to call clk_put on display clock, in the same way as functional clock.
>
> Signed-off-by: Julien CHAUVEAU
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gp
Hi,
On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote:
> On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote:
> > If we don't stup that call out, we will have
> > build failures for any drivers using that function
> > when .config happens to have CONFIG
On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote:
> If we don't stup that call out, we will have
> build failures for any drivers using that function
> when .config happens to have CONFIG_REGULATOR=n.
>
> One such case below, found with randconfig
>
> dr
es \
pointer from integer without a cast [-Werror]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
Signed-off-by: Felipe Balbi
---
include/linux/regulator/consumer.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/includ
On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote:
> On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > > OK, I guess this is as good as it gets.
> > > > >
> > > > > What tree would you like it go through?
> > &
On Wed, Sep 24, 2014 at 10:46:17PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 24, 2014 03:15:58 PM Felipe Balbi wrote:
> > On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote:
On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote:
> > This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend()
> > which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
> > seq
Hi,
Just caught this with v3.14-rc4 running with
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce
GTX 650] (rev a1)
full dmesg attached
[ 239.589213] ==
[ 239.589214] [ INFO: possible circular locking dependency
On Mon, Mar 03, 2014 at 01:08:58PM -0600, Felipe Balbi wrote:
> From: Darren Etheridge
>
> 1680x1050 appears to also be within the bandwidth capabilities
> of the device and memory infrastructure.
>
> Signed-off-by: Darren Etheridge
ping
> ---
> drivers/gpu/drm
On Mon, Mar 03, 2014 at 01:08:56PM -0600, Felipe Balbi wrote:
> From: Darren Etheridge
>
> On resume the screen contents were not being restored properly. Looking at
> other DRM drivers it seems a call to drm_helper_resume_force_mode() is needed
> in the resume handler to force
From: Darren Etheridge
1680x1050 appears to also be within the bandwidth capabilities
of the device and memory infrastructure.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilc
From: Darren Etheridge
On resume the screen contents were not being restored properly. Looking at
other DRM drivers it seems a call to drm_helper_resume_force_mode() is needed
in the resume handler to force restoration of the mode and framebuffer data.
Signed-off-by: Darren Etheridge
---
driv
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() f
m within its callbacks, which may be called during the musb
> device probing.
>
> Signed-off-by: Russell King
you want me to carry this one through my tree or you prefer getting my
Acked-by ? Either way works for me:
Acked-by: Felipe Balbi
there's also the third option of me set
e dma capability bindings this can go away.
>*/
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> - ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
> + ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
ask;
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (retval)
> + goto resource_fail;
>
> udc->board = &lpc32xx_usbddat
Hi,
On Mon, Feb 25, 2013 at 02:49:07PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:43:12PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> > > On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe
Hi,
On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe Balbi wrote:
> > Hi folks,
> >
> > I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
> > v3.8.0 but works fine with v3.6.11.
> &
Hi folks,
I have a Dell e6410 whose framebuffer gets corrupted with v3.7.9 and
v3.8.0 but works fine with v3.6.11.
Below you can find lspci and my .config, maybe I'm missing something ?
8<-
00:00.0 Host bridge: Intel Corporation Co
Hi,
On Mon, Feb 25, 2013 at 02:49:07PM +, Chris Wilson wrote:
> On Mon, Feb 25, 2013 at 04:43:12PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Feb 25, 2013 at 02:39:18PM +, Chris Wilson wrote:
> > > On Mon, Feb 25, 2013 at 04:24:11PM +0200, Felipe
Hi,
On Sun, Jan 16, 2011 at 09:42:37PM +1000, Dave Airlie wrote:
> I'll push the attached I think this time.
the point of headers_check is exactly to prevent indirect inclusion.
This is even 1st topic o SubmitChecklist:
" 1: If you use a facility then #include the file that defines/declares
that
On Sun, Jan 16, 2011 at 01:16:16PM +0200, Felipe Balbi wrote:
> I truly have those types in use.
I meant you :-p
--
balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sun, Jan 16, 2011 at 11:07:32AM +, Chris Wilson wrote:
> On Sun, 16 Jan 2011 12:46:22 +0200, Felipe Balbi wrote:
> > Drop the following headers_check errors:
> > /linux-2.6/usr/include/drm/drm_mode.h:85: found
> > __[us]{8,16,32,64} type without #include
> >
Hi,
On Sun, Jan 16, 2011 at 12:46:22PM +0200, Felipe Balbi wrote:
> Drop the following headers_check errors:
> /linux-2.6/usr/include/drm/drm_mode.h:85: found
> __[us]{8,16,32,64} type without #include
> /linux-2.6/usr/include/drm/i915_drm.h:120: found
> __[us]{8,16,32,64} type w
...@vger.kernel.org
Signed-off-by: Felipe Balbi
---
include/drm/drm_mode.h |2 ++
include/drm/i915_drm.h |1 +
include/drm/mga_drm.h|1 +
include/drm/radeon_drm.h |1 +
include/drm/via_drm.h|1 +
5 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_mode.h b
Hi,
On Sun, Jan 16, 2011 at 09:42:37PM +1000, Dave Airlie wrote:
> I'll push the attached I think this time.
the point of headers_check is exactly to prevent indirect inclusion.
This is even 1st topic o SubmitChecklist:
" 1: If you use a facility then #include the file that defines/declares
that
On Sun, Jan 16, 2011 at 01:16:16PM +0200, Felipe Balbi wrote:
> I truly have those types in use.
I meant you :-p
--
balbi
On Sun, Jan 16, 2011 at 11:07:32AM +, Chris Wilson wrote:
> On Sun, 16 Jan 2011 12:46:22 +0200, Felipe Balbi wrote:
> > Drop the following headers_check errors:
> > /linux-2.6/usr/include/drm/drm_mode.h:85: found
> > __[us]{8,16,32,64} type without #include
> >
Hi,
On Sun, Jan 16, 2011 at 12:46:22PM +0200, Felipe Balbi wrote:
> Drop the following headers_check errors:
> /linux-2.6/usr/include/drm/drm_mode.h:85: found
> __[us]{8,16,32,64} type without #include
> /linux-2.6/usr/include/drm/i915_drm.h:120: found
> __[us]{8,16,32,64} type w
vger.kernel.org
Signed-off-by: Felipe Balbi
---
include/drm/drm_mode.h |2 ++
include/drm/i915_drm.h |1 +
include/drm/mga_drm.h|1 +
include/drm/radeon_drm.h |1 +
include/drm/via_drm.h|1 +
5 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/drm
36 matches
Mail list logo
