Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Alex Deucher]

On Tue, Dec 18, 2018 at 7:08 PM Brad Love  wrote:
>
>
> On 18/12/2018 18.05, Brad Love wrote:
> > On 18/12/2018 17.46, Alex Deucher wrote:
> >> On Tue, Dec 18, 2018 at 7:45 AM Mauro Carvalho Chehab
> >>  wrote:
> >>> Em Mon, 17 Dec 2018 21:05:11 -0500
> >>> Alex Deucher  escreveu:
> >>>
> >>>> On Sun, Dec 16, 2018 at 9:23 AM Mauro Carvalho Chehab
> >>>>  wrote:
> >>>>> Em Sun, 16 Dec 2018 11:37:02 +0100
> >>>>> Markus Dobel  escreveu:
> >>>>>
> >>>>>> On 06.12.2018 19:01, Mauro Carvalho Chehab wrote:
> >>>>>>> Em Thu, 06 Dec 2018 18:18:23 +0100
> >>>>>>> Markus Dobel  escreveu:
> >>>>>>>
> >>>>>>>> Hi everyone,
> >>>>>>>>
> >>>>>>>> I will try if the hack mentioned fixes the issue for me on the 
> >>>>>>>> weekend
> >>>>>>>> (but I assume, as if effectively removes the function).
> >>>>>>> It should, but it keeps a few changes. Just want to be sure that what
> >>>>>>> would be left won't cause issues. If this works, the logic that would
> >>>>>>> solve Ryzen DMA fixes will be contained into a single point, making
> >>>>>>> easier to maintain it.
> >>>>>> Hi,
> >>>>>>
> >>>>>> I wanted to have this setup running stable for a few days before
> >>>>>> replying, that's why I am answering only now.
> >>>>>>
> >>>>>> But yes, as expected, with Mauro's hack, the driver has been stable for
> >>>>>> me for about a week, with several
> >>>>>> scheduled recordings in tvheadend, none of them missed.
> >>>>>>
> >>>>>> So, adding a reliable detection for affected chipsets, where the `if
> >>>>>> (1)` currently is, should work.
> >>>>> Markus,
> >>>>>
> >>>>> Thanks for testing!
> >>>>>
> >>>>> Brad/Alex,
> >>>>>
> >>>>> I guess we should then stick with this patch:
> >>>>> https://patchwork.linuxtv.org/patch/53351/
> >>>>>
> >>>>> The past approach that we used on cx88, bttv and other old drivers
> >>>>> were to patch drivers/pci/quirks.c, making them to "taint" DMA
> >>>>> memory controllers that were known to bad affect on media devices,
> >>>>> and then some logic at the drivers to check for such "taint".
> >>>>>
> >>>>> However, that would require to touch another subsystem, with
> >>>>> usually cause delays. Also, as Alex pointed, this could well
> >>>>> be just a matter of incompatibility between the cx23885 and
> >>>>> the Ryzen DMA controller, and may not affect any other drivers.
> >>>>>
> >>>>> So, let's start with a logic like what I proposed, fine
> >>>>> tuning it to the Ryzen DMA controllers with we know have
> >>>>> troubles with the driver.
> >>>>>
> >>>>> We need to list the PCI ID of the memory controllers at the
> >>>>> device ID table on that patch, though. At the RFC patch,
> >>>>> I just added an IOMMU PCI ID from a randon Ryzen CPU:
> >>>>>
> >>>>> +static struct {
> >>>>> +   int vendor, dev;
> >>>>> +} const broken_dev_id[] = {
> >>>>> +   /* According with
> >>>>> +* 
> >>>>> https://openbenchmarking.org/system/1703021-RI-AMDZEN08075/Ryzen%207%201800X/lspci,
> >>>>> +* 0x1451 is PCI ID for the IOMMU found on Ryzen 7
> >>>>> +*/
> >>>>> +   { PCI_VENDOR_ID_AMD, 0x1451 },
> >>>>> +};
> >>>>> +
> >>>>>
> >>>>> Ideally, the ID for the affected Ryzen DMA engines should be there at
> >>>>> include/linux/pci_ids.h, instead of hard-coded inside a driver.
> >>>>>
> >>>>> Also, we should, instead, add there the PCI IDs of the DMA engines
> >>>>> that are known to have p

Re: [PATCH v2] cx23885: only reset DMA on problematic CPUs

[Alex Deucher]

On Tue, Dec 18, 2018 at 5:59 PM Brad Love  wrote:
>
> It is reported that commit 95f408bbc4e4 ("media: cx23885: Ryzen DMA
> related RiSC engine stall fixes") caused regresssions with other CPUs.
>
> Ensure that the quirk will be applied only for the CPUs that
> are known to cause problems.
>
> A module option is added for explicit control of the behaviour.
>
> Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall 
> fixes")
>
> Signed-off-by: Brad Love 
> ---
> Changes since v1:
> - Added module option for three way control
> - Removed '7' from pci id description, Ryzen 3 is the same id
>
>  drivers/media/pci/cx23885/cx23885-core.c | 54 
> ++--
>  drivers/media/pci/cx23885/cx23885.h  |  2 ++
>  2 files changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d8..fb721c7 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -41,6 +42,18 @@ MODULE_AUTHOR("Steven Toth ");
>  MODULE_LICENSE("GPL");
>  MODULE_VERSION(CX23885_VERSION);
>
> +/*
> + * Some platforms have been found to require periodic resetting of the DMA
> + * engine. Ryzen and XEON platforms are known to be affected. The symptom
> + * encountered is "mpeg risc op code error". Only Ryzen platforms employ
> + * this workaround if the option equals 1. The workaround can be explicitly
> + * disabled for all platforms by setting to 0, the workaround can be forced
> + * on for any platform by setting to 2.
> + */
> +static unsigned int dma_reset_workaround = 1;
> +module_param(dma_reset_workaround, int, 0644);
> +MODULE_PARM_DESC(dma_reset_workaround, "periodic RiSC dma engine reset; 
> 0-force disable, 1-driver detect (default), 2-force enable");
> +
>  static unsigned int debug;
>  module_param(debug, int, 0644);
>  MODULE_PARM_DESC(debug, "enable debug messages");
> @@ -603,8 +616,13 @@ static void cx23885_risc_disasm(struct cx23885_tsport 
> *port,
>
>  static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
>  {
> -   uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
> -   uint32_t reg2_val = cx_read(TC_REQ_SET);
> +   uint32_t reg1_val, reg2_val;
> +
> +   if (!dev->need_dma_reset)
> +   return;
> +
> +   reg1_val = cx_read(TC_REQ); /* read-only */
> +   reg2_val = cx_read(TC_REQ_SET);
>
> if (reg1_val && reg2_val) {
> cx_write(TC_REQ, reg1_val);
> @@ -2058,6 +2076,36 @@ void cx23885_gpio_enable(struct cx23885_dev *dev, u32 
> mask, int asoutput)
> /* TODO: 23-19 */
>  }
>
> +static struct {
> +   int vendor, dev;
> +} const broken_dev_id[] = {
> +   /* According with
> +* 
> https://openbenchmarking.org/system/1703021-RI-AMDZEN08075/Ryzen%207%201800X/lspci,
> +* 0x1451 is PCI ID for the IOMMU found on Ryzen
> +*/
> +   { PCI_VENDOR_ID_AMD, 0x1451 },

Does this issue only happen with the IOMMU is enabled?  Is it only for
p2p transfers?  Until recently the DMA and PCI subsystems didn't
actually support p2p properly when the IOMMU was enabled.  that might
explain some of the issues.  Additionally, if you match based on the
IOMMU id, you won't match if the user disables the IOMMU in the sbios.
Is this only an issue with the IOMMU enabled?

Alex

> +};
> +
> +static bool cx23885_does_need_dma_reset(void)
> +{
> +   int i;
> +   struct pci_dev *pdev = NULL;
> +
> +   if (dma_reset_workaround == 0)
> +   return false;
> +   else if (dma_reset_workaround == 2)
> +   return true;
> +
> +   for (i = 0; i < sizeof(broken_dev_id); i++) {
> +   pdev = pci_get_device(broken_dev_id[i].vendor, 
> broken_dev_id[i].dev, NULL);
> +   if (pdev) {
> +   pci_dev_put(pdev);
> +   return true;
> +   }
> +   }
> +   return false;
> +}
> +
>  static int cx23885_initdev(struct pci_dev *pci_dev,
>const struct pci_device_id *pci_id)
>  {
> @@ -2069,6 +2117,8 @@ static int cx23885_initdev(struct pci_dev *pci_dev,
> if (NULL == dev)
> return -ENOMEM;
>
> +   dev->need_dma_reset = cx23885_does_need_dma_reset();
> +
> err = v4l2_device_register(&pci_dev->dev, &dev->v4l2_dev);
> if (err < 0)
> goto fail_free;
> diff --git a/drivers/media/pci/cx23885/cx23885.h 
> b/drivers/media/pci/cx23885/cx23885.h
> index d54c7ee..cf965ef 100644
> --- a/drivers/media/pci/cx23885/cx23885.h
> +++ b/drivers/media/pci/cx23885/cx23885.h
> @@ -451,6 +451,8 @@ struct cx23885_dev {
> /* Analog raw audio */
> struct cx23885_audio_dev   *audio_dev;
>
> +   /* Does the system require periodic DMA resets? */
> +   unsigned intnee

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Alex Deucher]

On Tue, Dec 18, 2018 at 7:45 AM Mauro Carvalho Chehab
 wrote:
>
> Em Mon, 17 Dec 2018 21:05:11 -0500
> Alex Deucher  escreveu:
>
> > On Sun, Dec 16, 2018 at 9:23 AM Mauro Carvalho Chehab
> >  wrote:
> > >
> > > Em Sun, 16 Dec 2018 11:37:02 +0100
> > > Markus Dobel  escreveu:
> > >
> > > > On 06.12.2018 19:01, Mauro Carvalho Chehab wrote:
> > > > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > > > Markus Dobel  escreveu:
> > > > >
> > > > >> Hi everyone,
> > > > >>
> > > > >> I will try if the hack mentioned fixes the issue for me on the 
> > > > >> weekend
> > > > >> (but I assume, as if effectively removes the function).
> > > > >
> > > > > It should, but it keeps a few changes. Just want to be sure that what
> > > > > would be left won't cause issues. If this works, the logic that would
> > > > > solve Ryzen DMA fixes will be contained into a single point, making
> > > > > easier to maintain it.
> > > >
> > > > Hi,
> > > >
> > > > I wanted to have this setup running stable for a few days before
> > > > replying, that's why I am answering only now.
> > > >
> > > > But yes, as expected, with Mauro's hack, the driver has been stable for
> > > > me for about a week, with several
> > > > scheduled recordings in tvheadend, none of them missed.
> > > >
> > > > So, adding a reliable detection for affected chipsets, where the `if
> > > > (1)` currently is, should work.
> > >
> > > Markus,
> > >
> > > Thanks for testing!
> > >
> > > Brad/Alex,
> > >
> > > I guess we should then stick with this patch:
> > > https://patchwork.linuxtv.org/patch/53351/
> > >
> > > The past approach that we used on cx88, bttv and other old drivers
> > > were to patch drivers/pci/quirks.c, making them to "taint" DMA
> > > memory controllers that were known to bad affect on media devices,
> > > and then some logic at the drivers to check for such "taint".
> > >
> > > However, that would require to touch another subsystem, with
> > > usually cause delays. Also, as Alex pointed, this could well
> > > be just a matter of incompatibility between the cx23885 and
> > > the Ryzen DMA controller, and may not affect any other drivers.
> > >
> > > So, let's start with a logic like what I proposed, fine
> > > tuning it to the Ryzen DMA controllers with we know have
> > > troubles with the driver.
> > >
> > > We need to list the PCI ID of the memory controllers at the
> > > device ID table on that patch, though. At the RFC patch,
> > > I just added an IOMMU PCI ID from a randon Ryzen CPU:
> > >
> > > +static struct {
> > > +   int vendor, dev;
> > > +} const broken_dev_id[] = {
> > > +   /* According with
> > > +* 
> > > https://openbenchmarking.org/system/1703021-RI-AMDZEN08075/Ryzen%207%201800X/lspci,
> > > +* 0x1451 is PCI ID for the IOMMU found on Ryzen 7
> > > +*/
> > > +   { PCI_VENDOR_ID_AMD, 0x1451 },
> > > +};
> > > +
> > >
> > > Ideally, the ID for the affected Ryzen DMA engines should be there at
> > > include/linux/pci_ids.h, instead of hard-coded inside a driver.
> > >
> > > Also, we should, instead, add there the PCI IDs of the DMA engines
> > > that are known to have problems with the cx23885.
> >
> > These aren't really DMA engines.  Isn't this just the pcie bridge on the 
> > CPU?
>
> Yeah, it is not the DMA engine itself, but the CPU/chipset support for it.
>
> Let me be a little clearer. The Conexant chipsets for PCI/PCIe engines
> have internally a RISC CPU that it is programmed, in runtime, to do
> DMA scatter/gather. The actual DMA engine is there. For it to work, the
> Northbridge (or the CPU chipset - as nowadays several chipsets integrated
> the Northbridge inside an IP block at the CPU) has to do the counter part,
> by allowing the board's DMA engine to access the mainboard's main memory,
> usually via IOMMU, in a safe way[1].
>
> [1] preventing memory corruption if two devices try to do DMA to the
> same area, or if the DMA from the board tries to write at the same
>

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Alex Deucher]

On Sun, Dec 16, 2018 at 9:23 AM Mauro Carvalho Chehab
 wrote:
>
> Em Sun, 16 Dec 2018 11:37:02 +0100
> Markus Dobel  escreveu:
>
> > On 06.12.2018 19:01, Mauro Carvalho Chehab wrote:
> > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > Markus Dobel  escreveu:
> > >
> > >> Hi everyone,
> > >>
> > >> I will try if the hack mentioned fixes the issue for me on the weekend
> > >> (but I assume, as if effectively removes the function).
> > >
> > > It should, but it keeps a few changes. Just want to be sure that what
> > > would be left won't cause issues. If this works, the logic that would
> > > solve Ryzen DMA fixes will be contained into a single point, making
> > > easier to maintain it.
> >
> > Hi,
> >
> > I wanted to have this setup running stable for a few days before
> > replying, that's why I am answering only now.
> >
> > But yes, as expected, with Mauro's hack, the driver has been stable for
> > me for about a week, with several
> > scheduled recordings in tvheadend, none of them missed.
> >
> > So, adding a reliable detection for affected chipsets, where the `if
> > (1)` currently is, should work.
>
> Markus,
>
> Thanks for testing!
>
> Brad/Alex,
>
> I guess we should then stick with this patch:
> https://patchwork.linuxtv.org/patch/53351/
>
> The past approach that we used on cx88, bttv and other old drivers
> were to patch drivers/pci/quirks.c, making them to "taint" DMA
> memory controllers that were known to bad affect on media devices,
> and then some logic at the drivers to check for such "taint".
>
> However, that would require to touch another subsystem, with
> usually cause delays. Also, as Alex pointed, this could well
> be just a matter of incompatibility between the cx23885 and
> the Ryzen DMA controller, and may not affect any other drivers.
>
> So, let's start with a logic like what I proposed, fine
> tuning it to the Ryzen DMA controllers with we know have
> troubles with the driver.
>
> We need to list the PCI ID of the memory controllers at the
> device ID table on that patch, though. At the RFC patch,
> I just added an IOMMU PCI ID from a randon Ryzen CPU:
>
> +static struct {
> +   int vendor, dev;
> +} const broken_dev_id[] = {
> +   /* According with
> +* 
> https://openbenchmarking.org/system/1703021-RI-AMDZEN08075/Ryzen%207%201800X/lspci,
> +* 0x1451 is PCI ID for the IOMMU found on Ryzen 7
> +*/
> +   { PCI_VENDOR_ID_AMD, 0x1451 },
> +};
> +
>
> Ideally, the ID for the affected Ryzen DMA engines should be there at
> include/linux/pci_ids.h, instead of hard-coded inside a driver.
>
> Also, we should, instead, add there the PCI IDs of the DMA engines
> that are known to have problems with the cx23885.

These aren't really DMA engines.  Isn't this just the pcie bridge on the CPU?


>
> There one thing that still bothers me: could this problem be due to
> some BIOS setup [1]? If so, are there any ways for dynamically
> disabling such features inside the driver?
>
> [1] like this: https://www.techarp.com/bios-guide/cpu-pci-write-buffer/
>

possibly?  It's still not clear to me that this is specific to ryzen
chips rather than a problem with the DMA setup on the cx board.  Is
there a downside to enabling the workaround in general?  The original
commit mentioned that xeon platforms were affected as well.  Is it
possible it's just particular platforms with wonky bioses?  Maybe DMI
matching would be better?

> Brad,
>
> From your reports about the DMA issues, do you know what generations
> of the Ryzen are affected?
>
> Alex,
>
> Do you know if are there any differences at the IP block for the
> DMA engine used on different Ryzen CPUs? I mean: I suspect that
> the engine for Ryzen 2nd generation would likely be different than
> the one at the 1st generation, but, along the same generation, does
> the Ryzen 3, 5, 7 and Threadripper use the same DMA engine?

+ Suravee.  I'm not really familiar with the changes, if any, that are
in the pcie bridges on various AMD CPUs.  Or if there are changes, it
would be hard to say whether this issue would affect them or not.

Alex

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

[Alex Deucher]

On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  wrote:
>
> Em Thu, 06 Dec 2018 18:18:23 +0100
> Markus Dobel  escreveu:
>
> > Hi everyone,
> >
> > I will try if the hack mentioned fixes the issue for me on the weekend (but 
> > I assume, as if effectively removes the function).
>
> It should, but it keeps a few changes. Just want to be sure that what
> would be left won't cause issues. If this works, the logic that would
> solve Ryzen DMA fixes will be contained into a single point, making
> easier to maintain it.
>
> >
> > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP 
> > Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more on 
> > the slow side.
>
> Good to know. It would probably worth to check if this Ryzen
> bug occors with all versions of it or with just a subset.
> I mean: maybe it is only at the first gen or Ryzen and doesn't
> affect Ryzen 2 (or vice versa).

The original commit also mentions some Xeons are affected too.  Seems
like this is potentially an issue on the device side rather than the
platform.

>
> The PCI quirks logic will likely need to detect the PCI ID of
> the memory controllers found at the buggy CPUs, in order to enable
> the quirk only for the affected ones.
>
> It could be worth talking with AMD people in order to be sure about
> the differences at the DMA engine side.
>

It's not clear to me what the pci or platform quirk would do.  The
workaround seems to be in the driver, not on the platform.

Alex

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig  wrote:
> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
>> > It has a non-coherent transaction mode (which the chipset can opt to
>> > not implement and still flush), to make sure the AGP horror show
>> > doesn't happen again and GPU folks are happy with PCIe. That's at
>> > least my understanding from digging around in amd the last time we had
>> > coherency issues between intel and amd gpus. GPUs have some bits
>> > somewhere (in the pagetables, or in the buffer object description
>> > table created by userspace) to control that stuff.
>>
>> Right.  We have a bit in the GPU page table entries that determines
>> whether we snoop the CPU's cache or not.
>
> I can see how that works with the GPU on the same SOC or SOC set as the
> CPU.  But how is that going to work for a GPU that is a plain old PCIe
> card?  The cache snooping in that case is happening in the PCIe root
> complex.

I'm not a pci expert, but as far as I know, the device sends either a
snooped or non-snooped transaction on the bus.  I think the
transaction descriptor supports a no snoop attribute.  Our GPUs have
supported this feature for probably 20 years if not more, going back
to PCI.  Using non-snooped transactions have lower latency and faster
throughput compared to snooped transactions.

Alex

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 2:13 AM, Daniel Vetter  wrote:
> On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig  wrote:
>> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>>> Out of curiosity, how much virtual flushing stuff is there still out
>>> there? At least in drm we've pretty much ignore this, and seem to be
>>> getting away without a huge uproar (at least from driver developers
>>> and users, core folks are less amused about that).
>>
>> As I've just been wading through the code, the following architectures
>> have non-coherent dma that flushes by virtual address for at least some
>> platforms:
>>
>>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>>powerpc
>>
>> These have non-coherent dma ops that flush by physical address:
>>
>>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>>
>> And these do not have non-coherent dma ops at all:
>>
>>  - alpha, h8300, riscv, unicore32, x86
>>
>> [1] arm ѕeems to do both virtually and physically based ops, further
>> audit needed.
>>
>> Note that using virtual addresses in the cache flushing interface
>> doesn't mean that the cache actually is virtually indexed, but it at
>> least allows for the possibility.
>>
>>> > I think the most important thing about such a buffer object is that
>>> > it can distinguish the underlying mapping types.  While
>>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>>> > back a dma_addr_t they are in now way interchangable.  And trying to
>>> > stuff them all into a structure like struct scatterlist that has
>>> > no indication what kind of mapping you are dealing with is just
>>> > asking for trouble.
>>>
>>> Well the idea was to have 1 interface to allow all drivers to share
>>> buffers with anything else, no matter how exactly they're allocated.
>>
>> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
>> a scatterlist through the sg_table in dma_buf_map_attachment /
>> ->map_dma_buf, but looking at a few of the callers it seems like they
>> really do not even want a scatterlist to start with, but check that
>> is contains a physically contiguous range first.  So kicking the
>> scatterlist our there will probably improve the interface in general.
>
> I think by number most drm drivers require contiguous memory (or an
> iommu that makes it look contiguous). But there's plenty others who
> have another set of pagetables on the gpu itself and can
> scatter-gather. Usually it's the former for display/video blocks, and
> the latter for rendering.
>
>>> dma-buf has all the functions for flushing, so you can have coherent
>>> mappings, non-coherent mappings and pretty much anything else. Or well
>>> could, because in practice people hack up layering violations until it
>>> works for the 2-3 drivers they care about. On top of that there's the
>>> small issue that x86 insists that dma is coherent (and that's true for
>>> most devices, including v4l drivers you might want to share stuff
>>> with), and gpus really, really really do want to make almost
>>> everything incoherent.
>>
>> How do discrete GPUs manage to be incoherent when attached over PCIe?
>
> It has a non-coherent transaction mode (which the chipset can opt to
> not implement and still flush), to make sure the AGP horror show
> doesn't happen again and GPU folks are happy with PCIe. That's at
> least my understanding from digging around in amd the last time we had
> coherency issues between intel and amd gpus. GPUs have some bits
> somewhere (in the pagetables, or in the buffer object description
> table created by userspace) to control that stuff.

Right.  We have a bit in the GPU page table entries that determines
whether we snoop the CPU's cache or not.

Alex

>
> For anything on the SoC it's presented as pci device, but that's
> extremely fake, and we can definitely do non-snooped transactions on
> drm/i915. Again, controlled by a mix of pagetables and
> userspace-provided buffer object description tables.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

[Alex Deucher]

On Wed, Apr 25, 2018 at 1:48 AM, Christoph Hellwig  wrote:
> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>> Out of curiosity, how much virtual flushing stuff is there still out
>> there? At least in drm we've pretty much ignore this, and seem to be
>> getting away without a huge uproar (at least from driver developers
>> and users, core folks are less amused about that).
>
> As I've just been wading through the code, the following architectures
> have non-coherent dma that flushes by virtual address for at least some
> platforms:
>
>  - arm [1], arm64, hexagon, nds32, nios2, parisc, sh, xtensa, mips,
>powerpc
>
> These have non-coherent dma ops that flush by physical address:
>
>  - arc, arm [1], c6x, m68k, microblaze, openrisc, sparc
>
> And these do not have non-coherent dma ops at all:
>
>  - alpha, h8300, riscv, unicore32, x86
>
> [1] arm ѕeems to do both virtually and physically based ops, further
> audit needed.
>
> Note that using virtual addresses in the cache flushing interface
> doesn't mean that the cache actually is virtually indexed, but it at
> least allows for the possibility.
>
>> > I think the most important thing about such a buffer object is that
>> > it can distinguish the underlying mapping types.  While
>> > dma_alloc_coherent, dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT,
>> > dma_map_page/dma_map_single/dma_map_sg and dma_map_resource all give
>> > back a dma_addr_t they are in now way interchangable.  And trying to
>> > stuff them all into a structure like struct scatterlist that has
>> > no indication what kind of mapping you are dealing with is just
>> > asking for trouble.
>>
>> Well the idea was to have 1 interface to allow all drivers to share
>> buffers with anything else, no matter how exactly they're allocated.
>
> Isn't that interface supposed to be dmabuf?  Currently dma_map leaks
> a scatterlist through the sg_table in dma_buf_map_attachment /
> ->map_dma_buf, but looking at a few of the callers it seems like they
> really do not even want a scatterlist to start with, but check that
> is contains a physically contiguous range first.  So kicking the
> scatterlist our there will probably improve the interface in general.
>
>> dma-buf has all the functions for flushing, so you can have coherent
>> mappings, non-coherent mappings and pretty much anything else. Or well
>> could, because in practice people hack up layering violations until it
>> works for the 2-3 drivers they care about. On top of that there's the
>> small issue that x86 insists that dma is coherent (and that's true for
>> most devices, including v4l drivers you might want to share stuff
>> with), and gpus really, really really do want to make almost
>> everything incoherent.
>
> How do discrete GPUs manage to be incoherent when attached over PCIe?

They can do CPU cache snooped (coherent) or non-snooped (incoherent)
DMA.  Also for things like APUs, they show up as a PCIe device, but
that actual GPU core is part of the same die as the CPU and they have
their own special paths to memory, etc.  The fact that they show up as
PCIe devices is mostly for enumeration purposes.

Alex

> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Alex Deucher]

Sorry, didn't mean to drop the lists here. re-adding.

On Wed, Mar 28, 2018 at 4:05 PM, Alex Deucher  wrote:
> On Wed, Mar 28, 2018 at 3:53 PM, Logan Gunthorpe  wrote:
>>
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>>> I can see it makes sure IOMMU is aware of the access route and
>>> translates a CPU address into a PCI Bus address.
>>
>>> I'm using that with the AMD IOMMU driver and at least there it works
>>> perfectly fine.
>>
>> Yes, it would be nice, but no arch has implemented this yet. We are just
>> lucky in the x86 case because that arch is simple and doesn't need to do
>> anything for P2P (partially due to the Bus and CPU addresses being the
>> same). But in the general case, you can't rely on it.
>
> Could we do something for the arches where it works?  I feel like peer
> to peer has dragged out for years because everyone is trying to boil
> the ocean for all arches.  There are a huge number of use cases for
> peer to peer on these "simple" architectures which actually represent
> a good deal of the users that want this.
>
> Alex
>
>>
>>>>> Yeah, but not for ours. See if you want to do real peer 2 peer you need
>>>>> to keep both the operation as well as the direction into account.
>>>> Not sure what you are saying here... I'm pretty sure we are doing "real"
>>>> peer 2 peer...
>>>>
>>>>> For example when you can do writes between A and B that doesn't mean
>>>>> that writes between B and A work. And reads are generally less likely to
>>>>> work than writes. etc...
>>>> If both devices are behind a switch then the PCI spec guarantees that A
>>>> can both read and write B and vice versa.
>>>
>>> Sorry to say that, but I know a whole bunch of PCI devices which
>>> horrible ignores that.
>>
>> Can you elaborate? As far as the device is concerned it shouldn't know
>> whether a request comes from a peer or from the host. If it does do
>> crazy stuff like that it's well out of spec. It's up to the switch (or
>> root complex if good support exists) to route the request to the device
>> and it's the root complex that tends to be what drops the load requests
>> which causes the asymmetries.
>>
>> Logan
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/7] cx231xx: Add second frontend option

[Alex Deucher]

On Fri, Jan 12, 2018 at 11:19 AM, Brad Love  wrote:
> Include ability to add a second dvb attach style frontend to cx231xx
> USB bridge. All current boards set to use frontend[0]. Changes are
> backwards compatible with current behaviour.
>
> Signed-off-by: Brad Love 
> ---
>  drivers/media/usb/cx231xx/cx231xx-dvb.c | 173 
> ++--
>  1 file changed, 97 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index cb4209f..4c6d2f4 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -55,7 +55,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  #define CX231XX_DVB_MAX_PACKETS 64
>
>  struct cx231xx_dvb {
> -   struct dvb_frontend *frontend;
> +   struct dvb_frontend *frontend[2];

Maybe define something like CX231XX_MAX_FRONTEND and use it here
rather than using a hardcoded 2.

Alex


>
> /* feed count management */
> struct mutex lock;
> @@ -386,17 +386,17 @@ static int attach_xc5000(u8 addr, struct cx231xx *dev)
> cfg.i2c_adap = cx231xx_get_i2c_adap(dev, dev->board.tuner_i2c_master);
> cfg.i2c_addr = addr;
>
> -   if (!dev->dvb->frontend) {
> +   if (!dev->dvb->frontend[0]) {
> dev_err(dev->dev, "%s/2: dvb frontend not attached. Can't 
> attach xc5000\n",
> dev->name);
> return -EINVAL;
> }
>
> -   fe = dvb_attach(xc5000_attach, dev->dvb->frontend, &cfg);
> +   fe = dvb_attach(xc5000_attach, dev->dvb->frontend[0], &cfg);
> if (!fe) {
> dev_err(dev->dev, "%s/2: xc5000 attach failed\n", dev->name);
> -   dvb_frontend_detach(dev->dvb->frontend);
> -   dev->dvb->frontend = NULL;
> +   dvb_frontend_detach(dev->dvb->frontend[0]);
> +   dev->dvb->frontend[0] = NULL;
> return -EINVAL;
> }
>
> @@ -408,9 +408,9 @@ static int attach_xc5000(u8 addr, struct cx231xx *dev)
>
>  int cx231xx_set_analog_freq(struct cx231xx *dev, u32 freq)
>  {
> -   if ((dev->dvb != NULL) && (dev->dvb->frontend != NULL)) {
> +   if ((dev->dvb != NULL) && (dev->dvb->frontend[0] != NULL)) {
>
> -   struct dvb_tuner_ops *dops = 
> &dev->dvb->frontend->ops.tuner_ops;
> +   struct dvb_tuner_ops *dops = 
> &dev->dvb->frontend[0]->ops.tuner_ops;
>
> if (dops->set_analog_params != NULL) {
> struct analog_parameters params;
> @@ -421,7 +421,7 @@ int cx231xx_set_analog_freq(struct cx231xx *dev, u32 freq)
> /*params.audmode = ;   */
>
> /* Set the analog parameters to set the frequency */
> -   dops->set_analog_params(dev->dvb->frontend, ¶ms);
> +   dops->set_analog_params(dev->dvb->frontend[0], 
> ¶ms);
> }
>
> }
> @@ -433,15 +433,15 @@ int cx231xx_reset_analog_tuner(struct cx231xx *dev)
>  {
> int status = 0;
>
> -   if ((dev->dvb != NULL) && (dev->dvb->frontend != NULL)) {
> +   if ((dev->dvb != NULL) && (dev->dvb->frontend[0] != NULL)) {
>
> -   struct dvb_tuner_ops *dops = 
> &dev->dvb->frontend->ops.tuner_ops;
> +   struct dvb_tuner_ops *dops = 
> &dev->dvb->frontend[0]->ops.tuner_ops;
>
> if (dops->init != NULL && !dev->xc_fw_load_done) {
>
> dev_dbg(dev->dev,
> "Reloading firmware for XC5000\n");
> -   status = dops->init(dev->dvb->frontend);
> +   status = dops->init(dev->dvb->frontend[0]);
> if (status == 0) {
> dev->xc_fw_load_done = 1;
> dev_dbg(dev->dev,
> @@ -481,17 +481,29 @@ static int register_dvb(struct cx231xx_dvb *dvb,
> dvb_register_media_controller(&dvb->adapter, dev->media_dev);
>
> /* Ensure all frontends negotiate bus access */
> -   dvb->frontend->ops.ts_bus_ctrl = cx231xx_dvb_bus_ctrl;
> +   dvb->frontend[0]->ops.ts_bus_ctrl = cx231xx_dvb_bus_ctrl;
> +   if (dvb->frontend[1])
> +   dvb->frontend[1]->ops.ts_bus_ctrl = cx231xx_dvb_bus_ctrl;
>
> dvb->adapter.priv = dev;
>
> /* register frontend */
> -   result = dvb_register_frontend(&dvb->adapter, dvb->frontend);
> +   result = dvb_register_frontend(&dvb->adapter, dvb->frontend[0]);
> if (result < 0) {
> dev_warn(dev->dev,
>"%s: dvb_register_frontend failed (errno = %d)\n",
>dev->name, result);
> -   goto fail_frontend;
> +   goto fail_frontend0;
> +   }
> +
> +   if (dvb->frontend[1]) {
> +   result = dvb_register_frontend(&dvb->adapter, 
> dvb->frontend[1]);
> +   if (result < 0) {
> + 

Re: [trivial PATCH] treewide: Align function definition open/close braces

[Alex Deucher]

On Sun, Dec 17, 2017 at 7:28 PM, Joe Perches  wrote:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches 
> ---
> git diff -w shows no difference other than the above 'Miscellanea'
>
> (this is against -next, but it applies against Linus' tree
>  with a couple offsets)
>
>  arch/x86/include/asm/atomic64_32.h   |  2 +-
>  drivers/acpi/custom_method.c |  2 +-
>  drivers/acpi/fan.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-

For amdgpu:
Acked-by: Alex Deucher 

>  drivers/media/i2c/msp3400-kthreads.c |  2 +-
>  drivers/message/fusion/mptsas.c  |  2 +-
>  drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
>  drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
>  drivers/platform/x86/eeepc-laptop.c  |  2 +-
>  drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
>  drivers/scsi/dpt_i2o.c   |  2 +-
>  drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
>  fs/locks.c   |  2 +-
>  fs/ocfs2/stack_user.c|  2 +-
>  fs/xfs/libxfs/xfs_alloc.c|  5 ++---
>  fs/xfs/xfs_export.c  |  2 +-
>  kernel/audit.c   |  6 +++---
>  kernel/trace/trace_printk.c  |  4 ++--
>  lib/raid6/sse2.c | 14 +++---
>  sound/soc/fsl/fsl_dma.c  |  2 +-
>  20 files changed, 30 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/include/asm/atomic64_32.h 
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
> long long r;
> alternative_atomic64(read, "=&A" (r), "c" (v) : "memory");
> return r;
> - }
> +}
>
>  /**
>   * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
>  {
> if (cm_dentry)
> debugfs_remove(cm_dentry);
> - }
> +}
>
>  module_init(acpi_custom_method_init);
>  module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
> unsigned long state)
> return fan_set_state_acpi4(device, state);
> else
> return fan_set_state(device, state);
> - }
> +}
>
>  static const struct thermal_cooling_device_ops fan_cooling_ops = {
> .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
> dc_state *context)
>   
> **/
>
>  struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
> struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
> unsigned int full_pipe_count;
>
> diff --git a/drivers/media/i2c/msp3400-kthreads.c 
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
>  }
>
>  static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
> struct msp_state *state = to_state(i2c_get_clientdata(client));
> int source, matrix;
>
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 3

Re: [PATCH] dma-buf: Cleanup comments on dma_buf_map_attachment()

[Alex Deucher]

On Wed, Nov 1, 2017 at 10:06 AM, Liviu Dudau  wrote:
> Mappings need to be unmapped by calling dma_buf_unmap_attachment() and
> not by calling again dma_buf_map_attachment(). Also fix some spelling
> mistakes.
>
> Signed-off-by: Liviu Dudau 

Reviewed-by: Alex Deucher 

> ---
>  drivers/dma-buf/dma-buf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index bc1cb284111cb..1792385405f0e 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -351,13 +351,13 @@ static inline int is_dma_buf_file(struct file *file)
>   *
>   * 2. Userspace passes this file-descriptors to all drivers it wants this 
> buffer
>   *to share with: First the filedescriptor is converted to a &dma_buf 
> using
> - *dma_buf_get(). The the buffer is attached to the device using
> + *dma_buf_get(). Then the buffer is attached to the device using
>   *dma_buf_attach().
>   *
>   *Up to this stage the exporter is still free to migrate or reallocate 
> the
>   *backing storage.
>   *
> - * 3. Once the buffer is attached to all devices userspace can inniate DMA
> + * 3. Once the buffer is attached to all devices userspace can initiate DMA
>   *access to the shared buffer. In the kernel this is done by calling
>   *dma_buf_map_attachment() and dma_buf_unmap_attachment().
>   *
> @@ -617,7 +617,7 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
>   * Returns sg_table containing the scatterlist to be returned; returns 
> ERR_PTR
>   * on error. May return -EINTR if it is interrupted by a signal.
>   *
> - * A mapping must be unmapped again using dma_buf_map_attachment(). Note that
> + * A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
>   * the underlying backing storage is pinned for as long as a mapping exists,
>   * therefore users/importers should not hold onto a mapping for undue 
> amounts of
>   * time.
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: how to link up audio bus from media controller driver to soc dai bus?

[Alex Deucher]

On Mon, Jun 12, 2017 at 3:15 PM, Tim Harvey  wrote:
> Greetings,
>
> I'm working on a media controller driver for the tda1997x HDMI
> receiver which provides an audio bus supporting I2S/SPDIF/OBA/HBR/DST.
> I'm unclear how to bind the audio bus to a SoC's audio bus, for
> example the IMX6 SSI (I2S) bus. I thought perhaps it was via a
> simple-audio-card device-tree binding but that appears to require an
> ALSA codec to bind to?
>
> Can anyone point me to an example of a media controller device driver
> that supports audio and video and how the audio is bound to a I2S bus?

I'm not sure if this is what you are looking for now not, but on some
AMD APUs, we have an i2s bus and codec attached to the GPU rather than
as a standalone device.  The audio DMA engine and interrupts are
controlled via the GPU's mmio aperture, but we expose the audio DMA
engine and i2c interface via alsa.  We use the MFD (Multi-Function
Device) kernel infrastructure to do this.  The GPU driver loads and
probes the audio capabilities and triggers the hotplug of the i2s and
audio dma engine.

For the GPU side see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
for the audio side:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/amd/acp-pcm-dma.c

Alex

Re: DRM Atomic property for color-space conversion

[Alex Deucher]

On Thu, Mar 16, 2017 at 10:07 AM, Ville Syrjälä
 wrote:
> On Tue, Jan 31, 2017 at 03:55:41PM +, Brian Starkey wrote:
>> On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote:
>> >On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote:
>> >> Hi,
>> >>
>> >> On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote:
>> >> >On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote:
>> >> >> Hi,
>> >> >>
>> >> >> We're looking to enable the per-plane color management hardware in
>> >> >> Mali-DP with atomic properties, which has sparked some conversation
>> >> >> around how to handle YCbCr formats.
>> >> >>
>> >> >> As it stands today, it's assumed that a driver will implicitly "do the
>> >> >> right thing" to display a YCbCr buffer.
>> >> >>
>> >> >> YCbCr data often uses different gamma curves and signal ranges (e.g.
>> >> >> BT.609, BT.701, BT.2020, studio range, full-range), so its desirable
>> >> >> to be able to explicitly control the YCbCr to RGB conversion process
>> >> >> from userspace.
>> >> >>
>> >> >> We're proposing adding a "CSC" (color-space conversion) property to
>> >> >> control this - primarily per-plane for framebuffer->pipeline CSC, but
>> >> >> perhaps one per CRTC too for devices which have an RGB pipeline and
>> >> >> want to output in YUV to the display:
>> >> >>
>> >> >> Name: "CSC"
>> >> >> Type: ENUM | ATOMIC;
>> >> >> Enum values (representative):
>> >> >> "default":
>> >> >> Same behaviour as now. "Some kind" of YCbCr->RGB conversion
>> >> >> for YCbCr buffers, bypass for RGB buffers
>> >> >> "disable":
>> >> >> Explicitly disable all colorspace conversion (i.e. use an
>> >> >> identity matrix).
>> >> >> "YCbCr to RGB: BT.709":
>> >> >> Only valid for YCbCr formats. CSC in accordance with BT.709
>> >> >> using [16..235] for (8-bit) luma values, and [16..240] for
>> >> >> 8-bit chroma values. For 10-bit formats, the range limits are
>> >> >> multiplied by 4.
>> >> >> "YCbCr to RGB: BT.709 full-swing":
>> >> >> Only valid for YCbCr formats. CSC in accordance with BT.709,
>> >> >> but using the full range of each channel.
>> >> >> "YCbCr to RGB: Use CTM":*
>> >> >> Only valid for YCbCr formats. Use the matrix applied via the
>> >> >> plane's CTM property
>> >> >> "RGB to RGB: Use CTM":*
>> >> >> Only valid for RGB formats. Use the matrix applied via the
>> >> >> plane's CTM property
>> >> >> "Use CTM":*
>> >> >> Valid for any format. Use the matrix applied via the plane's
>> >> >> CTM property
>> >> >> ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as
>> >> >> they are required.
>> >> >
>> >> >Having some RGB2RGB and YCBCR2RGB things in the same property seems
>> >> >weird. I would just go with something very simple like:
>> >> >
>> >> >YCBCR_TO_RGB_CSC:
>> >> >* BT.601
>> >> >* BT.709
>> >> >* custom matrix
>> >> >
>> >>
>> >> I think we've agreed in #dri-devel that this CSC property
>> >> can't/shouldn't be mapped on-to the existing (hardware implementing
>> >> the) CTM property - even in the case of per-plane color management -
>> >> because CSC needs to be done before DEGAMMA.
>> >>
>> >> So, I'm in favour of going with what you suggested in the first place:
>> >>
>> >> A new YCBCR_TO_RGB_CSC property, enum type, with a list of fixed
>> >> conversions. I'd drop the custom matrix for now, as we'd need to add
>> >> another property to attach the custom matrix blob too.
>> >>
>> >> I still think we need a way to specify whether the source data range
>> >> is broadcast/full-range, so perhaps the enum list should be expanded
>> >> to all combinations of BT.601/BT.709 + broadcast/full-range.
>> >
>> >Sounds reasonable. Not that much full range YCbCr stuff out there
>> >perhaps. Well, apart from jpegs I suppose. But no harm in being able
>> >to deal with it.
>> >
>> >>
>> >> (I'm not sure what the canonical naming for broadcast/full-range is,
>> >> we call them narrow and wide)
>> >
>> >We tend to call them full vs. limited range. That's how our
>> >"Broadcast RGB" property is defined as well.
>> >
>>
>> OK, using the same ones sounds sensible.
>>
>> >>
>> >> >And trying to use the same thing for the crtc stuff is probably not
>> >> >going to end well. Like Daniel said we already have the
>> >> >'Broadcast RGB' property muddying the waters there, and that stuff
>> >> >also ties in with what colorspace we signal to the sink via
>> >> >infoframes/whatever the DP thing was called. So my gut feeling is
>> >> >that trying to use the same property everywhere will just end up
>> >> >messy.
>> >>
>> >> Yeah, agreed. If/when someone wants to add CSC on the output of a CRTC
>> >> (after GAMMA), we can add a new property.
>> >>
>> >> That makes me wonder about calling this one SOURCE_YCBCR_TO_RGB_CSC to
>> >> be explicit that it describes the source data. Then we can later add
>> >> SINK_RGB_TO_YCBCR_CSC, and it will be reason

Re: Enabling peer to peer device transactions for PCIe devices

[Alex Deucher]

On Fri, Nov 25, 2016 at 2:34 PM, Jason Gunthorpe
 wrote:
> On Fri, Nov 25, 2016 at 12:16:30PM -0500, Serguei Sagalovitch wrote:
>
>> b) Allocation may not  have CPU address  at all - only GPU one.
>
> But you don't expect RDMA to work in the case, right?
>
> GPU people need to stop doing this windowed memory stuff :)
>

Blame 32 bit systems and GPUs with tons of vram :)

I think resizable bars are finally coming in a useful way so this
should go away soon.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Alex Deucher]

On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey  wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a way to describe the common ones?
>> >>
>> >> well, the point I'm trying to make, is by dividing your constraints
>> >> into two groups, one that impacts and is handled by userspace, and
>> >> one that is in the kernel (ie. where the pages go), you cut down
>> >> the number of permutations that the kernel has to care about
>> >>  considerably. And kernel already cares about, for example, what
>> >> range of addresses that a device can dma to/from.  I think really
>> >> the only thing missing is the max # of sglist entries (contiguous
>> >> or not)
>> >
>> > I think it's more than physically contiguous or not.
>> >
>> > For example, it can be more efficient to use large page sizes on
>> > devices with IOMMUs to reduce TLB traffic. I think the size and even
>> > the availability of large pages varies between different IOMMUs.
>>
>> sure.. but I suppose if we can spiff out dma_params to express "I need
>> contiguous", perhaps we can add some way to express "I prefer
>> as-contiguous-as-possible".. either way, this is about where the pages
>> are placed, and not about the layout of pixels within the page, so
>> should be in kernel.  It's something that is missing, but I believe
>> that it belongs in dma_params and hidden behind dma_alloc_*() for
>> simple drivers.
>
> Thinking about it, isn't this more a property of the IOMMU? I mean,
> are there any cases where an IOMMU had a large page mode but you
> wouldn't want to use it? So when allocating the memory, you'd have to
> take into account not just the constraints of the devices themselves,
> but also of any IOMMUs any of the device sit behind?
>
>
>> > There's also the issue of buffer stride alignment. As I say, if the
>> > buffer is to be written by a tile-based GPU like Mali, it's more
>> > efficient if the buffer's stride is aligned to the max AXI bus burst
>> > length. Though I guess a buffer stride only makes sense as a concept
>> > when interpreting the data as a linear-layout 2D image, so perhaps
>> > belongs in user-space along with format negotiation?
>> >
>>
>> Yeah.. this isn't about where the pages go, but about the arrangement
>> within a page.
>>
>> And, well, except for hw that supports the same tiling (or
>> compressed-fb) in display+gpu, you probably aren't sharing tiled
>> buffers.
>
> You'd only want to share a buffer between devices if those devices can
> understand the same pixel format. That pixel format can't be device-
> specific or opaque, it has to be explicit. I think drm_fourcc.h is
> what defines all the possible pixel formats. This is the enum I used
> in EGL_EXT_image_dma_buf_import at least. So if we get to the point
> where multiple devices can understand a tiled or compressed format, I
> assume we could just add that format to drm_fourcc.h and possibly
> v4l2's v4l2_mbus_pixelcode enum in v4l2-mediabus.h.
>
> For user-space to negotiate a common pixel format and now stride
> alignment, I guess it will obviously need a way to query what pixel
> formats a device supports and what its stride alignment requirements
> are.
>
> I don't know v4l2 very well, but it certainly seems the pixel format
> can be queried using V4L2_SUBDEV_FORMAT_TRY when attempting to set
> a particular format. I couldn't however find a way to retrieve a list
> of supported formats - it seems the mechanism is to try out each
> format in turn to determine if it is supported. Is that right?
>
> There doesn't however seem a way to query what stride constraints a
> V4l2 device might have. Does HW abstracted by v4l2 typically have
> such constraints? If so, how can we query them such that a buffer
> allocated by a DRM driver can be imported into v4l2 and used with
> that HW?
>
> Turning to DRM/KMS, it seems the supported formats of a plane can be
> queried using drm_mode_get_plane. However, there doesn't seem to be a
> way to query the supported formats of a crtc? If display HW only
> supports scanning out from a single buffer (like pl111 does), I think
> it won't have any planes and a fb can only be set on the crtc. In
> which case, how should user-space query which pixel formats that crtc
> supports?
>
> Assuming user-space can query the supported formats and find a common
> one, it will need to allocate a buffer. Looks like
> drm_mode_create_dumb can do that, but it only takes a bpp parameter,
> there's no format parameter. I assume then that user-space defines
> the format and tells the DRM driver which format the buffer is in
> when creating the fb with drm_mode_fb_cmd2, which does take a format
> parameter? Is that right?
>
> As with v4l2, DRM doesn't appear to have a way to query the stride
> constraints? Assuming there is a way to query the stride constraints,

Re: HD-Audio Generic HDMI/DP on wheezy

[Alex Deucher]

On Thu, May 9, 2013 at 1:41 PM, pierre  wrote:
> Thanks for your quick ansver, but after modifing /etc/default/grub with
> GRUB_CMDLINE_LINUX="radeon.audio=1 and update-grub then reboot, nothing go
> better:

Perhaps I misunderstood what you were asking about.  radeon.audio=1
just enables auto routing via HDMI.  what exactly are you trying to
do?  Discrete graphics cards only support audio via HDMI or DP.

Alex


>
> May  9 19:32:37 retraite kernel: [6.660223] snd_hda_intel :01:00.1:
> irq 45 for MSI/MSI-X
> May  9 19:32:37 retraite kernel: [6.660242] snd_hda_intel :01:00.1:
> setting latency timer to 64
> May  9 19:32:37 retraite kernel: [6.684425] HDMI status: Codec=0 Pin=3
> Presence_Detect=0 ELD_Valid=0
> May  9 19:32:37 retraite kernel: [6.684523] input: HD-Audio Generic
> HDMI/DP,pcm=3 as
> /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input6
> May  9 19:32:37 retraite kernel: [6.996110] WARNING: You are using an
> experimental version of the media stack.
> May  9 19:32:37 retraite kernel: [6.996111] As the driver is
> backported to an older kernel, it doesn't offer
> May  9 19:32:37 retraite kernel: [6.996112] enough quality for its
> usage in production.
> May  9 19:32:37 retraite kernel: [6.996113] Use it with care.
> May  9 19:32:37 retraite kernel: [6.996114] Latest git patches (needed
> if you report a bug to linux-media@vger.kernel.org):
> May  9 19:32:37 retraite kernel: [6.996115]
> 02615ed5e1b2283db2495af3cf8f4ee172c77d80 [media] cx88: make core less
> verbose
> May  9 19:32:37 retraite kernel: [6.996116]
> a3b60209e7dd4db05249a9fb27940bb6705cd186 [media] em28xx: fix oops at
> em28xx_dvb_bus_ctrl()
> May  9 19:32:37 retraite kernel: [6.996117]
> 4494f0fdd825958d596d05a4bd577df94b149038 [media] s5c73m3: fix indentation of
> the help section in Kconfig
> May  9 19:32:37 retraite kernel: [7.055361] WARNING: You are using an
> experimental version of the media stack.
> May  9 19:32:37 retraite kernel: [7.055363] As the driver is
> backported to an older kernel, it doesn't offer
> May  9 19:32:37 retraite kernel: [7.055364] enough quality for its
> usage in production.
> May  9 19:32:37 retraite kernel: [7.055365] Use it with care.
> May  9 19:32:37 retraite kernel: [7.055366] Latest git patches (needed
> if you report a bug to linux-media@vger.kernel.org):
> May  9 19:32:37 retraite kernel: [7.055367]
> 02615ed5e1b2283db2495af3cf8f4ee172c77d80 [media] cx88: make core less
> verbose
> May  9 19:32:37 retraite kernel: [7.055369]
> a3b60209e7dd4db05249a9fb27940bb6705cd186 [media] em28xx: fix oops at
> em28xx_dvb_bus_ctrl()
> May  9 19:32:37 retraite kernel: [    7.055370]
> 4494f0fdd825958d596d05a4bd577df94b149038 [media] s5c73m3: fix indentation of
> the help section in Kconfig
>
> Pierre
>
> Le 09/05/2013 18:12, Alex Deucher a écrit :
>
> On Thu, May 9, 2013 at 11:04 AM, pierre  wrote:
>
> Hi,
>
> Some difficult on wheezy, on my computer
> product: Inspiron 620
> vendor: Dell Inc.
> version: 00
> serial: D9V135J
> width: 64 bits
>
> My sound card is now defined as Caicos HDMI Audio [Radeon HD 6400 Series]
> Digital Stereo (HDMI) on Squeeze, it was HD-Audio Generic Digital Stereo
> (HDMI).
> It works but i'm not able to get analogic output, only HDMI / display port
> that i can't use.
>
> You need to enable the audio parameter in the radeon driver.  Boot with:
> radeon.audio=1
> on the kernel command line in grub.
>
> Alex
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HD-Audio Generic HDMI/DP on wheezy

[Alex Deucher]

On Thu, May 9, 2013 at 11:04 AM, pierre  wrote:
> Hi,
>
> Some difficult on wheezy, on my computer
> product: Inspiron 620
> vendor: Dell Inc.
> version: 00
> serial: D9V135J
> width: 64 bits
>
> My sound card is now defined as Caicos HDMI Audio [Radeon HD 6400 Series]
> Digital Stereo (HDMI) on Squeeze, it was HD-Audio Generic Digital Stereo
> (HDMI).
> It works but i'm not able to get analogic output, only HDMI / display port
> that i can't use.

You need to enable the audio parameter in the radeon driver.  Boot with:
radeon.audio=1
on the kernel command line in grub.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CDF meeting @FOSDEM report

[Alex Deucher]

On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen  wrote:
> Hi,
>
> On 2013-02-06 00:27, Laurent Pinchart wrote:
>> Hello,
>>
>> We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary
>> of the discussions.
>
> Thanks for the summary. I've been on a longish leave, and just got back,
> so I haven't read the recent CDF discussions on lists yet. I thought
> I'll start by replying to this summary first =).
>
>> 0. Abbreviations
>> 
>>
>> DBI - Display Bus Interface, a parallel video control and data bus that
>> transmits data using parallel data, read/write, chip select and address
>> signals, similarly to 8051-style microcontroller parallel busses. This is a
>> mixed video control and data bus.
>>
>> DPI - Display Pixel Interface, a parallel video data bus that transmits data
>> using parallel data, h/v sync and clock signals. This is a video data bus
>> only.
>>
>> DSI - Display Serial Interface, a serial video control and data bus that
>> transmits data using one or more differential serial lines. This is a mixed
>> video control and data bus.
>
> In case you'll re-use these abbrevs in later posts, I think it would be
> good to mention that DPI is a one-way bus, whereas DBI and DSI are
> two-way (perhaps that's implicit with control bus, though).
>
>> 1. Goals
>> 
>>
>> The meeting started with a brief discussion about the CDF goals.
>>
>> Tomi Valkeinin and Tomasz Figa have sent RFC patches to show their views of
>> what CDF could/should be. Many others have provided very valuable feedback.
>> Given the early development stage propositions were sometimes contradictory,
>> and focused on different areas of interest. We have thus started the meeting
>> with a discussion about what CDF should try to achieve, and what it 
>> shouldn't.
>>
>> CDF has two main purposes. The original goal was to support display panels in
>> a platform- and subsystem-independent way. While mostly useful for embedded
>> systems, the emergence of platforms such as Intel Medfield and ARM-based PCs
>> that blends the embedded and PC worlds makes panel support useful for the PC
>> world as well.
>>
>> The second purpose is to provide a cross-subsystem interface to support video
>> encoders. The idea originally came from a generalisation of the original RFC
>> that supported panels only. While encoder support is considered as lower
>> priority than display panel support by developers focussed on display
>> controller driver (Intel, Renesas, ST Ericsson, TI), companies that produce
>> video encoders (Analog Devices, and likely others) don't share that point of
>> view and would like to provide a single encoder driver that can be used in
>> both KMS and V4L2 drivers.
>
> What is an encoder? Something that takes a video signal in, and lets the
> CPU store the received data to memory? Isn't that a decoder?
>
> Or do you mean something that takes a video signal in, and outputs a
> video signal in another format? (transcoder?)

In KMS parlance, we have two objects a crtc and an encoder.  A crtc
reads data from memory and produces a data stream with display timing.
 The encoder then takes that datastream and timing from the crtc and
converts it some sort of physical signal (LVDS, TMDS, DP, etc.).  It's
not always a perfect match to the hardware.  For example a lot of GPUs
have a DVO encoder which feeds a secondary encoder like an sil164 DVO
to TMDS encoder.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Asus PVR-416

[Alex Deucher]

On Mon, Jul 30, 2012 at 6:57 AM, Jerry Haggard  wrote:
> I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on
> Scientific Linux 6.  I have a bttv card working, my setup works in general,
> etc, and the driver attempts to load.  But when I check dmesg, I keep
> getting firmware load errors and checksum errors. I've tried every firmware
> I could find.  I've used the one from Atrpms, I've downloaded the correctly
> named firmware from ivtv, but no luck.  Anyone know anything about this
> card?  I've tried cutting the drivers myself like it says in the direcitons
> at mythtv.org. This is supposed to be a supported card, does anyone have any
> experience with it?

I've got one and it worked years ago, but I haven't used it since.
IIRC, the initial blackbird support was added using this card, but I'm
not sure what the current state is.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATI theatre 750 HD tuner USB stick

[Alex Deucher]

On Wed, Jul 4, 2012 at 9:27 AM, Fisher Grubb  wrote:
> Hi all,
>
> I was in contact with AMD today regarding this tuner haveing no
> support on Linux and I was given a link for a feedback form and told
> to get specific needs from www.linuxtv.org to help the cause and if
> there were enough people, then the AMD developers may help.
>
> Of course I wouldn't be surprised if people will have to reverse
> engineer it from the windows drivers but I thought I would mention it.
>  I could not find any info on this 750 HD on www.linuxtv.org regarding
> where it stands.  What help is needed for it?

Unfortunately, I don't think there is much AMD can do.  We sold our
multimedia DTV division to Broadcom several years ago.  IANAL, so I
don't know exactly what rights we retained for the IP.  You may need
to talk to Broadcom now.

Alex

>
> Fisher
>
> On Wed, Jul 4, 2012 at 11:21 PM, Fisher Grubb  wrote:
>> Hi all,
>>
>> My name is Fisher Grubb, I have an ATI (now AMD) theatre 750 HD based
>> TV tuner USB stick.  I don't think this ATI chipset is supported by
>> linuxTV and have had no joy search google as others also hit a dead
>> end.
>>
>> I have put USB bus dump for that device and the chip part numbers at the 
>> bottom.
>>
>> Please may I have a quick reply if someone looks at this, thanks.
>>
>> Model number is U5071, manufacturer site: 
>> http://www.geniatech.com/pa/u5071.asp
>>
>> I think this is a very impressive piece of hardware as it can do:
>> Analogue TV, DVB, AV capture and S video capture.  There is an IR
>> receiver on board and came with IR remote control.
>>
>> I'm happy to provide any info on it that you may want such as picture
>> of board & chips.  I'm almost finished my electronics degree and so
>> can do hardware probing if someone may give me something specific to
>> look for.  I'm also happy to run software or commands to dump stuff or
>> even help with dumping things from the windows drivers if I've given
>> directions etc.
>>
>> Thank you,
>>
>> Fisher
>>
>> lsusb: Bus 002 Device 021: ID 0438:ac14 Advanced Micro Devices, Inc.
>>
>> sudo lsusb -vd 0438:ac14
>>
>> Bus 002 Device 021: ID 0438:ac14 Advanced Micro Devices, Inc.
>> Device Descriptor:
>>   bLength18
>>   bDescriptorType 1
>>   bcdUSB   2.00
>>   bDeviceClass0 (Defined at Interface level)
>>   bDeviceSubClass 0
>>   bDeviceProtocol 0
>>   bMaxPacketSize064
>>   idVendor   0x0438 Advanced Micro Devices, Inc.
>>   idProduct  0xac14
>>   bcdDevice1.00
>>   iManufacturer   1 AMD
>>   iProduct2 Cali TV Card
>>   iSerial 3 1234-5678
>>   bNumConfigurations  1
>>   Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength   97
>> bNumInterfaces  1
>> bConfigurationValue 1
>> iConfiguration  0
>> bmAttributes 0x80
>>   (Bus Powered)
>> MaxPower  500mA
>> Interface Descriptor:
>>   bLength 9
>>   bDescriptorType 4
>>   bInterfaceNumber0
>>   bAlternateSetting   0
>>   bNumEndpoints   5
>>   bInterfaceClass   255 Vendor Specific Class
>>   bInterfaceSubClass255 Vendor Specific Subclass
>>   bInterfaceProtocol255 Vendor Specific Protocol
>>   iInterface  0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81  EP 1 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0200  1x 512 bytes
>> bInterval   0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x82  EP 2 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0200  1x 512 bytes
>> bInterval   0
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03  EP 3 OUT
>> bmAttributes2
>>   Transfer TypeBulk
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxPacketSize 0x0200  1x 512 bytes
>> bInterval   3
>>   Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x84  EP 4 IN
>> bmAttributes2
>>   Transfer TypeBulk
>>   Synch Type   None
>>   Usage Type   Data
>> wMaxP

Re: Unknown eMPIA tuner

[Alex Deucher]

On Tue, Apr 10, 2012 at 3:49 PM, Stefan Monnier
 wrote:
>> Ok, so it's an em2874/drx-j/tda18271 design, which in terms of the
>> components is very similar to the PCTV 80e (which I believe Mauro got
>> into staging recently).  I would probably recommend looking at that
>> code as a starting point.
>
> Any pointers to actual file names?
>
>> That said, you'll need to figure out the correct IF frequency, the
>> drx-j configuration block, the GPIO layout, and the correct tuner
>> config.  If those terms don't mean anything to you, then you are best
>> to wait until some developer stumbles across the device and has the
>> time to add the needed support.
>
> The words aren't meaningless to me, but not too far either.  Maybe if
> someone could give me pointers as to how I could try to figure out the
> corresponding info, I could give it a try.

Probably useful to start with the config from a similar card (lots of
vendors use the same reference design) and see how much of it works
then tweak from there until you get it fully working.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Display hotplug

[Alex Deucher]

On Tue, Oct 25, 2011 at 5:09 AM, James Courtier-Dutton
 wrote:
> Hi,
>
> Does anyone know when X will support display hotplug?
> I have a PC connected via HDMI to a TV.
> Unless I turn the TV on first, I have to reboot the PC before it
> displays anything on the HDMI TV.

It's be supported on all modern KMS drivers (radeon, intel, nouveau)
assuming you have a recent enough userspace to deal with the hotplug
uevents.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Alex Deucher]

On Thu, Mar 24, 2011 at 3:13 PM, Guennadi Liakhovetski
 wrote:
> On Thu, 24 Mar 2011, K, Mythri P wrote:
>
>> Hi Jesse,
>>
>> On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes  
>> wrote:
>> > On Wed, 23 Mar 2011 18:58:27 +0530
>> > "K, Mythri P"  wrote:
>> >
>> >> Hi Dave,
>> >>
>> >> On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie  wrote:
>> >> > On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K  wrote:
>> >> >> Adding support for common EDID parsing in kernel.
>> >> >>
>> >> >> EDID - Extended display identification data is a data structure 
>> >> >> provided by
>> >> >> a digital display to describe its capabilities to a video source, This 
>> >> >> a
>> >> >> standard supported by CEA and VESA.
>> >> >>
>> >> >> There are several custom implementations for parsing EDID in kernel, 
>> >> >> some
>> >> >> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
>> >> >> parsing of EDID should be done in a library, which is agnostic of the
>> >> >> framework (V4l2, DRM, FB)  which is using the functionality, just 
>> >> >> based on
>> >> >> the raw EDID pointer with size/segment information.
>> >> >>
>> >> >> With other RFC's such as the one below, which tries to standardize 
>> >> >> HDMI API's
>> >> >> It would be better to have a common EDID code in one place.It also 
>> >> >> helps to
>> >> >> provide better interoperability with variety of TV/Monitor may be even 
>> >> >> by
>> >> >> listing out quirks which might get missed with several custom 
>> >> >> implementation
>> >> >> of EDID.
>> >> >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>> >> >>
>> >> >> This patch tries to add functions to parse some portion EDID (detailed 
>> >> >> timing,
>> >> >> monitor limits, AV delay information, deep color mode support, Audio 
>> >> >> and VSDB)
>> >> >> If we can align on this library approach i can enhance this library to 
>> >> >> parse
>> >> >> other blocks and probably we could also add quirks from other 
>> >> >> implementation
>> >> >> as well.
>> >> >>
>> >> >
>> >> > If you want to take this approach, you need to start from the DRM EDID 
>> >> > parser,
>> >> > its the most well tested and I can guarantee its been plugged into more 
>> >> > monitors
>> >> > than any of the others. There is just no way we would move the DRM 
>> >> > parser to a
>> >> > library one that isn't derived from it + enhancements, as we'd throw 
>> >> > away the
>> >> > years of testing and the regression count would be way too high.
>> >> >
>> >> I had a look at the DRM EDID code, but for quirks it looks pretty much 
>> >> the same.
>> >> yes i could take quirks and other DRM tested code and enhance, but
>> >> still the code has to do away with struct drm_display_mode
>> >> which is very much custom to DRM.
>> >
>> > If that's the only issue you have, we could easily rename that
>> > structure or add conversion funcs to a smaller structure if that's what
>> > you need.
>> >
>> > Dave's point is that we can't ditch the existing code without
>> > introducing a lot of risk; it would be better to start a library-ized
>> > EDID codebase from the most complete one we have already, i.e. the DRM
>> > EDID code.
>
> Does the DRM EDID-parser also process blocks beyond the first one and
> also parses SVD entries similar to what I've recently added to fbdev? Yes,
> we definitely need a common EDID parses, and maybe we'll have to collect
> various pieces from different implementations.

At the moment there is only limited support for looking up things like
the hdmi block and checking for audio.

Alex

>
> Thanks
> Guennadi
>
>> >
>> This sounds good. If we can remove the DRM dependent portion to have a
>> library-ized EDID code,
>> That would be perfect. The main Intention to have a library is,
>> Instead of having several different Implementation in kernel, all
>> doing the same EDID parsing , if we could have one single
>> implementation , it would help in better testing and interoperability.
>>
>> > Do you really think the differences between your code and the existing
>> > DRM code are irreconcilable?
>> >
>> On the contrary if there is a library-ized  EDID parsing using the
>> drm_edid, and there is any delta / fields( Parsing the video block in
>> CEA extension for Short Video Descriptor, Vendor block for AV delay
>> /Deep color information etc) that are parsed with the RFC i posted i
>> would be happy to add.
>>
>> Thanks and regards,
>> Mythri.
>> > --
>> > Jesse Barnes, Intel Open Source Technology Center
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  htt

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Alex Deucher]

Adding dri-devel.

On Tue, Mar 22, 2011 at 1:32 PM, Mythri P K  wrote:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB)  which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>
> Signed-off-by: Mythri P K 
> ---
>  arch/arm/include/asm/edid.h |  243 ++
>  drivers/video/edid.c        |  340 
> +++
>  2 files changed, 583 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/edid.h
>  create mode 100644 drivers/video/edid.c
>
> diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
> new file mode 100644
> index 000..843346a
> --- /dev/null
> +++ b/arch/arm/include/asm/edid.h
> @@ -0,0 +1,243 @@
> +/*
> + * edid.h
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + * History:
> + */
> +
> +#ifndef _EDID_H_
> +#define _EDID_H_
> +
> +/* HDMI EDID Length */
> +#define HDMI_EDID_MAX_LENGTH                   512
> +
> +/* HDMI EDID Extension Data Block Tags  */
> +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK                0xE0
> +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK                0x1F
> +
> +#define EDID_TIMING_DESCRIPTOR_SIZE            0x12
> +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS         0x36
> +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS         0x80
> +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR     4
> +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR     4
> +
> +/* EDID Detailed Timing        Info 0 begin offset */
> +#define HDMI_EDID_DETAILED_TIMING_OFFSET       0x36
> +
> +#define HDMI_EDID_PIX_CLK_OFFSET               0
> +#define HDMI_EDID_H_ACTIVE_OFFSET              2
> +#define HDMI_EDID_H_BLANKING_OFFSET            3
> +#define HDMI_EDID_V_ACTIVE_OFFSET              5
> +#define HDMI_EDID_V_BLANKING_OFFSET            6
> +#define HDMI_EDID_H_SYNC_OFFSET                        8
> +#define HDMI_EDID_H_SYNC_PW_OFFSET             9
> +#define HDMI_EDID_V_SYNC_OFFSET                        10
> +#define HDMI_EDID_V_SYNC_PW_OFFSET             11
> +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET          12
> +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET          13
> +#define HDMI_EDID_H_BORDER_OFFSET              15
> +#define HDMI_EDID_V_BORDER_OFFSET              16
> +#define HDMI_EDID_FLAGS_OFFSET                 17
> +
> +/* HDMI EDID DTDs */
> +#define HDMI_EDID_MAX_DTDS                     4
> +
> +/* HDMI EDID DTD Tags */
> +#define HDMI_EDID_DTD_TAG_MONITOR_NAME         0xFC
> +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM    0xFF
> +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS       0xFD
> +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
> +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA     0xFB
> +#define HDMI_EDID_DTD_TAG_ASCII_STRING         0xFE
> +
> +#define HDMI_IMG_FORMAT_MAX_LENGTH             20
> +#define HDMI_AUDIO_FORMAT_MAX_LENGTH           10
> +
> +/* HDMI EDID Extenion Data Block Values: Video */
> +#define HDMI_EDID_EX_VIDEO_NATIVE              0x80
> +#define HDMI_EDID_EX_VIDEO_MASK                        0x7F
> +#define HDMI_EDID_EX_VIDEO_MAX                 35
> +
> +#define STANDARD_HDMI_TIMINGS_NB               34
> +#define STANDARD_HDMI_T

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Wed, Mar 16, 2011 at 1:49 PM, Laurent Pinchart
 wrote:
> Hi Alex,
>
> On Wednesday 16 March 2011 17:09:45 Alex Deucher wrote:
>> On Wed, Mar 16, 2011 at 3:37 AM, Li Li  wrote:
>> > Sorry but I feel the discussion is a bit off the point. We're not
>> > going to compare the pros and cons of current code (GEM/TTM, HWMEM,
>> > UMP, CMA, VCM, CMEM, PMEM, etc.)
>> >
>> > The real problem is to find a suitable unified memory management
>> > module for various kinds of HW components (including CPU, VPU, GPU,
>> > camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires
>> > physical continuous big chunk of memory (e.g. some VPU & OVL); while
>> > others could live with DMA chain (e.g. some powerful GPU has built-in
>> > MMU).
>> >
>> > So, what's current situation?
>> >
>> > 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the
>> > DRM framework (w/ KMS, etc.). This works fine on conventional (mostly
>> > Xorg-based) Linux distribution.
>> >
>> > 2) But DRM (or GEM/TTM) is still too heavy and complex to some
>> > embedded OS, which only want a cheaper memory management module. So...
>> >
>> > 2.1) Google uses PMEM in Android - However PMEM was removed from
>> > upstream kernel for well-known reasons;
>> >
>> > 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However
>> > KGSL was shamed in dri-devel list because their close user space
>> > binary.
>> >
>> > 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This
>> > makes things even more complicated. (Therefore I personally think this
>> > is actually a shame for ARM to create another private SW. As a leader
>> > of Linaro, ARM should think more and coordinate with partners better
>> > to come up a unified solution to make our life easier.)
>> >
>> > 2.4) Other companies also have their own private solutions because
>> > nobody can get a STANDARD interface from upstream, including Marvell,
>> > TI, Freescale.
>> >
>> >
>> >
>> > In general, it would be highly appreciated if Linaro guys could sit
>> > down together around a table, co-work with silicon vendors and
>> > upstream Linux kernel maintainers to make a unified (and cheaper than
>> > GEM/TTM/DRM) memory management module. This module should be reviewed
>> > carefully and strong enough to replace any other private memory
>> > manager mentioned above. It should replace PMEM for Android (with
>> > respect to Gralloc). And it could even be leveraged in DRM framework
>> > (as a primitive memory allocation provider under GEM).
>> >
>> > Anyway, such a module is necessary, because user space application
>> > cannot exchange enough information by a single virtual address (among
>> > different per-process virtual address space). Gstreamer, V4L and any
>> > other middleware could remain using a single virtual address in the
>> > same process. But a global handler/ID is also necessary for sharing
>> > buffers between processes.
>> >
>> > Furthermore, besides those well-known basic features, some advanced
>> > APIs should be provided for application to map the same physical
>> > memory region into another process, with 1) manageable fine
>> > CACHEable/BUFFERable attributes and cache flush mechanism (for
>> > performance); 2) lock/unlock synchronization; 3) swap/migration
>> > ability (optional in current stage, as those buffer are often expected
>> > to stay in RAM for better performance).
>> >
>> > Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO
>> > UPSTREAM (sorry, please ignore all the nonsense I wrote above if we
>> > can achieve this) so that everyone treat it as a de facto well
>> > supported memory management module. Thus all companies could transit
>> > from current private design to this public one. And, let's cheer for
>> > the end of this damn chaos!
>>
>> FWIW, I don't know if a common memory management API is possible.  On
>> the GPU side we tried, but there ended up being too many weird
>> hardware quirks from vendor to vendor (types of memory addressable,
>> strange tiling formats, etc.).  You might be able to come up with some
>> kind of basic framework like TTM, but by the time you add the
>> necessary quirks for various hw, it may be bigger than you want.
>> That's why we have GEM and TTM and driver specific memo

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Wed, Mar 16, 2011 at 3:37 AM, Li Li  wrote:
> Sorry but I feel the discussion is a bit off the point. We're not
> going to compare the pros and cons of current code (GEM/TTM, HWMEM,
> UMP, CMA, VCM, CMEM, PMEM, etc.)
>
> The real problem is to find a suitable unified memory management
> module for various kinds of HW components (including CPU, VPU, GPU,
> camera, FB/OVL, etc.), especially for ARM based SOC. Some HW requires
> physical continuous big chunk of memory (e.g. some VPU & OVL); while
> others could live with DMA chain (e.g. some powerful GPU has built-in
> MMU).
>
> So, what's current situation?
>
> 1) As Hans mentioned, there're GEM & TTM in upstream kernel, under the
> DRM framework (w/ KMS, etc.). This works fine on conventional (mostly
> Xorg-based) Linux distribution.
>
> 2) But DRM (or GEM/TTM) is still too heavy and complex to some
> embedded OS, which only want a cheaper memory management module. So...
>
> 2.1) Google uses PMEM in Android - However PMEM was removed from
> upstream kernel for well-known reasons;
>
> 2.2) Qualcomm writes a hybrid KGSL based DRM+PMEM solution - However
> KGSL was shamed in dri-devel list because their close user space
> binary.
>
> 2.3) ARM starts UMP/MaliDRM for both of Android and X11/DRI2 - This
> makes things even more complicated. (Therefore I personally think this
> is actually a shame for ARM to create another private SW. As a leader
> of Linaro, ARM should think more and coordinate with partners better
> to come up a unified solution to make our life easier.)
>
> 2.4) Other companies also have their own private solutions because
> nobody can get a STANDARD interface from upstream, including Marvell,
> TI, Freescale.
>
>
>
> In general, it would be highly appreciated if Linaro guys could sit
> down together around a table, co-work with silicon vendors and
> upstream Linux kernel maintainers to make a unified (and cheaper than
> GEM/TTM/DRM) memory management module. This module should be reviewed
> carefully and strong enough to replace any other private memory
> manager mentioned above. It should replace PMEM for Android (with
> respect to Gralloc). And it could even be leveraged in DRM framework
> (as a primitive memory allocation provider under GEM).
>
> Anyway, such a module is necessary, because user space application
> cannot exchange enough information by a single virtual address (among
> different per-process virtual address space). Gstreamer, V4L and any
> other middleware could remain using a single virtual address in the
> same process. But a global handler/ID is also necessary for sharing
> buffers between processes.
>
> Furthermore, besides those well-known basic features, some advanced
> APIs should be provided for application to map the same physical
> memory region into another process, with 1) manageable fine
> CACHEable/BUFFERable attributes and cache flush mechanism (for
> performance); 2) lock/unlock synchronization; 3) swap/migration
> ability (optional in current stage, as those buffer are often expected
> to stay in RAM for better performance).
>
> Finally, and the most important, THIS MODULE SHOULD BE PUSHED TO
> UPSTREAM (sorry, please ignore all the nonsense I wrote above if we
> can achieve this) so that everyone treat it as a de facto well
> supported memory management module. Thus all companies could transit
> from current private design to this public one. And, let's cheer for
> the end of this damn chaos!

FWIW, I don't know if a common memory management API is possible.  On
the GPU side we tried, but there ended up being too many weird
hardware quirks from vendor to vendor (types of memory addressable,
strange tiling formats, etc.).  You might be able to come up with some
kind of basic framework like TTM, but by the time you add the
necessary quirks for various hw, it may be bigger than you want.
That's why we have GEM and TTM and driver specific memory management
ioctls in the drm.

Alex

>
> Thanks,
> Lea
>
> On Wed, Mar 16, 2011 at 12:47 AM, Alex Deucher  wrote:
>> On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete
>>  wrote:
>>> On 8 March 2011 20:23, Laurent Pinchart
>>>  wrote:
>>>> Hi Andy,
>>>>
>>>> On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
>>>>> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>> > > > It really shouldn't be that hard to get everyone involved together
>>>>> > > > and settle on a single solution (either based on an existing
>>>>> > > > proposal or create a 'the best of' vendor-n

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Wed, Mar 16, 2011 at 4:52 AM, Laurent Pinchart
 wrote:
> Hi Alex,
>
> On Tuesday 15 March 2011 17:47:47 Alex Deucher wrote:
>
> [snip]
>
>> FWIW, I have yet to see any v4l developers ever email the dri mailing
>> list while discussing GEM, TTM, or the DRM, all the while conjecturing
>> on aspects of it they admit to not fully understanding.  For future
>> reference, the address is: .  We are
>> happy to answer questions.
>
> Please don't see any malice there. Even though the topic has been on our table
> for quite some time now, we're only starting to actively work on it. The first
> step is to gather our requirements (this will likely be done this week, during
> the V4L2 brainstorming meeting in Warsaw). We will then of course contact
> DRM/DRI developers.

Sorry, it came out a little harsher than I wanted.  I just want to
avoid duplication of effort if possible.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Tue, Mar 15, 2011 at 12:07 PM, Robert Fekete
 wrote:
> On 8 March 2011 20:23, Laurent Pinchart
>  wrote:
>> Hi Andy,
>>
>> On Tuesday 08 March 2011 20:12:45 Andy Walls wrote:
>>> On Tue, 2011-03-08 at 16:52 +0100, Laurent Pinchart wrote:
>>>
>>> [snip]
>>>
>>> > > > It really shouldn't be that hard to get everyone involved together
>>> > > > and settle on a single solution (either based on an existing
>>> > > > proposal or create a 'the best of' vendor-neutral solution).
>>> > >
>>> > > "Single" might be making the problem impossibly hard to solve well.
>>> > > One-size-fits-all solutions have a tendency to fall short on meeting
>>> > > someone's critical requirement.  I will agree that "less than n", for
>>> > > some small n, is certainly desirable.
>>> > >
>>> > > The memory allocators and managers are ideally satisfying the
>>> > > requirements imposed by device hardware, what userspace applications
>>> > > are expected to do with the buffers, and system performance.  (And
>>> > > maybe the platform architecture, I/O bus, and dedicated video memory?)
>>> >
>>> > In the embedded world, a very common use case is to capture video data
>>> > from an ISP (V4L2+MC), process it in a DSP (V4L2+M2M, tidspbridge, ...)
>>> > and display it on the GPU (OpenGL/ES). We need to be able to share a
>>> > data buffer between the ISP and the DSP, and another buffer between the
>>> > DSP and the GPU. If processing is not required, sharing a data buffer
>>> > between the ISP and the GPU is required. Achieving zero-copy requires a
>>> > single memory management solution used by the ISP, the DSP and the GPU.
>>>
>>> Ah.  I guess I misunderstood what was meant by "memory provider" to some
>>> extent.
>>>
>>> So what I read is a common way of providing in kernel persistent buffers
>>> (buffer objects? buffer entities?) for drivers and userspace
>>> applications to pass around by reference (no copies).  Userspace may or
>>> may not want to see the contents of the buffer objects.
>>
>> Exactly. How that memory is allocated in irrelevant here, and we can have
>> several different allocators as long as the buffer objects can be managed
>> through a single API. That API will probably have to expose buffer properties
>> related to allocation, in order for all components in the system to verify
>> that the buffers are suitable for their needs, but the allocation process
>> itself is irrelevant.
>>
>>> So I understand now why a single solution is desirable.
>>
>
> Exactly,
>
> It is important to know that there are 3 topics of discussion which
> all are a separate topic of its own:
>
> 1. The actual memory allocator
> 2. In-kernel API
> 3. Userland API
>
> Explained:
> 1. This is how you acquire the actual physical or virtual memory,
> defrag, swap, etc. This can be enhanced by CMA, hotswap, memory
> regions or whatever and the main topic for a system wide memory
> allocator does not deal much with how this is done.
> 2. In-kernel API is important from a device driver point of view in
> order to resolve buffers, pin memory when used(enable defrag when
> unpinned)
> 3. Userland API deals with alloc/free, import/export(IPC), security,
> and set-domain capabilities among others and is meant to pass buffers
> between processes in userland and enable no-copy data paths.
>
> We need to resolve 2. and 3.
>
> GEM/TTM is mentioned in this thread and there is an overlap of what is
> happening within DRM/DRI/GEM/TTM/KMS and V4L2. The whole idea behind
> DRM is to have one device driver for everything (well at least 2D/3D,
> video codecs, display output/composition), while on a SoC all this is
> on several drivers/IP's. A V4L2 device cannot resolve a GEM handle.
> GEM only lives inside one DRM device (AFAIK). GEM is also mainly for
> "dedicated memory-less" graphics cards while TTM mainly targets
> advanced Graphics Card with dedicated memory. From a SoC point of view
> DRM looks very "fluffy" and not quite slimmed for an embedded device,
> and you cannot get GEM/TTM without bringing in all of DRM/DRI. KMS on
> the other hand is very attractive as a framebuffer device replacer. It
> is not an easy task to decide on a multimedia user interface for a SoC
> vendor.

Modern GPUs are basically an SoC: 3D engine, video decode, hdmi packet
engines, audio, dma engine, display blocks, etc. with a shared memory
controller.  Also the AMD fusion and Intel moorestown SoCs are not too
different from ARM-based SoCs and we are supporting them with the drm.
 I expect we'll see the x86 and ARM/MIPS based SoCs continue to get
closer together.

What are you basing your "fluffy" statement on?  We recently merged a
set of patches from qualcomm to support platform devices in the drm
and Dave added support for USB devices. Qualcomm also has an open
source drm for their snapdragon GPUs (although the userspace driver is
closed) and they are using that on their SoCs.

>
> Uniting the frameworks within the kernel will likely fail(too big of a
> task) but a common system w

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Tue, Mar 8, 2011 at 9:01 AM, Andy Walls  wrote:
> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
>> Hi all,
>>
>> We had a discussion yesterday regarding ways in which linaro can assist
>> V4L2 development. One topic was that of sorting out memory providers like
>> GEM and HWMEM.
>>
>> Today I learned of yet another one: UMP from ARM.
>>
>> http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
>>
>> This is getting out of hand. I think that organizing a meeting to solve this
>> mess should be on the top of the list. Companies keep on solving the same
>> problem time and again and since none of it enters the mainline kernel any
>> driver using it is also impossible to upstream.
>>
>> All these memory-related modules have the same purpose: make it possible to
>> allocate/reserve large amounts of memory and share it between different
>> subsystems (primarily framebuffer, GPU and V4L).
>
> I'm not sure that's the entire story regarding what the current
> allocators for GPU do.  TTM and GEM create in kernel objects that can be
> passed between applications.  TTM apparently has handling for VRAM
> (video RAM).  GEM uses anonymous userspace memory that can be swapped
> out.

TTM can handle pretty much any "type" of memory, it's just a basic
memory manager.  You specify things cacheability attributes when you
set up the pools.

Generally on GPUs we see 3 types of buffers:
1. video ram connected to the GPU.  Often some or all of that pool is
not accessible by the CPU.  The GPU usually provides a mechanism to
migrate the buffer to a pool or region that is accessible to the CPU.
Vram buffers are usually mapped uncached write-combined.
2. GART/GTT (Graphics Address Remapping Table) memory.  This is
DMAable system memory that is mapped into the GPU's address space and
remapped to look linear to the GPU.  It can either be cached or
uncached pages depending on the GPU's capabilities and what the
buffers are used for.
3. unpinned system pages.  Depending on the GPU, they have to be
copied to DMAable memory before the GPU can access them.

The DRI protocol (used for communication between GPU acceleration
drivers) doesn't really care what the underlying memory manager is.
It just passes around handles.

Alex

>
> TTM:
> http://lwn.net/Articles/257417/
> http://www.x.org/wiki/ttm
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf
> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf
>
> GEM:
> http://lwn.net/Articles/283798/
>
> GEM vs. TTM:
> http://lwn.net/Articles/283793/
>
>
> The current TTM and GEM allocators appear to have API and buffer
> processing and management functions tied in with memory allocation.
>
> TTM has fences for event notification of buffer processing completion.
> (maybe something v4l2 can do with v4l2_events?)
>
> GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem
> to mem API?)
>
>
> Thanks to the good work of developers on the LMML in the past year or
> two, V4L2 has separated out some of that functionality from video buffer
> allocation:
>
>        video buffer queue management and userspace access (videobuf2)
>        memory to memory buffer transformation/movement (m2m)
>        event notification (VIDIOC_SUBSCRIBE_EVENT)
>
>        http://lwn.net/Articles/389081/
>        http://lwn.net/Articles/420512/
>
>
>> It really shouldn't be that hard to get everyone involved together and settle
>> on a single solution (either based on an existing proposal or create a 'the
>> best of' vendor-neutral solution).
>
>
> "Single" might be making the problem impossibly hard to solve well.
> One-size-fits-all solutions have a tendency to fall short on meeting
> someone's critical requirement.  I will agree that "less than n", for
> some small n, is certainly desirable.
>
> The memory allocators and managers are ideally satisfying the
> requirements imposed by device hardware, what userspace applications are
> expected to do with the buffers, and system performance.  (And maybe the
> platform architecture, I/O bus, and dedicated video memory?)
>
>
>
>> I am currently aware of the following solutions floating around the net
>> that all solve different parts of the problem:
>>
>> In the kernel: GEM and TTM.
>> Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM.
>
> Prior to a meeting one would probably want to capture for each
> allocator:
>
> 1. What are the attributes of the memory allocated by this allocator?
>
> 2. For what domain was this allocator designed: GPU, video capture,
> video decoder, etc.
>
> 3. How are applications expected to use objects from this allocator?
>
> 4. What are the estimated sizes and lifetimes of objects that would be
> allocated this allocator?
>
> 5. Beyond memory allocation, what other functionality is built into this
> allocator: buffer queue management, event notification, etc.?
>
> 6. Of the requ

Re: Yet another memory provider: can linaro organize a meeting?

[Alex Deucher]

On Tue, Mar 8, 2011 at 12:23 PM, Hans Verkuil  wrote:
> On Tuesday, March 08, 2011 15:01:10 Andy Walls wrote:
>> On Tue, 2011-03-08 at 09:13 +0100, Hans Verkuil wrote:
>> > Hi all,
>> >
>> > We had a discussion yesterday regarding ways in which linaro can assist
>> > V4L2 development. One topic was that of sorting out memory providers like
>> > GEM and HWMEM.
>> >
>> > Today I learned of yet another one: UMP from ARM.
>> >
>> > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/
>> >
>> > This is getting out of hand. I think that organizing a meeting to solve 
>> > this
>> > mess should be on the top of the list. Companies keep on solving the same
>> > problem time and again and since none of it enters the mainline kernel any
>> > driver using it is also impossible to upstream.
>> >
>> > All these memory-related modules have the same purpose: make it possible to
>> > allocate/reserve large amounts of memory and share it between different
>> > subsystems (primarily framebuffer, GPU and V4L).
>>
>> I'm not sure that's the entire story regarding what the current
>> allocators for GPU do.  TTM and GEM create in kernel objects that can be
>> passed between applications.  TTM apparently has handling for VRAM
>> (video RAM).  GEM uses anonymous userspace memory that can be swapped
>> out.
>>
>> TTM:
>> http://lwn.net/Articles/257417/
>> http://www.x.org/wiki/ttm
>> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=mm.pdf
>> http://nouveau.freedesktop.org/wiki/TTMMemoryManager?action=AttachFile&do=get&target=xdevconf2006.pdf
>>
>> GEM:
>> http://lwn.net/Articles/283798/
>>
>> GEM vs. TTM:
>> http://lwn.net/Articles/283793/
>>
>>
>> The current TTM and GEM allocators appear to have API and buffer
>> processing and management functions tied in with memory allocation.
>>
>> TTM has fences for event notification of buffer processing completion.
>> (maybe something v4l2 can do with v4l2_events?)
>>
>> GEM tries avoid mapping buffers to userspace. (sounds like the v4l2 mem
>> to mem API?)
>>
>>
>> Thanks to the good work of developers on the LMML in the past year or
>> two, V4L2 has separated out some of that functionality from video buffer
>> allocation:
>>
>>       video buffer queue management and userspace access (videobuf2)
>>       memory to memory buffer transformation/movement (m2m)
>>       event notification (VIDIOC_SUBSCRIBE_EVENT)
>>
>>       http://lwn.net/Articles/389081/
>>       http://lwn.net/Articles/420512/
>>
>>
>> > It really shouldn't be that hard to get everyone involved together and 
>> > settle
>> > on a single solution (either based on an existing proposal or create a 'the
>> > best of' vendor-neutral solution).
>>
>>
>> "Single" might be making the problem impossibly hard to solve well.
>> One-size-fits-all solutions have a tendency to fall short on meeting
>> someone's critical requirement.  I will agree that "less than n", for
>> some small n, is certainly desirable.
>
> Actually, I think we really need one solution. I don't see how you can have
> it any other way without requiring e.g. gstreamer to support multiple
> 'solutions'.
>
>> The memory allocators and managers are ideally satisfying the
>> requirements imposed by device hardware, what userspace applications are
>> expected to do with the buffers, and system performance.  (And maybe the
>> platform architecture, I/O bus, and dedicated video memory?)
>>
>
> We discussed this before at the V4L2 brainstorm meeting in Oslo. The idea
> was to have opaque buffer IDs (more like cookies) that both kernel and
> userspace can use. You have some standard operations you can do with that
> and tied to the buffer is the knowledge (probably a set of function pointers
> in practice) of how to do each operation. So a buffer referring to video
> memory might have different code to e.g. obtain the virtual address compared
> to a buffer residing in regular memory.
>
> This way you would hide all these details while still have enough flexibility.
> It also allows you to support 'hidden' memory. It is my understanding that on
> some platforms (particular those used for set-top boxes) the video buffers are
> on memory that is not accessible from the CPU (rights management related). But
> apparently you still have to be able to refer to it. I may be wrong, it's
> something I was told.

A related example is vram on GPUs.  Often, the CPU can only mmap the
region of vram that is covered by the PCI framebuffer BAR, but the GPU
can access the entire vram pool.  As such in order to access the
buffer using the CPU, you either have to migrate it to a mappable
region of vram using the GPU (using a dma engine or a blit), or
migrate the buffer to another memory pool (such as gart memory -
system memory that is remapped into a linear aperture on the GPU).

Alex

>
>>
>>
>> > I am currently aware of the following solutions floating around the net
>> > that all solve diffe

Re: [ANN] Agenda for the Warsaw meeting.

[Alex Deucher]

On Sun, Mar 13, 2011 at 8:31 AM, Hans Verkuil  wrote:
> Agenda for V4L2 brainstorm meeting in Warsaw, March 16-18 2011.
>
> Purpose of the meeting: to brainstorm about current V4L2 API limitations
> with regards to required functionality. Ideally the results of the meeting
> are actual solutions to these problems, but at the very least we should
> have a concensus of what direction to take and who will continue working
> on each problem. The hope is that this meeting will save us endless email
> and irc discussions.
>
> It is *not* a summit meeting, so any conclusions need to be discussed and
> approved on the mailinglist.
>
> The basic outline is the same as during previous meetings: the first day we
> go through all the agenda points and make sure everyone understands the
> problem. Smaller issues will be discussed and decided, more complex issues
> are just discussed.
>
> The second day we go in depth into the complex issues and try to come up with
> ideas that might work. The last day we translate the all agenda items into
> actions.
>
> This approach worked well in the past and it ensures that we end up with
> something concrete.
>
> Those who have a vested interest in an agenda item should be prepared to
> explain their take on it and if necessary have a presentation ready.
>
> Besides the main agenda I also added a few items falling under the category
> 'if time permits'.
>
> Attendees:
>
> Samsung Poland R&D Center:
>  Kamil Debski 
>  Sylwester Nawrocki 
>  Tomasz Stanislawski 
>  Marek Szyprowski (Organizer) 
>
> Cisco Systems Norway:
>  Martin Bugge 
>  Hans Verkuil (Chair) 
>
> Nokia:
>  Sakari Ailus 
>
> Ideas On Board:
>  Laurent Pinchart 
>
> ST-Ericsson:
>  Willy Poisson 
>
> Samsung System.LSI Korea
>  Jonghun Han 
>  Jaeryul Oh 
>
> Samsung DMC Korea:
>   Seung-Woo Kim 
>
> Freelance:
>  Guennadi Liakhovetski 
>
>
> Agenda:
>
> 1) Compressed format API for MPEG, H.264, etc. Also need to discuss what to
>   do with weird 'H.264 inside MJPEG' muxed formats.
>   (Hans, Laurent, Samsung)
>
> 2) Small architecture enhancements:
>        - Acquiring subdevs from other devices using subdev pool
>          http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html
>          (Tomasz)
>        - Introducing subdev hierarchy. Below there is a link to driver using 
> it:
>          
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890
>          (Tomasz)
>        - Allow per-filehandle control handlers.
>          http://www.spinics.net/lists/linux-media/msg27975.html
>          (Jaeryul)
>        - How to control FrameBuffer device as v4l2 sub-device?
>          
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/29442/focus=29570
>          (Jaeryul)
>        - Which interface is better for Mixer of Exynos, frame buffer or V4l2?
>          http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html
>          (Jaeryul)
>        - Entity information ioctl
>          Some drivers (namely the uvcvideo driver) will need to report 
> driver-specific
>          information about each entity (the UVC entity GUID, the UVC controls 
> it
>          supports, ...). We need an API for that.
>          (Laurent)
>
> 3) Pipeline configuration, cropping and scaling:
>
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html
>
>   (Everyone)
>
> 4) HDMI receiver/transmitter API support
>
>   Some hotplug/CEC code can be found here:
>
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html
>
>   CEC RFC from Cisco Systems Norway:
>
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg29241.html
>
>   Hopefully we can post an initial HDMI RFC as well on Monday.
>
>   (Martin, Hans, Samsung, ST-Ericsson)
>
> 5) Sensor/Flash/Snapshot functionality.
>
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html
>   http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html
>
>   - Sensor blanking/pixel-clock/frame-rate settings (including
>     enumeration/discovery)
>
>   - Multiple video buffer queues per device (currently implemented in the
>     OMAP 3 ISP driver in non-standard way).
>
>   - Synchronising parameters (e.g. exposure time and gain) on given
>     frames. Some sensors support this on hardware. There are many use cases
>     which benefit from this, for example this one:
>
>     http://fcam.garage.maemo.org/>
>
>   - Flash synchronisation (might fall under the above topic).
>
>   - Frame metadata. It is important for the control algorithms (exposure,
>     white balance, for example), to know which sensor settings have been
>     used to expose a given frame. Many sensors do support this. Do we want
>     to parse this in the kernel or does it belong to user space? The
>     metadata formats are mostly sensor dependent.
>   (Everyone)
>
>
> Items 3 and 5 are 'the big ones'. Past e

Re: [RFC] HDMI-CEC proposal

[Alex Deucher]

On Wed, Mar 2, 2011 at 4:13 AM, Hans Verkuil  wrote:
> Hi Alex,
>
> On Tuesday, March 01, 2011 18:52:28 Alex Deucher wrote:
>> On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
>>  wrote:
>> > Author: Martin Bugge 
>> > Date:  Tue, 1 March 2010
>> > ==
>> >
>> > This is a proposal for adding a Consumer Electronic Control (CEC) API to
>> > V4L2.
>> > This document describes the changes and new ioctls needed.
>> >
>> > Version 1.0 (This is first version)
>> >
>> > Background
>> > ==
>> > CEC is a protocol that provides high-level control functions between
> various
>> > audiovisual products.
>> > It is an optional supplement to the High-Definition Multimedia Interface
>> > Specification (HDMI).
>> > Physical layer is a one-wire bidirectional serial bus that uses the
>> > industry-standard AV.link protocol.
>> >
>> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive
>> > small data-packets
>> >          (maximum 16 bytes including a 1 byte header) at low data rates
>> > (~400 bits/s).
>> >
>> > A CEC device may have any of 15 logical addresses (0 - 14).
>> > (address 15 is broadcast and some addresses are reserved)
>> >
>>
>> It would be nice if this was not tied to v4l as we'll start seeing CEC
>> support show in GPUs soon as well.
>
> As mentioned in other emails it is my firm believe that mixing APIs is a bad
> idea. I've never seen that work in practice. That said, I do think that any
> userspace CEC library shouldn't be tied to V4L allowing it to be used by GPUs.
>

Right.  That was my concern.  You are probably more of an expert on
CEC so I'll leave the API to you, but as it's going to show up in
GPUs, I'd rather not re-invent the wheel to support it on the GPU side
in some incompatible manner if it can be avoided.

> It would also be interesting to see if i2c HDMI receiver/transmitter drivers
> can be used by both subsystems. This would make a lot of sense.

There are already several i2c tmds drivers in the drm tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i2c;h=9eb6dad3ffa6cac6dfc07afb0b8526049416398b;hb=HEAD
And a few in the intel kms driver that could be broken out as
independent drivers.  See the dvo_*.c files in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm/i915;h=19e4b8fe8f5413f0c5d5059d8b2561eafab9e5dd;hb=HEAD
Still they are tied to the drm as they are used as kms encoders.


>
> Apologies if I asked this before, but are you planning to attend the ELC in
> San Francisco? If so, then we should sit together and compare the subsystems
> and see if we can work something out.

Probably not, but I'll know more soon.

Alex

>
> Regards,
>
>        Hans
>
>>
>> Alex
>>
>> >
>> > References
>> > ==
>> > [1] High-Definition Multimedia Interface Specification version 1.3a,
>> >    Supplement 1 Consumer Electronic Control (CEC).
>> >    http://www.hdmi.org/manufacturer/specification.aspx
>> >
>> > [2]
>> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>> >
>> >
>> > Proposed solution
>> > =
>> >
>> > Two new ioctls:
>> >    VIDIOC_CEC_CAP (read)
>> >    VIDIOC_CEC_CMD (read/write)
>> >
>> > VIDIOC_CEC_CAP:
>> > ---
>> >
>> > struct vl2_cec_cap {
>> >       __u32 logicaldevices;
>> >       __u32 reserved[7];
>> > };
>> >
>> > The capability ioctl will return the number of logical devices/addresses
>> > which can be
>> > simultaneously supported on this HW.
>> >    0:       This HW don't support CEC.
>> >    1 -> 14: This HW supports n logical devices simultaneously.
>> >
>> > VIDIOC_CEC_CMD:
>> > ---
>> >
>> > struct v4l2_cec_cmd {
>> >    __u32 cmd;
>> >    __u32 reserved[7];
>> >    union {
>> >        struct {
>> >            __u32 index;
>> >            __u32 enable;
>> >            __u32 addr;
>> >        } conf;
>> >        struct {
>> >            __u32 len;
>> >            __u8  msg[16];
>> >            __u32 status;
>> >        } data;
>> >        __u32 raw[8];
>> >    };
>> > };
>> >
>> &

Re: [RFC] HDMI-CEC proposal

[Alex Deucher]

On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
 wrote:
> Author: Martin Bugge 
> Date:  Tue, 1 March 2010
> ==
>
> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> V4L2.
> This document describes the changes and new ioctls needed.
>
> Version 1.0 (This is first version)
>
> Background
> ==
> CEC is a protocol that provides high-level control functions between various
> audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.
>
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> small data-packets
>          (maximum 16 bytes including a 1 byte header) at low data rates
> (~400 bits/s).
>
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
>

It would be nice if this was not tied to v4l as we'll start seeing CEC
support show in GPUs soon as well.

Alex

>
> References
> ==
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>    Supplement 1 Consumer Electronic Control (CEC).
>    http://www.hdmi.org/manufacturer/specification.aspx
>
> [2]
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>
>
> Proposed solution
> =
>
> Two new ioctls:
>    VIDIOC_CEC_CAP (read)
>    VIDIOC_CEC_CMD (read/write)
>
> VIDIOC_CEC_CAP:
> ---
>
> struct vl2_cec_cap {
>       __u32 logicaldevices;
>       __u32 reserved[7];
> };
>
> The capability ioctl will return the number of logical devices/addresses
> which can be
> simultaneously supported on this HW.
>    0:       This HW don't support CEC.
>    1 -> 14: This HW supports n logical devices simultaneously.
>
> VIDIOC_CEC_CMD:
> ---
>
> struct v4l2_cec_cmd {
>    __u32 cmd;
>    __u32 reserved[7];
>    union {
>        struct {
>            __u32 index;
>            __u32 enable;
>            __u32 addr;
>        } conf;
>        struct {
>            __u32 len;
>            __u8  msg[16];
>            __u32 status;
>        } data;
>        __u32 raw[8];
>    };
> };
>
> Alternatively the data struct could be:
>        struct {
>            __u8  initiator;
>            __u8  destination;
>            __u8  len;
>            __u8  msg[15];
>            __u32 status;
>        } data;
>
> Commands:
>
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
>
> Tx status field:
>
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>
> The command ioctl is used both for configuration and to receive/transmit
> data.
>
> * The configuration command must be done for each logical device address
>  which is to be enabled on this HW. Maximum number of logical devices
>  is found with the capability ioctl.
>    conf:
>         index:  0 -> number_of_logical_devices-1
>         enable: true/false
>         addr:   logical address
>
>  By default all logical devices are disabled.
>
> * Tx/Rx command
>    data:
>         len:    length of message (data + header)
>         msg:    the raw CEC message received/transmitted
>         status: when the driver is in blocking mode it gives the result for
> transmit.
>
> Events
> --
>
> In the case of non-blocking mode the driver will issue the following events:
>
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
>
> V4L2_EVENT_CEC_TX
> -
>  * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
>
> struct v4l2_event_cec_tx {
>       __u32 status;
> }
>
> V4L2_EVENT_CEC_RX
> -
>  * received a complete message
>
>
> Comments ?
>
>           Martin Bugge
>
> --
> Martin Bugge - Tandberg (now a part of Cisco)
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Alex Deucher]

On Wed, Feb 9, 2011 at 7:51 PM, Andy Walls  wrote:
> On Wed, 2011-02-09 at 02:12 -0500, Alex Deucher wrote:
>> On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls  wrote:
>> > On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote:
>> >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
>> >> > Just two quick notes. I'll try to do a full review this weekend.
>> >> >
>> >> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
>> >> >> ==
>> >> >>  Introduction
>> >> >> ==
>> >> >>
>> >> >> The purpose of this RFC is to discuss the driver for a TV output 
>> >> >> interface
>> >> >> available in upcoming Samsung SoC. The HW is able to generate digital 
>> >> >> and
>> >> >> analog signals. Current version of the driver supports only digital 
>> >> >> output.
>> >> >>
>> >> >> Internally the driver uses videobuf2 framework, and CMA memory 
>> >> >> allocator.
>> >> > Not
>> >> >> all of them are merged by now, but I decided to post the sources to 
>> >> >> start
>> >> >> discussion driver's design.
>> >
>> >> >
>> >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope 
>> >> > to post
>> >> > an RFC by the end of this month. We also have a proposal for CEC 
>> >> > support in
>> >> > the pipeline.
>> >>
>> >> Any reason to not use the drm kms APIs for modesetting, display
>> >> configuration, and hotplug support?  We already have the
>> >> infrastructure in place for complex display configurations and
>> >> generating events for hotplug interrupts.  It would seem to make more
>> >> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>> >> API.  Things like CEC would be a natural fit since a lot of desktop
>> >> GPUs support hdmi audio/3d/etc. and are already using kms.
>> >>
>> >> Alex
>> >
>> > I'll toss one out: lack of API documentation for driver or application
>> > developers to use.
>> >
>> >
>> > When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to
>> > possibly get rid of reliance on the ivtv X video driver
>> > http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation
>> > was really sparse.
>> >
>> > DRM had the most documentation under Documentation/DocBook/drm.tmpl, but
>> > the userland API wasn't fleshed out.  GEM was talked about a bit in
>> > there as well, IIRC.
>> >
>> > TTM documentation was essentially non-existant.
>> >
>> > I can't find any KMS documentation either.
>> >
>> > I recall having to read much of the drm code, and having to look at the
>> > radeon driver, just to tease out what the DRM ioctls needed to do.
>> >
>> > Am I missing a Documentation source for the APIs?
>> >
>>
>> Documentation is somewhat sparse compared to some other APIs.  Mostly
>> inline kerneldoc comments in the core functions.  It would be nice to
>> improve things.   The modesetting API is very similar to the xrandr
>> API in the xserver.
>>
>> At the moment a device specific surface manager (Xorg ddx, or some
>> other userspace lib) is required to use kms due to device specific
>> requirements with respect to memory management and alignment for
>> acceleration.  The kms modesetting ioctls are common across all kms
>> drm drivers, but the memory management ioctls are device specific.
>> GEM itself is an Intel-specific memory manager, although radeon uses
>> similar ioctls.  TTM is used internally by radeon, nouveau, and svga
>> for managing memory gpu accessible memory pools.  Drivers are free to
>> use whatever memory manager they want; an existing one shared with a
>> v4l or platform driver, TTM, or something new.
>>   There is no generic
>> userspace kms driver/lib although Dave and others have done some work
>> to support that, but it's really hard to make a generic interface
>> flexible enough to handle all the strange acceleration requirements of
>> GPUs.
>
> All of the above unfortunately says to me that the KMS API has a fairly
> tightly coupled set of userspace components, because userspace
> applications need have details about the specif

Re: [PATCH 0/8] Port xf86-video-v4l driver to V4L2 version 2

[Alex Deucher]

On Fri, Feb 11, 2011 at 10:54 AM, Mauro Carvalho Chehab
 wrote:
> This is the second version of my backport patches. To avoid spending
> people's time on looking at lines that have only whitespace changes,
> I broke the patch I submitted two days ago into two patches:
> the first one with just the logical changes, and the second one with
> just CodingStyle (whitespace) fixes.

Mauro,  I don't think anyone has maintained or used the v4l module in
ages.  You could be the new maintainer :)
Or at least have commit rights.  Just follow the instructions here:
http://www.freedesktop.org/wiki/AccountRequests

Alex

>
> Reworking on a driver with whitespace and identation problems is hard,
> as it makes harder for people to work with the source code.
>
> So, the first two patches have basically the same content as the patch
> I submitted earlier[1].
>
> [1] http://lists.x.org/archives/xorg-devel/2011-February/019042.html
>
> The fix patch I submited for xserver is still needed[2], otherwise
> loading the v4l driver with a video driver that doesn't support overlay
> will cause a server crash.
>
> [2] http://lists.x.org/archives/xorg-devel/2011-February/019048.html
>
> The remaining patches on this series fix some bugs found on the tests
> I made with:
>        1) a Nvidia FX5200 and the nv driver, and a bttv Encore FM board;
>        2) a Nvidia 6600 and nouveau driver, and a Kworld SBTV-D board
>          (to test it on an environment where Xv overlay is not available).
> And by some tests made by Dmitry Butskoy with a bttv AVerMedia TVPhone98
> board, with a Radeon RV100, using an old version of the Radeon driver.
>
> As I said before, the intention now is to port it to work with textured
> video. Help is wanted to point us how to use a textured video from the
> v4l driver.
>
> To make easier for people to test and review, the same patches are also
> available on a git repository at:
>        http://git.linuxtv.org/mchehab/xf86-video-v4l.git
>
> PS.: I'm c/c just this  message to the media devel ML, for people there
>     to be aware of the changes. There's not much sense to submit the
>     remaining patches there.
>
> Mauro Carvalho Chehab (8):
>  Port xf86-video-v4l driver to V4L2
>  Coding style Cleanup
>  Use the fourcc header instead of redefining it inside the code
>  Fix Get/Set Port Attribute logic
>  Return BadMatch if a Port Attribute is not found
>  Provide a more consistent message if FBUF fails
>  Fix arguments for v4l_check_yuv
>  Fix standard video size detection
>
>  src/v4l.c       | 1549 ++---
>  src/videodev.h  |  254 
>  src/videodev2.h | 1929 
> +++
>  3 files changed, 2831 insertions(+), 901 deletions(-)
>  delete mode 100644 src/videodev.h
>  create mode 100644 src/videodev2.h
>
> ___
> xorg-de...@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Alex Deucher]

On Wed, Feb 9, 2011 at 2:43 PM, Hans Verkuil  wrote:
> On Wednesday, February 09, 2011 20:00:38 Matt Turner wrote:
>> On Wed, Feb 9, 2011 at 7:12 AM, Alex Deucher  wrote:
>> > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls  wrote:
>> >> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote:
>> >>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
>> >>> > Just two quick notes. I'll try to do a full review this weekend.
>> >>> >
>> >>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
>> >>> >> ==
>> >>> >>  Introduction
>> >>> >> ==
>> >>> >>
>> >>> >> The purpose of this RFC is to discuss the driver for a TV output 
>> >>> >> interface
>> >>> >> available in upcoming Samsung SoC. The HW is able to generate digital 
>> >>> >> and
>> >>> >> analog signals. Current version of the driver supports only digital 
>> >>> >> output.
>> >>> >>
>> >>> >> Internally the driver uses videobuf2 framework, and CMA memory 
>> >>> >> allocator.
>> >>> > Not
>> >>> >> all of them are merged by now, but I decided to post the sources to 
>> >>> >> start
>> >>> >> discussion driver's design.
>> >>
>> >>> >
>> >>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope 
>> >>> > to post
>> >>> > an RFC by the end of this month. We also have a proposal for CEC 
>> >>> > support in
>> >>> > the pipeline.
>> >>>
>> >>> Any reason to not use the drm kms APIs for modesetting, display
>> >>> configuration, and hotplug support?  We already have the
>> >>> infrastructure in place for complex display configurations and
>> >>> generating events for hotplug interrupts.  It would seem to make more
>> >>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>> >>> API.  Things like CEC would be a natural fit since a lot of desktop
>> >>> GPUs support hdmi audio/3d/etc. and are already using kms.
>> >>>
>> >>> Alex
>> >>
>> >> I'll toss one out: lack of API documentation for driver or application
>> >> developers to use.
>> >>
>> >>
>> >> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to
>> >> possibly get rid of reliance on the ivtv X video driver
>> >> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation
>> >> was really sparse.
>> >>
>> >> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but
>> >> the userland API wasn't fleshed out.  GEM was talked about a bit in
>> >> there as well, IIRC.
>> >>
>> >> TTM documentation was essentially non-existant.
>> >>
>> >> I can't find any KMS documentation either.
>> >>
>> >> I recall having to read much of the drm code, and having to look at the
>> >> radeon driver, just to tease out what the DRM ioctls needed to do.
>> >>
>> >> Am I missing a Documentation source for the APIs?
>>
>> Yes,
>>
>> My summer of code project's purpose was to create something of a
>> tutorial for writing a KMS driver. The code, split out into something
>> like 15 step-by-step patches, and accompanying documentation are
>> available from Google's website.
>>
>> http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz
>
> Nice!
>
> What I still don't understand is if and how this is controlled via userspace.
>
> Is there some documentation of the userspace API somewhere?

At the moment, it's only used by Xorg ddxes and the plymouth
bootsplash.  For details see:
http://cgit.freedesktop.org/plymouth/tree/src/plugins/renderers/drm
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/drmmode_display.c

>
>> My repository (doesn't include the documentation) is available here:
>> http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary
>>
>> There's a 'rebased' branch that contains API changes required for the
>> code to work with 2.6.37~.
>>
>> I hope it's useful to you.
>

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Alex Deucher]

On Wed, Feb 9, 2011 at 3:59 AM, Hans Verkuil  wrote:
> On Tuesday, February 08, 2011 16:28:32 Alex Deucher wrote:
>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
>
> 
>
>> >>   The driver supports an interrupt. It is used to detect plug/unplug
> events
>> > in
>> >> kernel debugs.  The API for detection of such an events in V4L2 API is to
> be
>> >> defined.
>> >
>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to
> post
>> > an RFC by the end of this month. We also have a proposal for CEC support
> in
>> > the pipeline.
>>
>> Any reason to not use the drm kms APIs for modesetting, display
>> configuration, and hotplug support?  We already have the
>> infrastructure in place for complex display configurations and
>> generating events for hotplug interrupts.  It would seem to make more
>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>> API.  Things like CEC would be a natural fit since a lot of desktop
>> GPUs support hdmi audio/3d/etc. and are already using kms.
>
> There are various reasons for not going down that road. The most important one
> is that mixing APIs is actually a bad idea. I've done that once in the past
> and I've regretted ever since. The problem with doing that is that it is
> pretty hard on applications who have to mix two different styles of API,
> somehow know where to find the documentation for each and know that both APIs
> can in fact be used on the same device.
>
> Now, if there was a lot of code that could be shared, then that might be
> enough reason to go that way, but in practice there is very little overlap.
> Take CEC: all the V4L API will do is to pass the CEC packets from kernel to
> userspace and vice versa. There is no parsing at all. This is typically used
> by embedded apps that want to do their own CEC processing.
>
> An exception might be a PCI(e) card with HDMI input/output that wants to
> handle CEC internally. At that point we might look at sharing CEC parsing
> code. A similar story is true for EDID handling.
>
> One area that might be nice to look at would be to share drivers for HDMI
> receivers and transmitters. However, the infrastructure for such drivers is
> wildly different between how it is used for GPUs versus V4L and has been for
> 10 years or so. I also suspect that most GPUs have there own HDMI internal
> implementation so code sharing will probably be quite limited.
>

You don't need to worry about the rest of the 3D and acceleration
stuff to use the kms modesetting API.  For video output, you have a
timing generator, an encoder that translates a bitstream into
voltages, and an connector that you plug into a monitor.  Additionally
you may want to read an edid or generate a hotplug event and use some
modeline handling helpers.  The kms api provides core modesetting code
and a set of modesetting driver callbacks for crtcs, encoders, and
connectors.  The hardware implementations will vary, but modesetting
is the same.  From drm_crtc_helper.h:

The driver provides the following callbacks for the crtc.  The crtc
loosely refers to the part of the display pipe that generates timing
and framebuffer scanout position.

struct drm_crtc_helper_funcs {
/*
 * Control power levels on the CRTC.  If the mode passed in is
 * unsupported, the provider must use the next lowest power
level.
 */
void (*dpms)(struct drm_crtc *crtc, int mode);
void (*prepare)(struct drm_crtc *crtc);
void (*commit)(struct drm_crtc *crtc);

/* Provider can fixup or change mode timings before modeset occurs */
bool (*mode_fixup)(struct drm_crtc *crtc,
   struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode);
/* Actually set the mode */
int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode, int x, int y,
struct drm_framebuffer *old_fb);

/* Move the crtc on the current fb to the given position *optional* */
int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
 struct drm_framebuffer *old_fb);
int (*mode_set_base_atomic)(struct drm_crtc *crtc,
struct drm_framebuffer *fb, int x, int y,
enum mode_set_atomic);

/* reload the current crtc LUT */
void (*load_lut)(struct drm_crtc *crtc);

/* disable crtc when not in use - more explicit than dpms off */
void (*disable)(struct drm_crtc *crtc);
};

encoders take the bitstream from the crtc and convert it into a set of
voltages unde

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Alex Deucher]

On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls  wrote:
> On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote:
>> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
>> > Just two quick notes. I'll try to do a full review this weekend.
>> >
>> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
>> >> ==
>> >>  Introduction
>> >> ==
>> >>
>> >> The purpose of this RFC is to discuss the driver for a TV output interface
>> >> available in upcoming Samsung SoC. The HW is able to generate digital and
>> >> analog signals. Current version of the driver supports only digital 
>> >> output.
>> >>
>> >> Internally the driver uses videobuf2 framework, and CMA memory allocator.
>> > Not
>> >> all of them are merged by now, but I decided to post the sources to start
>> >> discussion driver's design.
>
>> >
>> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to 
>> > post
>> > an RFC by the end of this month. We also have a proposal for CEC support in
>> > the pipeline.
>>
>> Any reason to not use the drm kms APIs for modesetting, display
>> configuration, and hotplug support?  We already have the
>> infrastructure in place for complex display configurations and
>> generating events for hotplug interrupts.  It would seem to make more
>> sense to me to fix any deficiencies in the KMS APIs than to spin a new
>> API.  Things like CEC would be a natural fit since a lot of desktop
>> GPUs support hdmi audio/3d/etc. and are already using kms.
>>
>> Alex
>
> I'll toss one out: lack of API documentation for driver or application
> developers to use.
>
>
> When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to
> possibly get rid of reliance on the ivtv X video driver
> http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation
> was really sparse.
>
> DRM had the most documentation under Documentation/DocBook/drm.tmpl, but
> the userland API wasn't fleshed out.  GEM was talked about a bit in
> there as well, IIRC.
>
> TTM documentation was essentially non-existant.
>
> I can't find any KMS documentation either.
>
> I recall having to read much of the drm code, and having to look at the
> radeon driver, just to tease out what the DRM ioctls needed to do.
>
> Am I missing a Documentation source for the APIs?
>

Documentation is somewhat sparse compared to some other APIs.  Mostly
inline kerneldoc comments in the core functions.  It would be nice to
improve things.   The modesetting API is very similar to the xrandr
API in the xserver.

At the moment a device specific surface manager (Xorg ddx, or some
other userspace lib) is required to use kms due to device specific
requirements with respect to memory management and alignment for
acceleration.  The kms modesetting ioctls are common across all kms
drm drivers, but the memory management ioctls are device specific.
GEM itself is an Intel-specific memory manager, although radeon uses
similar ioctls.  TTM is used internally by radeon, nouveau, and svga
for managing memory gpu accessible memory pools.  Drivers are free to
use whatever memory manager they want; an existing one shared with a
v4l or platform driver, TTM, or something new.  There is no generic
userspace kms driver/lib although Dave and others have done some work
to support that, but it's really hard to make a generic interface
flexible enough to handle all the strange acceleration requirements of
GPUs.  kms does however provide a legacy kernel fb interface.

While the documentation is not great, the modesetting API is solid and
it would be nice to get more people involved and working on it (or at
least looking at it) rather than starting something equivalent from
scratch or implementing a device specific modesetting API.  If you
have any questions about it, please ask on dri-devel (CCed).

Alex

>
>
> For V4L2 and DVB on ther other hand, one can point to pretty verbose
> documentation that application developers can use:
>
>        http://linuxtv.org/downloads/v4l-dvb-apis/
>
>
>
> Regards,
> Andy
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

[Alex Deucher]

On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil  wrote:
> Just two quick notes. I'll try to do a full review this weekend.
>
> On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote:
>> ==
>>  Introduction
>> ==
>>
>> The purpose of this RFC is to discuss the driver for a TV output interface
>> available in upcoming Samsung SoC. The HW is able to generate digital and
>> analog signals. Current version of the driver supports only digital output.
>>
>> Internally the driver uses videobuf2 framework, and CMA memory allocator.
> Not
>> all of them are merged by now, but I decided to post the sources to start
>> discussion driver's design.
>>
>> ==
>>  Hardware description
>> ==
>>
>> The SoC contains a few HW sub-blocks:
>>
>> 1. Video Processor (VP). It is used for processing of NV12 data.  An image
>> stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally,
>> post processing operations like brightness, sharpness and contrast
> adjustments
>> could be performed. The output in YCbCr444 format is send to Mixer.
>>
>> 2. Mixer (MXR). The piece of hardware responsible for mixing and blending
>> multiple data inputs before passing it to an output device.  The MXR is
> capable
>> of handling up to three image layers. One is the output of VP.  Other two
> are
>> images in RGB format (multiple variants are supported).  The layers are
> scaled,
>> cropped and blended with background color.  The blending factor, and layers'
>> priority are controlled by MXR's registers. The output is passed either to
> HDMI
>> or TVOUT.
>>
>> 3. HDMI. The piece of HW responsible for generation of HDMI packets. It
> takes
>> pixel data from mixer and transforms it into data frames. The output is send
>> to HDMIPHY interface.
>>
>> 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets
> to
>> HDMI connector. Basically, it contains a PLL that produces source clock for
>> Mixer, VP and HDMI during streaming.
>>
>> 5. TVOUT. Generation of TV analog signal. (driver not implemented)
>>
>> 6. VideoDAC. Modulator for TVOUT signal. (driver not implemented)
>>
>>
>> The diagram below depicts connection between all HW pieces.
>>                     +---+
>> NV12 data ---dma--->|   Video   |
>>                     | Processor |
>>                     +---+
>>                           |
>>                           V
>>                     +---+
>> RGB data  ---dma--->|           |
>>                     |   Mixer   |
>> RGB data  ---dma--->|           |
>>                     +---+
>>                           |
>>                           * dmux
>>                          /
>>                   +-*   *--+
>>                   |                |
>>                   V                V
>>             +---+    +---+
>>             |    HDMI   |    |   TVOUT   |
>>             +---+    +---+
>>                   |                |
>>                   V                V
>>             +---+    +---+
>>             |  HDMIPHY  |    |  VideoDAC |
>>             +---+    +---+
>>                   |                |
>>                   V                V
>>                 HDMI           Composite
>>              connector         connector
>>
>>
>> ==
>>  Driver interface
>> ==
>>
>> The posted driver implements three V4L2 nodes. Every video node implements
> V4L2
>> output buffer. One of nodes corresponds to input of Video Processor. The
> other
>> two nodes correspond to RGB inputs of Mixer. All nodes share the same
> output.
>> It is one of the Mixer's outputs: TVOUT or HDMI. Changing output in one
> layer
>> using S_OUTPUT would change outputs of all other video nodes. The same thing
>> happens if one try to reconfigure output i.e. by calling S_DV_PRESET.
> However
>> it not possible to change or reconfigure the output while streaming. To sum
> up,
>> all features in posted version of driver goes as follows:
>>
>> 1. QUERYCAP
>> 2. S_FMT, G_FMT - single and multiplanar API
>>   a) node named video0 supports formats NV12, NV12, NV12T (tiled version of
>> NV12), NV12MT (multiplane version of NV12T).
>>   b) nodes named graph0 and graph1 support formats RGB565, ARGB1555,
> ARGB,
>> ARGB.
>
> graph0? Do you perhaps mean fb0? I haven't heard about nodes names 'graph'
> before.
>
>> 3. Buffer with USERPTR and MMAP memory.
>> 4. Streaming and buffer control. (STREAMON, STREAMOFF, REQBUF, QBUF, DQBUF)
>> 5. OUTPUT enumeration.
>> 6. DV preset control (SET, GET, ENUM). Currently modes 480P59_94, 720P59_94,
>> 1080P30, 1080P59_94 and 1080P60 work.
>> 7. Positioning layer's window on output display using S_CROP, G_GROP,
> CROPCAP.
>> 8. Positioning and cropping data in buffer using S_CROP, G_GROP, CROPCAP
> with
>> buffer type OVERLAY. *
>>
>> TODOs:
>> - add analog TVOUT driver
>> - add S_OUTPUT
>> - a

Re: [PATCH v10 8/8] davinci vpbe: Readme text for Dm6446 vpbe

[Alex Deucher]

On Thu, Dec 23, 2010 at 6:55 AM, Manjunath Hadli  wrote:
> Please refer to this file for detailed documentation of
> davinci vpbe v4l2 driver
>
> Signed-off-by: Manjunath Hadli 
> Acked-by: Muralidharan Karicheri 
> Acked-by: Hans Verkuil 
> ---
>  Documentation/video4linux/README.davinci-vpbe |   93 
> +
>  1 files changed, 93 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/video4linux/README.davinci-vpbe
>
> diff --git a/Documentation/video4linux/README.davinci-vpbe 
> b/Documentation/video4linux/README.davinci-vpbe
> new file mode 100644
> index 000..7a460b0
> --- /dev/null
> +++ b/Documentation/video4linux/README.davinci-vpbe
> @@ -0,0 +1,93 @@
> +
> +                VPBE V4L2 driver design
> + ==
> +
> + File partitioning
> + -
> + V4L2 display device driver
> +         drivers/media/video/davinci/vpbe_display.c
> +         drivers/media/video/davinci/vpbe_display.h
> +
> + VPBE display controller
> +         drivers/media/video/davinci/vpbe.c
> +         drivers/media/video/davinci/vpbe.h
> +
> + VPBE venc sub device driver
> +         drivers/media/video/davinci/vpbe_venc.c
> +         drivers/media/video/davinci/vpbe_venc.h
> +         drivers/media/video/davinci/vpbe_venc_regs.h
> +
> + VPBE osd driver
> +         drivers/media/video/davinci/vpbe_osd.c
> +         drivers/media/video/davinci/vpbe_osd.h
> +         drivers/media/video/davinci/vpbe_osd_regs.h
> +
> + Functional partitioning
> + ---
> +
> + Consists of the following (in the same order as the list under file
> + partitioning):-
> +
> + 1. V4L2 display driver
> +    Implements creation of video2 and video3 device nodes and
> +    provides v4l2 device interface to manage VID0 and VID1 layers.
> +
> + 2. Display controller
> +    Loads up VENC, OSD and external encoders such as ths8200. It provides
> +    a set of API calls to V4L2 drivers to set the output/standards
> +    in the VENC or external sub devices. It also provides
> +    a device object to access the services from OSD subdevice
> +    using sub device ops. The connection of external encoders to VENC LCD
> +    controller port is done at init time based on default output and standard
> +    selection or at run time when application change the output through
> +    V4L2 IOCTLs.
> +
> +    When connected to an external encoder, vpbe controller is also 
> responsible
> +    for setting up the interface between VENC and external encoders based on
> +    board specific settings (specified in board-xxx-evm.c). This allows
> +    interfacing external encoders such as ths8200. The setup_if_config()
> +    is implemented for this as well as configure_venc() (part of the next 
> patch)
> +    API to set timings in VENC for a specific display resolution. As of this
> +    patch series, the interconnection and enabling and setting of the 
> external
> +    encoders is not present, and would be a part of the next patch series.
> +
> + 3. VENC subdevice module
> +    Responsible for setting outputs provided through internal DACs and also
> +    setting timings at LCD controller port when external encoders are 
> connected
> +    at the port or LCD panel timings required. When external encoder/LCD 
> panel
> +    is connected, the timings for a specific standard/preset is retrieved 
> from
> +    the board specific table and the values are used to set the timings in
> +    venc using non-standard timing mode.
> +
> +    Support LCD Panel displays using the VENC. For example to support a Logic
> +    PD display, it requires setting up the LCD controller port with a set of
> +    timings for the resolution supported and setting the dot clock. So we 
> could
> +    add the available outputs as a board specific entry (i.e add the 
> "LogicPD"
> +    output name to board-xxx-evm.c). A table of timings for various LCDs
> +    supported can be maintained in the board specific setup file to support
> +    various LCD displays.As of this patch a basic driver is present, and this
> +    support for external encoders and displays forms a part of the next
> +    patch series.
> +

For 2. and 3., any plans to eventually migrate to a KMS interface?  It
seems like a lot of device specific controls here.

Alex


> + 4. OSD module
> +    OSD module implements all OSD layer management and hardware specific
> +    features. The VPBE module interacts with the OSD for enabling and
> +    disabling appropriate features of the OSD.
> +
> + Current status:-
> +
> + A fully functional working version of the V4L2 driver is available. This
> + driver has been tested with NTSC and PAL standards and buffer streaming.
> +
> + Following are TBDs.
> +
> + vpbe display controller
> +    - Add support for external encoders.
> +    - add support for selecting external encoder as default at probe time.
> +
> + vpbe venc sub device
> +    - add timings for supporting ths8200
> + 

Re: problems with using the -rc kernel in the git tree

[Alex Deucher]

On Mon, Dec 20, 2010 at 1:54 PM, Theodore Kilgore
 wrote:
>
>
> On Mon, 20 Dec 2010, Alex Deucher wrote:
>
>> On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore
>>  wrote:
>> >
>> > Hans,
>> >
>> > Thanks for the helpful advice about how to set up a git tree for current
>> > development so that I can get back into things.
>> >
>> > However, there is a problem with that -rc kernel, at least as far as my
>> > hardware is concerned. So if I am supposed to use it to work on camera
>> > stuff there is an obstacle.
>> >
>> > I started by copying my .config file over to the tree, and then running
>> > make oldconfig (as you said and as I would have done anyway).
>> >
>> > The problem seems to be centered right here (couple of lines
>> > from .config follow)
>> >
>> > CONFIG_DRM_RADEON=m
>> > # CONFIG_DRM_RADEON_KMS is not set
>> >
>> > I have a Radeon video card, obviously. Specifically, it is (extract from X
>> > config file follows)
>> >
>> > # Device configured by xorgconfig:
>> >
>> > Section "Device"
>> >    Identifier  "ATI Radeon HD 3200"
>> >    Driver      "radeon"
>> >
>> > Now, what happens is that with the kernel configuration (see above) I
>> > cannot start X in the -rc kernel. I get bumped out with an error
>> > message (details below) whereas that _was_ my previous configuration
>> > setting.
>> >
>> > But if in the config for the -rc kernel I change the second line by
>> > turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the
>> > video cuts off during the boot process, with the monitor going blank and
>> > flashing up a message that it lost signal. After that the only thing to do
>> > is a hard reset, which strangely does not result in any check for a dirty
>> > file system, showing that things _really_ got screwed. These problems wit
>> > the video cutting off at boot are with booting into the _terminal_, BTW. I
>> > do not and never have made a practice of booting into X. I start X from
>> > the command line after boot. Thus, the video cutting off during boot has
>> > nothing to do with X at all, AFAICT.
>> >
>> > So as I said there are two alternatives, both of them quite unpleasant.
>> >
>> > Here is what the crash message is on the screen from the attempt to start
>> > up X, followed by what seem to be the relevant lines from the log file,
>> > with slightly more detail.
>> >
>> > Markers: (--) probed, (**) from config file, (==) default setting,
>> >        (++) from command line, (!!) notice, (II) informational,
>> >        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010
>> > (==) Using config file: "/etc/X11/xorg.conf"
>> > (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>> > (II) [KMS] drm report modesetting isn't supported.
>> > (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22)
>> > (EE) RADEON(0): Memory map the MMIO region failed
>> > (EE) Screen(s) found, but none have a usable configuration.
>> >
>> > Fatal server error:
>> > no screens found
>> >
>> > Please consult the The X.Org Foundation support
>> >         at http://wiki.x.org
>> >  for help.
>> > Please also check the log file at "/var/log/Xorg.0.log" for additional
>> > information.
>> >
>> > xinit: giving up
>> > xinit: unable to connect to X server: Connection refused
>> > xinit: server error
>> > xinit: unable to connect to X server: Connection refused
>> > xinit: server error
>> > kilg...@khayyam:~$
>> >
>> > And the following, too, from the log file, which perhaps contains one or
>> > two
>> > more details:
>> >
>> > [    48.050] (--) using VT number 7
>> >
>> > [    48.052] (II) [KMS] drm report modesetting isn't supported.
>> > [    48.052] (II) RADEON(0): TOTO SAYS feaf
>> > [    48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size
>> > 64KB
>> > [    48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument
>> > (22)
>> > [    48.052] (EE) RADEON(0): Memory map the MMIO region failed
>> > [    48.052] (II) UnloadModule: "radeon&

Re: problems with using the -rc kernel in the git tree

[Alex Deucher]

On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore
 wrote:
>
> Hans,
>
> Thanks for the helpful advice about how to set up a git tree for current
> development so that I can get back into things.
>
> However, there is a problem with that -rc kernel, at least as far as my
> hardware is concerned. So if I am supposed to use it to work on camera
> stuff there is an obstacle.
>
> I started by copying my .config file over to the tree, and then running
> make oldconfig (as you said and as I would have done anyway).
>
> The problem seems to be centered right here (couple of lines
> from .config follow)
>
> CONFIG_DRM_RADEON=m
> # CONFIG_DRM_RADEON_KMS is not set
>
> I have a Radeon video card, obviously. Specifically, it is (extract from X
> config file follows)
>
> # Device configured by xorgconfig:
>
> Section "Device"
>    Identifier  "ATI Radeon HD 3200"
>    Driver      "radeon"
>
> Now, what happens is that with the kernel configuration (see above) I
> cannot start X in the -rc kernel. I get bumped out with an error
> message (details below) whereas that _was_ my previous configuration
> setting.
>
> But if in the config for the -rc kernel I change the second line by
> turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the
> video cuts off during the boot process, with the monitor going blank and
> flashing up a message that it lost signal. After that the only thing to do
> is a hard reset, which strangely does not result in any check for a dirty
> file system, showing that things _really_ got screwed. These problems wit
> the video cutting off at boot are with booting into the _terminal_, BTW. I
> do not and never have made a practice of booting into X. I start X from
> the command line after boot. Thus, the video cutting off during boot has
> nothing to do with X at all, AFAICT.
>
> So as I said there are two alternatives, both of them quite unpleasant.
>
> Here is what the crash message is on the screen from the attempt to start
> up X, followed by what seem to be the relevant lines from the log file,
> with slightly more detail.
>
> Markers: (--) probed, (**) from config file, (==) default setting,
>        (++) from command line, (!!) notice, (II) informational,
>        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 19 14:32:12 2010
> (==) Using config file: "/etc/X11/xorg.conf"
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (II) [KMS] drm report modesetting isn't supported.
> (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22)
> (EE) RADEON(0): Memory map the MMIO region failed
> (EE) Screen(s) found, but none have a usable configuration.
>
> Fatal server error:
> no screens found
>
> Please consult the The X.Org Foundation support
>         at http://wiki.x.org
>  for help.
> Please also check the log file at "/var/log/Xorg.0.log" for additional
> information.
>
> xinit: giving up
> xinit: unable to connect to X server: Connection refused
> xinit: server error
> xinit: unable to connect to X server: Connection refused
> xinit: server error
> kilg...@khayyam:~$
>
> And the following, too, from the log file, which perhaps contains one or
> two
> more details:
>
> [    48.050] (--) using VT number 7
>
> [    48.052] (II) [KMS] drm report modesetting isn't supported.
> [    48.052] (II) RADEON(0): TOTO SAYS feaf
> [    48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size
> 64KB
> [    48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument
> (22)
> [    48.052] (EE) RADEON(0): Memory map the MMIO region failed
> [    48.052] (II) UnloadModule: "radeon"
> [    48.052] (EE) Screen(s) found, but none have a usable configuration.
> [    48.052]
> Fatal server error:
> [    48.052] no screens found
> [    48.052]
>
> There are a couple of suggestions about things to try, such as compiling
> with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the
> radeon module. But that does not seem to help, either.
>
> The help screens in make menuconfig do not seem to praise the
> CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still
> a very experimental feature.
>
> There are no such equivalent problems with my current kernel, which is a
> home-compiled 2.6.35.7.
>
> I realize that this is a done decision, but it is exactly this kind of
> thing that I had in mind when we had the Great Debate on the linux-media
> list about whether to use hg or git. My position was to let hardware
> support people to run hg with the compatibility layer for recent kernels
> (and 2.6.35.7 is certainly recent!). Well, the people who had such a
> position did not win. So now here is unfortunately the foreseeable result.
> An experimental kernel with some totally unrelated bug which affects my
> hardware and meanwhile stops all progress.

If you enable radeon KMS, you need to enable fbcon in your kernel or
you will lose video when the radeon 

Re: rtl2832u support

[Alex Deucher]

On Mon, Dec 6, 2010 at 4:29 PM, Jan Hoogenraad
 wrote:
> I haven't seen any data sheets. At the other hand, Antti was able to create
> a separated (tuner vs demod) driver, except for IR.
>
> http://linuxtv.org/hg/~anttip/rtl2831u/
>
> http://linuxtv.org/hg/~anttip/qt1010/
>
> I haven't seen a data sheet, but I doubt if it would be of more use than
> using this example code.
> My mail contacts (latest in may 2008) focused on getting the code to work
> and on signing off the code.
>
> I'll give my mail contact a try, especially if you have questions that
> cannot be found in the current code base.

FWIW, in my experience, working code is preferable to datasheets if
you have to pick.  Often times datasheets are produced pre-silicon and
aren't always updated properly with the final changes.

Alex

>
> Maxim Levitsky wrote:
>>
>> On Mon, 2010-12-06 at 16:45 +0100, Jan Hoogenraad wrote:
>>>
>>> Could the tree from
>>>
>>> http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2
>>>
>>> which is really just an older version of the same code, go into staging
>>> than as well ?
>>
>> Yes, but the problem is that due to shaddy license status of the
>> 'windows' driver, I am afraid to look seriously at it.
>> Up till now, I only experimented with IR code.
>>
>> Jan, since you have contacts with Realtek, maybe it would be possible to
>> get datasheet for their hardware?
>>
>> And the above code is guaraneed not to work on my card because even
>> their 'windows' driver v1.4 doesn't work here.
>> Only 2.0 driver works.
>>
>> And you said that you couldn't seperate demod from bridge?
>> Is that nessesary?
>> I have seen few drivers that don't separate it in v4l source.
>>
>> Tuners are of course another story.
>>
>> Best regards,
>>        Maxim Levitsky
>>
>>
>>>
>>> For that one, I have the signoff by RealTek already.
>>>
>>> Mauro Carvalho Chehab wrote:

 Em 20-11-2010 20:37, Maxim Levitsky escreveu:

>>> Do we have a common agreement that this driver can go to staging
>>> as-is?
>>>
>>> If yes, I have patch ready, just need to know where to send it (It is
>>> around 1 MB).

 Yes, if people is interested on later fixing the issues. As Antti said
 he already broke the driver into more consistent parts, maybe his tree
 may be an start.

>
> I would like to volunteer to clean up the driver for eventual merge.
> At least I can start right away with low handing fruit.

 Ok, Seems fine for me.

> I have took the driver from
>
>
> http://www.turnovfree.net/~stybla/linux/v4l-dvb/lv5tdlx/20101102_RTL2832_2836_2840_LINUX+RC-Dongle.rar
>
>
> And it looks very recent, so that means that Realtek actually continues
> to develop it.

 The better would be to try to sync with Realtek to be sure that they'll
 continue to develop the upstream driver, after having it merged.
 Otherwise,
 someone will need to do the manual sync, and this can be very painful.

> Greg KH, maybe you know how to contact Realteck to figure out the best
> strategy in handling this code.
>
> Meanwhile, lets put that into staging.
> (The above driver doesn't compile due to changes in RC code, but it can
> be removed (that what I did for now) or ported to new rc-core which
> what
> I will do very soon).

 Just send the patches. The better is to submit them via linux-media, and
 say, at
 a TODO file, that patches for it should be submitted to
 linux-me...@vger.kernel.org.
 Something similar to drivers/staging/tm6000/TODO.

 Cheers,
 Mauro
 --
 To unsubscribe from this list: send the line "unsubscribe linux-media"
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

>>>
>>>
>>
>>
>
>
> --
> Jan Hoogenraad
> Hoogenraad Interface Services
> Postbus 2717
> 3500 GS Utrecht
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/10] MCDE: Add build files and bus

[Alex Deucher]

;> device in question. All calls DSS only related to overlays, like
>> buffer pointers, position, rotation etc is handled directly by DSS
>> calling mcde_hw.
>>
>> You could see mcde_hw as a physical level driver and mcde_dss closer
>> to a logical driver, delegating display specific decisions to the
>> display driver. Another analogy is mcde_hw is host driver and display
>> drivers are client device drivers. And DSS is a collection of logic
>> to manage the interaction between host and client devices.
>
> The way you describe it, I would picture it differently:
>
> +--+ ++-+-+ +---+
> | mcde_hw  | | fb | kms | v4l | | displ |
> ++--+
> | HW |            mcde_dss              |
> ++--+
>
> In this model, the dss is the core module that everything else
> links to. The hw driver talks to the actual hardware and to the
> dss. The three front-ends only talk to the dss, but not to the
> individual display drivers or to the hw code directly (i.e. they
> don't use their exported symbols or internal data structures.
> The display drivers only talk to the dss, but not to the front-ends
> or the hw drivers.
>
> Would this be a correct representation of your modules?
>
>> > Having the kms/fb/v4l2 drivers on top definitely makes sense, so
>> > these should all be able to be standalone loadable modules.
>> > I do not understand why you have a v4l2 driver at all, or why
>> > you need both fb and kms drivers, but that is probably because
>> > of my ignorance of display device drivers.
>>
>> All APIs have to be provided, these are user space API requirements.
>> KMS has a generic FB implementation. But most of KMS is modeled by
>> desktop/PC graphics cards. And while we might squeeze MCDE in to look
>> like a PC card, it might also just make things more complex and
>> restrict us to do things not possible in PC architecture.
>
> Ok, so you have identified a flaw with the existing KMS code. You should
> most certainly not try to make your driver fit into the flawed model by
> making it look like a PC. Instead, you are encouraged to fix the problems
> with KMS to make sure it can also meet your requirements. The reason
> why it doesn't do that today is that all the existing users are PC
> hardware and we don't build infrastructure that we expect to be used
> in the future but don't need yet. It would be incorrect anyway.
>
> Can you describe the shortcomings of the KSM code? I've added the dri-devel
> list to Cc, to get the attention of the right people.

This doesn't seem that different from the graphics chips we support
with kms.  I don't think it would require much work to use KMS.  One
thing we considered, but never ended up implementing was a generic
overlay API for KMS.  Most PC hardware still has overlays, but we
don't use them much any more on the desktop side.  It may be
worthwhile to design an appropriate API for them for these type of
hardware.

To elaborate on the current KMS design, we have:
crtcs - the display controller.  these map to the timing generators
and scanout hardware
encoders - the hw that takes the bitstream from the display controller
and converts it to the appropriate format for the connected display.
connector - the physical interface that a display attaches to (VGA,
LVDS, eDP, HDMI-A, etc.)

Modern PC hardware is pretty complex.  I've blogged about some of the
recent radeon display hardware:
http://www.botchco.com/agd5f/?p=51
Moreover, each oem designs different boards with vastly different
display configurations.  It gets more complex with things like
advanced color management and DP (DisplayPort) 1.2 that introduces
things like daisy-chaining monitors and tunnelling USB and audio over
DP.


>
>> Alex Deucher noted in a previous post that we also have the option of
>> implementing the KMS ioctls. We are looking at both options. And having
>> our own framebuffer driver might make sense since it is a very basic
>> driver, and it will allow us to easily extend support for things like
>> partial updates for display panels with on board memory. These panels
>> with memory (like DSI command mode displays) is one of the reasons why
>> KMS is not the perfect match. Since we want to expose features available
>> for these types of displays.
>
> Ok.
>
>> > > > From what I understood so far, you have a single multi-channel
>> > display
>> > > > controller (mcde_hw.c) that drives the hardware.
>> > > > Each controller can have multiple frame buffers attached to it,
>> > which
>> > > > in turn can have multiple disp

Re: [PATCH 00/10] MCDE: Add frame buffer device driver

[Alex Deucher]

On Fri, Nov 12, 2010 at 11:46 AM, Marcus LORENTZON
 wrote:
> Hi Alex,
> Do you have any idea of how we should use KMS without being a "real" drm 3D 
> device? Do you mean that we should use the KMS ioctls on for display driver? 
> Or do you mean that we should expose a /dev/drmX device only capable of KMS 
> and no GEM?
>

In this case I was only speaking of using the kms icotls and fbdev
emulation for modesetting as your device seems to have a fairly
complex display engine.  As for 2D/3D/video accel, that's up to you.
Each drm driver does it differently depending on how they handle
command buffers.  Intel and AMD have different sets of ioctls for
submitting 2D/3D/video commands from userspace acceleration drivers
and a different set of ioctls for memory management.

> What if we were to add a drm driver for 3D later on. Is it possible to have a 
> separate drm device for display and one for 3D, but still share "GEM" like 
> buffers between these devices? It look like GEM handles are device relative. 
> This is a vital use case for us. And we really don't like to entangle our 
> MCDE display driver, memory manager and 3D driver without a good reason. 
> Today they are maintained as independent drivers without code dependencies. 
> Would this still be possible using drm? Or does drm require memory manager, 
> 3D and display to be one driver? I can see the drm=graphics card on desktop 
> machines. But embedded UMA systems doesn't really have this dependency. You 
> can switch memory mamanger, 3D driver, display manager in menuconfig 
> independently of the other drivers. Not that it's used like that on one 
> particular HW, but for different HW you can use different parts. In drm it 
> looks like all these pieces belong together.
>

No one has done anything like that, but I don't think it would be an
issue, you'd just need some sort of way to get buffers in your display
driver or your 3D driver, so I'd assume they would depend on your
memory manager.  Right now the userspace 2D/3D accel drivers all talk
to the drm independently depending on what they need to do.  Whatever
your userspace stack looks like could do something similar, call into
one set of ioctls for memory, another set for modesetting, and another
for accel.  As long as the kernel memory manager is common, you should
be able to pass buffer handles between all of them.  If you wanted
separate memory managers for each, things get a bit trickier, but
that's up to you.

> Do you think the driver should live in the "gpu/drm" folder, even though it's 
> not a gpu driver?
>

gpu is kind of a broad term.  It encompasses, 3D, display, video, etc.
 I don't think it really matters.

> Do you know of any other driver that use DRM/KMS API but not being a PC-style 
> graphics card that we could look at for inspiration?

Jordan Crouse submitted some patches for Qualcomm snapdragon a while
back although it was mostly a shim for a userspace accel driver.  He
did implement platform support in the drm however:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=dcdb167402cbdca1d021bdfa5f63995ee0a79317

>
> And GEM, is that the only way of exposing graphics buffers to user space in 
> drm? Or is it possible (is it ok) to expose another similar API? You 
> mentioned that there are TTM and GEM, do both expose user space APIs for 
> things like sharing buffers between processes, security, cache management, 
> defragmentation? Or are these type of features defined by DRM and not TTM/GEM?
>

GEM is not a requirement, it just happens that all the current drm
drivers use variants of it for their external memory management
interface.  However, they are free to implement the memory manager
however they like.

Alex

> /BR
> /Marcus
>
>> -Original Message-
>> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
>> Sent: den 12 november 2010 16:53
>> To: Jimmy RUBIN
>> Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON; Marcus
>> LORENTZON
>> Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver
>>
>> On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN
>>  wrote:
>> > Hi Alex,
>> >
>> > Good point, we are looking at this for possible future improvements
>> but for the moment we feel like
>> > the structure of drm does not add any simplifications for our driver.
>> We have the display manager (MCDE DSS = KMS) and the memory manager
>> (HWMEM = GEM) that could be migrated to drm framework. But we do not
>> have drm drivers for 3D hw and this also makes drm a less obvious
>> choice at the moment.
>> >
>>
>> You don't have to use t

Re: [PATCH 00/10] MCDE: Add frame buffer device driver

[Alex Deucher]

On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN  wrote:
> Hi Alex,
>
> Good point, we are looking at this for possible future improvements but for 
> the moment we feel like
> the structure of drm does not add any simplifications for our driver. We have 
> the display manager (MCDE DSS = KMS) and the memory manager (HWMEM = GEM) 
> that could be migrated to drm framework. But we do not have drm drivers for 
> 3D hw and this also makes drm a less obvious choice at the moment.
>

You don't have to use the drm strictly for 3D hardware.  historically
that's why it was written, but with kms, it also provides an interface
for complex display systems.  fbdev doesn't really deal properly with
multiple display controllers or connectors that are dynamically
re-routeable at runtime.  I've seen a lot of gross hacks to fbdev to
support this kind of stuff in the past, so it'd be nice to use the
interface we now have for it if you need that functionality.
Additionally, you can use the shared memory manager to both the
display side and v4l side.  While the current drm drivers use GEM
externally, there's no requirement that a kms driver has to use GEM.
radeon and nouveau use ttm internally for example.  Something to
consider.  I just want to make sure people are aware of the interface
and what it's capable of.

Alex

> Jimmy
>
> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: den 10 november 2010 15:43
> To: Jimmy RUBIN
> Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON
> Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver
>
> On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin  
> wrote:
>> These set of patches contains a display sub system framework (DSS) which is 
>> used to
>> implement the frame buffer device interface and a display device
>> framework that is used to add support for different type of displays
>> such as LCD, HDMI and so on.
>
> For complex display hardware, you may want to consider using the drm
> kms infrastructure rather than the kernel fb interface.  It provides
> an API for complex display hardware (multiple encoders, display
> controllers, etc.) and also provides a legacy kernel fb interface for
> compatibility.  See:
> Documentation/DocBook/drm.tmpl
> drivers/gpu/drm/
> in the kernel tree.
>
> Alex
>
>>
>> The current implementation supports DSI command mode displays.
>>
>> Below is a short summary of the files in this patchset:
>>
>> mcde_fb.c
>> Implements the frame buffer device driver.
>>
>> mcde_dss.c
>> Contains the implementation of the display sub system framework (DSS).
>> This API is used by the frame buffer device driver.
>>
>> mcde_display.c
>> Contains default implementations of the functions in the display driver
>> API. A display driver may override the necessary functions to function
>> properly. A simple display driver is implemented in display-generic_dsi.c.
>>
>> display-generic_dsi.c
>> Sample driver for a DSI command mode display.
>>
>> mcde_bus.c
>> Implementation of the display bus. A display device is probed when both
>> the display driver and display configuration have been registered with
>> the display bus.
>>
>> mcde_hw.c
>> Hardware abstraction layer of MCDE. All code that communicates directly
>> with the hardware resides in this file.
>>
>> board-mop500-mcde.c
>> The configuration of the display and the frame buffer device is handled
>> in this file
>>
>> NOTE: These set of patches replaces the patches already sent out for review.
>>
>> RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver
>> RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver
>>
>> The old patchset was to large to be handled by the mailing lists.
>>
>> Jimmy Rubin (10):
>>  MCDE: Add hardware abstraction layer
>>  MCDE: Add configuration registers
>>  MCDE: Add pixel processing registers
>>  MCDE: Add formatter registers
>>  MCDE: Add dsi link registers
>>  MCDE: Add generic display
>>  MCDE: Add display subsystem framework
>>  MCDE: Add frame buffer device driver
>>  MCDE: Add build files and bus
>>  ux500: MCDE: Add platform specific data
>>
>>  arch/arm/mach-ux500/Kconfig                    |    8 +
>>  arch/arm/mach-ux500/Makefile                   |    1 +
>>  arch/arm/mach-ux500/board-mop500-mcde.c        |  209 ++
>>  arch/arm/mach-ux500/board-mop500-regulators.c  |   28 +
>>  arch/arm/mach-ux500/board-mop500.c             |    3 +
>&

Re: [PATCH 00/10] MCDE: Add frame buffer device driver

[Alex Deucher]

On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin  wrote:
> These set of patches contains a display sub system framework (DSS) which is 
> used to
> implement the frame buffer device interface and a display device
> framework that is used to add support for different type of displays
> such as LCD, HDMI and so on.

For complex display hardware, you may want to consider using the drm
kms infrastructure rather than the kernel fb interface.  It provides
an API for complex display hardware (multiple encoders, display
controllers, etc.) and also provides a legacy kernel fb interface for
compatibility.  See:
Documentation/DocBook/drm.tmpl
drivers/gpu/drm/
in the kernel tree.

Alex

>
> The current implementation supports DSI command mode displays.
>
> Below is a short summary of the files in this patchset:
>
> mcde_fb.c
> Implements the frame buffer device driver.
>
> mcde_dss.c
> Contains the implementation of the display sub system framework (DSS).
> This API is used by the frame buffer device driver.
>
> mcde_display.c
> Contains default implementations of the functions in the display driver
> API. A display driver may override the necessary functions to function
> properly. A simple display driver is implemented in display-generic_dsi.c.
>
> display-generic_dsi.c
> Sample driver for a DSI command mode display.
>
> mcde_bus.c
> Implementation of the display bus. A display device is probed when both
> the display driver and display configuration have been registered with
> the display bus.
>
> mcde_hw.c
> Hardware abstraction layer of MCDE. All code that communicates directly
> with the hardware resides in this file.
>
> board-mop500-mcde.c
> The configuration of the display and the frame buffer device is handled
> in this file
>
> NOTE: These set of patches replaces the patches already sent out for review.
>
> RFC:[PATCH 1/2] Video: Add support for MCDE frame buffer driver
> RFC:[PATCH 2/2] Ux500: Add support for MCDE frame buffer driver
>
> The old patchset was to large to be handled by the mailing lists.
>
> Jimmy Rubin (10):
>  MCDE: Add hardware abstraction layer
>  MCDE: Add configuration registers
>  MCDE: Add pixel processing registers
>  MCDE: Add formatter registers
>  MCDE: Add dsi link registers
>  MCDE: Add generic display
>  MCDE: Add display subsystem framework
>  MCDE: Add frame buffer device driver
>  MCDE: Add build files and bus
>  ux500: MCDE: Add platform specific data
>
>  arch/arm/mach-ux500/Kconfig                    |    8 +
>  arch/arm/mach-ux500/Makefile                   |    1 +
>  arch/arm/mach-ux500/board-mop500-mcde.c        |  209 ++
>  arch/arm/mach-ux500/board-mop500-regulators.c  |   28 +
>  arch/arm/mach-ux500/board-mop500.c             |    3 +
>  arch/arm/mach-ux500/devices-db8500.c           |   68 +
>  arch/arm/mach-ux500/include/mach/db8500-regs.h |    7 +
>  arch/arm/mach-ux500/include/mach/devices.h     |    1 +
>  arch/arm/mach-ux500/include/mach/prcmu-regs.h  |    1 +
>  arch/arm/mach-ux500/include/mach/prcmu.h       |    3 +
>  arch/arm/mach-ux500/prcmu.c                    |  129 ++
>  drivers/video/Kconfig                          |    2 +
>  drivers/video/Makefile                         |    1 +
>  drivers/video/mcde/Kconfig                     |   39 +
>  drivers/video/mcde/Makefile                    |   12 +
>  drivers/video/mcde/display-generic_dsi.c       |  152 ++
>  drivers/video/mcde/dsi_link_config.h           | 1486 ++
>  drivers/video/mcde/mcde_bus.c                  |  259 +++
>  drivers/video/mcde/mcde_config.h               | 2156 
>  drivers/video/mcde/mcde_display.c              |  427 
>  drivers/video/mcde/mcde_dss.c                  |  353 
>  drivers/video/mcde/mcde_fb.c                   |  697 +++
>  drivers/video/mcde/mcde_formatter.h            |  782 
>  drivers/video/mcde/mcde_hw.c                   | 2528 
> 
>  drivers/video/mcde/mcde_mod.c                  |   67 +
>  drivers/video/mcde/mcde_pixelprocess.h         | 1137 +++
>  include/video/mcde/mcde.h                      |  387 
>  include/video/mcde/mcde_display-generic_dsi.h  |   34 +
>  include/video/mcde/mcde_display.h              |  139 ++
>  include/video/mcde/mcde_dss.h                  |   78 +
>  include/video/mcde/mcde_fb.h                   |   54 +
>  31 files changed, 11248 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-ux500/board-mop500-mcde.c
>  create mode 100644 drivers/video/mcde/Kconfig
>  create mode 100644 drivers/video/mcde/Makefile
>  create mode 100644 drivers/video/mcde/display-generic_dsi.c
>  create mode 100644 drivers/video/mcde/dsi_link_config.h
>  create mode 100644 drivers/video/mcde/mcde_bus.c
>  create mode 100644 drivers/video/mcde/mcde_config.h
>  create mode 100644 drivers/video/mcde/mcde_display.c
>  create mode 100644 drivers/video/mcde/mcde_dss.c
>  create mode 100644 drivers/video/mcde/mcde_fb.c
>  create mode 100644 drivers/video/mcde/m

Re: rtl2832u support

[Alex Deucher]

On Tue, Oct 19, 2010 at 4:27 PM, Hans Verkuil  wrote:
> On Tuesday, October 19, 2010 21:26:13 Devin Heitmueller wrote:
>> On Tue, Oct 19, 2010 at 1:42 PM, Damjan Marion  
>> wrote:
>> >
>> > Hi,
>> >
>> > Is there any special reason why driver for rtl2832u DVB-T receiver chipset 
>> > is not included into v4l-dvb?
>> >
>> > Realtek published source code under GPL:
>> >
>> > MODULE_AUTHOR("Realtek");
>> > MODULE_DESCRIPTION("Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 
>> > device");
>> > MODULE_VERSION("1.4.2");
>> > MODULE_LICENSE("GPL");
>>
>> Unfortunately, in most cases much more is "required" than having a
>> working driver under the GPL in order for it to be accepted upstream.
>> In some cases it can mean a developer spending a few hours cleaning up
>> whitespace and indentation, and in other cases it means significant
>> work to the driver is required.
>>
>> The position the LinuxTV team has taken is that they would rather have
>> no upstream driver at all than to have a driver which doesn't have the
>> right indentation or other aesthetic problems which has no bearing on
>> how well the driver actually works.
>>
>> This is one of the big reasons KernelLabs has tens of thousands of
>> lines of code adding support for a variety of devices with many happy
>> users (who are willing to go through the trouble to compile from
>> source), but the code cannot be accepted upstream.  I just cannot find
>> the time to do the "idiot work".
>
> Bullshit. First of all these rules are those of the kernel community
> as a whole and *not* linuxtv as such, and secondly you can upstream such
> drivers in the staging tree. If you want to move it out of staging, then
> it will take indeed more work since the quality requirements are higher
> there.
>
> Them's the rules for kernel development.
>
> I've done my share of coding style cleanups. I never understand why people
> dislike doing that. In my experience it always greatly improves the code
> (i.e. I can actually understand it) and it tends to highlight the remaining
> problematic areas in the driver.
>
> Of course, I can also rant for several paragraphs about companies throwing
> code over the wall without bothering to actually do the remaining work to
> get it mainlined. The very least they can do is to sponsor someone to do the
> work for them.

To start, I appreciate the kernel coding style requirements.  I think
it makes the code much easier to read and more consistent across the
kernel tree.  But, just to play devil's advocate, it's a fair amount
of work to write a driver especially if the hw is complex.  It's much
easier to share a common codebase between different OSs because to
reduces the maintenance burden and makes it easier to support new asic
variants.  This is especially true if you are a small company with
limited resources.  It annoys me somewhat when IHVs put in the effort
to actually produce a GPLed Linux driver and the community shits on
them for not writing it from scratch to match the kernel style
requirements.  Lets face it, there are a lot of hw specs out there
with no driver.  A working driver with source is vastly more useful.
It would be nice if every company out there had the resources to
develop a nice clean native Linux driver, but right now that's not
always the case.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Illuminators and status LED controls

[Alex Deucher]

On Wed, Sep 8, 2010 at 2:58 PM, Peter Korsgaard  wrote:
>> "Andy" == Andy Walls  writes:
>
> Hi,
>
>  Andy> Incandescent and Halogen lamps that effect an image coming into a
>  Andy> camera are *not* LEDs that blink or flash automatically based on
>  Andy> driver or system trigger events.  They are components of a video
>  Andy> capture system with which a human attempts to adjust the
>  Andy> appearance of an image of a subject by changing the subject's
>  Andy> environment.  These illuminators are not some generically
>  Andy> connected device, but controlled by GPIO's on the camera's bridge
>  Andy> or sensor chip itself.  Such an illuminator will essentially be
>  Andy> used only in conjunction with the camera.
>
> Agreed.
>
>  Andy> Status LEDs integrated into webcam devices that are not generically
>  Andy> connected devices but controlled with GPIOs on the camera's bridge or
>  Andy> sensor chip will also essentially be used only in conjunction with the
>  Andy> camera.
>
> Or for any other usage the user envision - E.G. I could imagine using
> the status led of the webcam in my macbook for hard disk or wifi
> activity. I'm sure other people can come up with more creative use cases
> as well.
>
>  Andy> Turning these sorts camera specific illuminators and LEDs on an off
>  Andy> should be as simple to implement for an application developer as it is
>  Andy> to grasp the concept of turning a light bulb on and off.
>
> The point is that the logic rarely needs to be in the v4l
> applications. The status LEDs should by default go on when the v4l
> device is active and go off again when not like it used to do. A v4l
> application developer would normally not want to worry about such
> things, and only care about the video data.
>
> But if a user wants something special / non-standard, then it's just a
> matter of changing LED trigger in /sys/class/leds/..

I agree with Peter here.  I don't see why a video app would care about
blinking an LED while capturing.  I suspect most apps won't bother to
implement it, or it will be a card specific mess (depending on what
the hw actually provides).  Shouldn't the driver just turn it on or
blink it when capturing is active or whatever.  Why should apps care?
Plus, each app may implement some different behavior or some may not
implement it at all which will further confuse users.

Alex

>
>  Andy> The LED interface seems more appropriate to use when the LEDs are
>  Andy> connected more generically and will likely be used more generically,
>  Andy> such as in an embedded system.
>
> The LED subsystem certainly has it uses in embedded, but it's also used
> on PCs - As an example the ath9k wireless driver exports a number of
> LEDs. I find the situation with the wlan LEDs pretty comparable to
> status LEDs on v4l devices.
>
>  >> And yes, application developers must use the correct API to control
>  >> stuff.
>
>  >> Why should kernel duplicate interfaces just because
>  >> user land don't want to use two different interfaces? Doesn't this sound 
> a bit ... strange at least?
>
>  Andy> Why should the kernel push multiple APIs on application developers to
>  Andy> control a complex federation of small devices all connected behind a
>  Andy> single bridge chip, which the user perceives as a single device?  (BTW 
> a
>  Andy> USB microscope is such a federation which doesn't work at all without
>  Andy> proper subject illumination.)
>
> Because that's the only sensible way to create a bunch of incompatible
> custom interfaces  - E.G. a microphone built into a webcam is handled
> through also, not v4l, so it works with any sound recording program.
>
>  Andy> V4L2 controls are how desktop V4L2 applications currently control
>  Andy> aspects of a incoming image.  Forcing the use of the LED interface in
>  Andy> sysfs to control one aspect of that would be a departure from the norm
>  Andy> for the existing V4L2 desktop applications.
>
>  Andy> Forcing the use of the LED interface also brings along the complication
>  Andy> of proper association of the illuminator or LED sysfs control node to
>  Andy> the proper video capture/control device node.  I have a laptop with a
>  Andy> built in webcam with a status LED and a USB connected microscope with
>  Andy> two illuminators.  What are the steps for an application to discover 
> the
>  Andy> correct light for the video device and what settings that light is
>  Andy> capable of: using V4L2 controls? using the LED interface?
>
> Again, for status LEDs I don't see any reason why a standard v4l tool
> would care. As I mentioned above, illuminators are a different story
> (comparable to a gain setting imho).
>
>  Andy> How does one go about associating LEDs and Illuminators to video device
>  Andy> nodes using the LED sysfs interface?  I'm betting it's not as simple 
> for
>  Andy> applications that use V4L2 controls.
>
> I would imagine each video device would have a (number of) triggers,
> similar to how it's done for E.G. the

Re: Unknown CX23885 device

[Alex Deucher]

On Tue, Jul 27, 2010 at 3:21 PM, Christian Iversen
 wrote:
> (please CC, I'm not subscribed yet)
>
> Hey Linux-DVB people
>
> I'm trying to make an as-of-yet unsupported CX23885 device work in Linux.
>
> I've tested that the device is not supported using the newest snapshot
> of the DVB drivers. They did support a bunch of extra devices compared
> to the standard ubuntu driver, but to no avail.
>
> This is what I know about the device:
>
> ### physical description ###
>
> The device is a small mini-PCIe device currently installed in my
> Thinkpad T61p notebook. It did not originate there, but I managed to fit it
> in.

How are you attaching the video/audio/antenna/etc. input to the pcie
card?  I don't imagine the card is much use without external
connectors.

Alex

>
> It has an "Avermedia" logo on top, but no other discernable markings.
> I've tried removing the chip cover, but I can't see any other major chips
> than the cx23885. I can take a second look, if I know what to look for.
>
> ### pci info ###
>
> $ sudo lspci -s 02:00.0 -vv
> 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI
> Video and Audio Decoder (rev 02)
>        Subsystem: Avermedia Technologies Inc Device c139
>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR+ FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-         Latency: 0, Cache Line Size: 64 bytes
>        Interrupt: pin A routed to IRQ 16
>        Region 0: Memory at d7a0 (64-bit, non-prefetchable) [size=2M]
>        Capabilities: [40] Express (v1) Endpoint, MSI 00
>                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns,
> L1 <1us
>                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
>                DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
>                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                        MaxPayload 128 bytes, MaxReadReq 512 bytes
>                DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr-
> TransPend-
>                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <2us, L1 <4us
>                        ClockPM- Suprise- LLActRep- BwNot-
>                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
>                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
>        Capabilities: [80] Power Management version 2
>                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>        Capabilities: [90] Vital Product Data 
>        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                Address:   Data: 
>        Capabilities: [100] Advanced Error Reporting 
>        Capabilities: [200] Virtual Channel 
>        Kernel driver in use: cx23885
>        Kernel modules: cx23885
>
>
> I've tried several different card=X settings for "modprobe cx23885", and a
> few of them result in creation of /dev/dvb devices, but none of them really
> seem towork.
>
> What can I try for a next step?
>
> --
> Med venlig hilsen
> Christian Iversen
>
> ___
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Idea of a v4l -> fb interface driver

[Alex Deucher]

On Fri, May 28, 2010 at 3:15 PM, Florian Tobias Schandinat
 wrote:
> Alex Deucher schrieb:
>>
>> On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
>>  wrote:
>>>
>>> On Thu, 27 May 2010, Alex Deucher wrote:
>>>
>>>>
>>>> Another API to consider in the drm kms (kernel modesetting) interface.
>>>>  The kms API deals properly with advanced display hardware and
>>>> properly handles crtcs, encoders, and connectors.  It also provides
>>>> fbdev api emulation.
>>>
>>> Well, is KMS planned as a replacement for both fbdev and user-space
>>> graphics drivers? I mean, if you'd be writing a new fb driver for a
>>> relatively simple embedded SoC, would KMS apriori be a preferred API?
>>
>> It's become the defacto standard for X and things like EGL are being
>> built onto of the API.  As for the kms vs fbdev, kms provides a nice
>> API for complex display setups with multiple display controllers and
>> connectors while fbdev assumes one monitor/connector/encoder per
>> device.  The fbdev and console stuff has yet to take advantage of this
>> flexibility, I'm not sure what will happen there.  fbdev emulation is
>> provided by kms, but it has to hide the complexity of the attached
>> displays.  For an soc with a single encoder and display, there's
>> probably not much advantage over fbdev, but if you have an soc that
>> can do TMDS and LVDS and possibly analog tv out, it gets more
>> interesting.
>
> Well hiding complexity is actually the job of an API. I don't see any need
> for major changes in fbdev for complex display setups. In most cases as a
> userspace application you really don't want to be bothered how many
> different output devices you have and control each individually, you just
> want an area to draw and to know/control what area the user is expected to
> see and that's already provided in fbdev.

Users want to be able to dynamically change their display config on the fly.

> If the user wants the same content on multiple outputs just configure the
> driver to do so.

KMS provide an API to do that and a nice internal abstraction for handling it.

> If he wants different (independent) content on each output, just provide
> multiple /dev/fbX devices. I admit that we could use a controlling interface
> here that decides which user (application) might draw at a time to the
> interface which they currently only do if they are the active VT.
> If you want 2 or more outputs to be merged as one just configure this in the
> driver.
> The only thing that is impossible to do in fbdev is controlling 2 or more
> independent display outputs that access the same buffer. But that's not an
> issue I think.
> The things above only could use a unification of how to set them up on
> module load time (as only limited runtime changes are permited given that we
> must always be able to support a mode that we once entered during runtime).
>

What about changing outputs on the fly (turn off VGA, turn on DVI,
switch between multi-head and single-head, etc) or encoders shared
between multiple connectors (think a single dac shared between a VGA
and a TV port); how do you expose them easily as separate fbdevs?
Lots of stuff is doable with fbdev, but it's nicer with kms.

Alex

> The thing that's really missing in fbdev is a way to allow hardware
> acceleration for userspace.
>
>
> Regards,
>
> Florian Tobias Schandinat
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Idea of a v4l -> fb interface driver

[Alex Deucher]

On Fri, May 28, 2010 at 4:21 AM, Guennadi Liakhovetski
 wrote:
> On Thu, 27 May 2010, Alex Deucher wrote:
>
>> On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski 
>>  wrote:
>
> ...
>
>> > Ok, let me explain what exactly I meant. Above I referred to "display
>> > drivers," which is not the same as a "framebuffer controller driver" or
>> > whatever you would call it. By framebuffer controller driver I mean a
>> > driver for the actual graphics engine on a certain graphics card or an
>> > SoC. This is the part, that reads data from the actual framebuffer and
>> > outputs it to some hardware interface to a display device. Now this
>> > interface can be a VGA or a DVI connector, it can be one of several bus
>> > types, used with various LCD displays. In many cases this is all you have
>> > to do to get the output to your display. But in some cases the actual
>> > display on the other side of this bus also requires a driver. That can be
>> > some kind of a smart display, it can be a panel with an attached display
>> > controller, that must be at least configured, say, over SPI, it can be a
>> > display, attached to the host over the MIPI DSI bus, and implementing some
>> > proprietary commands. In each of these cases you will have to write a
>> > display driver for this specific display or controller type, and your
>> > framebuffer driver will have to interface with that display driver. Now,
>> > obviously, those displays can be connected to a variety of host systems,
>> > in which case you will want to reuse that display driver. This means,
>> > there has to be a standard fb-driver - display-driver API. AFAICS, this is
>> > currently not implemented in fbdev, please, correct me if I am wrong.
>>
>>
>> Another API to consider in the drm kms (kernel modesetting) interface.
>>  The kms API deals properly with advanced display hardware and
>> properly handles crtcs, encoders, and connectors.  It also provides
>> fbdev api emulation.
>
> Well, is KMS planned as a replacement for both fbdev and user-space
> graphics drivers? I mean, if you'd be writing a new fb driver for a
> relatively simple embedded SoC, would KMS apriori be a preferred API?

It's become the defacto standard for X and things like EGL are being
built onto of the API.  As for the kms vs fbdev, kms provides a nice
API for complex display setups with multiple display controllers and
connectors while fbdev assumes one monitor/connector/encoder per
device.  The fbdev and console stuff has yet to take advantage of this
flexibility, I'm not sure what will happen there.  fbdev emulation is
provided by kms, but it has to hide the complexity of the attached
displays.  For an soc with a single encoder and display, there's
probably not much advantage over fbdev, but if you have an soc that
can do TMDS and LVDS and possibly analog tv out, it gets more
interesting.

drm has historically been tied to pci, but Jordan Crouse recently
posted changes to support platform devices:
http://lists.freedesktop.org/archives/dri-devel/2010-May/000887.html

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Idea of a v4l -> fb interface driver

[Alex Deucher]

On Thu, May 27, 2010 at 2:56 AM, Guennadi Liakhovetski
 wrote:
> (adding V4L ML to CC and preserving the complete reply for V4L readers)
>
> On Thu, 27 May 2010, Jaya Kumar wrote:
>
>> On Wed, May 26, 2010 at 10:09 PM, Guennadi Liakhovetski
>>  wrote:
>> > Problem: Currently the standard way to provide graphical output on various
>> > (embedded) displays like LCDs is to use a framebuffer driver. The
>> > interface is well supported and widely adopted in the user-space, many
>> > applications, including the X-server, various libraries like directfb,
>> > gstreamer, mplayer, etc. In the kernel space, however, the subsystem has a
>> > number of problems. It is unmaintained. The infrastructure is not being
>> > further developed, every specific hardware driver is being supported by
>> > the respective architecture community. But as video output hardware
>>
>> I understand the issue you are raising, but to be clear there are
>> several developers, Geert, Krzysztof, and others who are helping with
>> the role of fbdev maintainer while Tony is away. If you meant that it
>> has no specific currently active maintainer person, when you wrote
>> "unmaintained", then I agree that is correct.
>
> Exactly, I just interpreted this excerpt from MAINTAINERS:
>
> FRAMEBUFFER LAYER
> L:      linux-fb...@vger.kernel.org
> W:      http://linux-fbdev.sourceforge.net/
> S:      Orphan
>
>> We're not sure where
>> Tony is and we hope he's okay and that he'll be back soon. But if you
>> meant that it is not maintained as in bugs aren't being fixed, then
>> I'd have to slightly disagree. Maybe not as fast as commercial
>> organizations seem to think should come for free, but still they are
>> being worked on.
>>
>> > evolves, more complex displays and buses appear and have to be supported,
>> > the subsystem shows its aging. For example, there is currently no way to
>> > write reusable across multiple platforms display drivers.
>>
>> At first I misread your point as talking about multi-headed displays
>> which you're correct is not so great in fbdev. But "write reusable
>> across multi-platform display driver", I did not understand fully. I
>> maintain a fbdev driver, broadsheetfb, that we're using on arm and x86
>> without problems and my presumption is other fbdev drivers are also
>> capable of this unless the author made it explicitly platform
>> specific.
>
> Ok, let me explain what exactly I meant. Above I referred to "display
> drivers," which is not the same as a "framebuffer controller driver" or
> whatever you would call it. By framebuffer controller driver I mean a
> driver for the actual graphics engine on a certain graphics card or an
> SoC. This is the part, that reads data from the actual framebuffer and
> outputs it to some hardware interface to a display device. Now this
> interface can be a VGA or a DVI connector, it can be one of several bus
> types, used with various LCD displays. In many cases this is all you have
> to do to get the output to your display. But in some cases the actual
> display on the other side of this bus also requires a driver. That can be
> some kind of a smart display, it can be a panel with an attached display
> controller, that must be at least configured, say, over SPI, it can be a
> display, attached to the host over the MIPI DSI bus, and implementing some
> proprietary commands. In each of these cases you will have to write a
> display driver for this specific display or controller type, and your
> framebuffer driver will have to interface with that display driver. Now,
> obviously, those displays can be connected to a variety of host systems,
> in which case you will want to reuse that display driver. This means,
> there has to be a standard fb-driver - display-driver API. AFAICS, this is
> currently not implemented in fbdev, please, correct me if I am wrong.


Another API to consider in the drm kms (kernel modesetting) interface.
 The kms API deals properly with advanced display hardware and
properly handles crtcs, encoders, and connectors.  It also provides
fbdev api emulation.

Alex


>
>> In my experience with adding defio to the fbdev infra, the
>> fbdev community seemed quite good and I did not notice any aging
>> problems. I realize there's probably issues that you're encountering
>> where fbdev might be weak, this is good, and if you raise them
>> specifically, I think the community can work together to address the
>> issues.
>>
>> >
>> > OTOH V4L2 has a standard video output driver support, it is not very
>> > widely used, in the userspace I know only of gstreamer, that somehow
>> > supports video-output v4l2 devices in latest versions. But, being a part
>> > of the v4l2 subsystem, these drivers already now can take a full advantage
>> > of all v4l2 APIs, including the v4l2-subdev API for the driver reuse.
>> >
>> > So, how can we help graphics driver developers on the one hand by
>> > providing them with a capable driver framework (v4l2) and on the other
>> > hand by simplif

Re: ATI TV Wonder 650 PCI development

[Alex Deucher]

On Mon, Feb 15, 2010 at 5:43 PM, Samuel Cantrell
 wrote:
> Perhaps we could contact Broadcom regarding the Theatre 312?
>
> Am I making too much of this? I do have a Pinnacle 800i which works
> with Linux, I was just also wanting to get this card to work. Should I
> just drop it?
>

Can't hurt to try, but I'm not sure how much luck you'll have.

Alex


> Thanks.
>
> Sam
>
> On Mon, Feb 15, 2010 at 2:37 PM, Alex Deucher  wrote:
>> On Mon, Feb 15, 2010 at 5:34 PM, Devin Heitmueller
>>  wrote:
>>> On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher  wrote:
>>>> Who did you contact?   gpudriverdevsupport AT amd DOT com is the devel
>>>> address you probably want.  I looked into documentation for the newer
>>>> theatre chips when I started at AMD, but unfortunately, I'm not sure
>>>> how much we can release since we sold most of our multimedia IP to
>>>> Marvell last year.  I'm not sure what the status of the theatre chips
>>>> is now.
>>>>
>>>> Documentation for the older theatre and theatre 200 asics was released
>>>> under NDA years ago which resulted in the theatre support in the
>>>> opensource radeon Xorg driver and gatos projects.  Now that we a
>>>> proper KMS driver for radeon, someone could port the old userspace
>>>> theatre code to the kernel for proper v4l support on AIW radeon cards.
>>>>
>>>> Alex
>>>
>>> For what it's worth, I actually did have a contact at the ATI/AMD
>>> division that made the Theatre 312/314/316, and I was able to get
>>> access to both the docs and reference driver sources under NDA.
>>> However, the division in question was sold off to Broadcom, and I
>>> couldn't get the rights needed to do a GPL driver nor to get
>>> redistribution rights on the firmware.  In fact, they couldn't even
>>> told me who actually *held* the rights for the reference driver code.
>>>
>>> At that point, I decided that it just wasn't worth the effort for such
>>> an obscure design.
>>
>> Ah right, I meant Broadcom, not Marvell.
>>
>> Alex
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATI TV Wonder 650 PCI development

[Alex Deucher]

On Mon, Feb 15, 2010 at 5:34 PM, Devin Heitmueller
 wrote:
> On Mon, Feb 15, 2010 at 5:21 PM, Alex Deucher  wrote:
>> Who did you contact?   gpudriverdevsupport AT amd DOT com is the devel
>> address you probably want.  I looked into documentation for the newer
>> theatre chips when I started at AMD, but unfortunately, I'm not sure
>> how much we can release since we sold most of our multimedia IP to
>> Marvell last year.  I'm not sure what the status of the theatre chips
>> is now.
>>
>> Documentation for the older theatre and theatre 200 asics was released
>> under NDA years ago which resulted in the theatre support in the
>> opensource radeon Xorg driver and gatos projects.  Now that we a
>> proper KMS driver for radeon, someone could port the old userspace
>> theatre code to the kernel for proper v4l support on AIW radeon cards.
>>
>> Alex
>
> For what it's worth, I actually did have a contact at the ATI/AMD
> division that made the Theatre 312/314/316, and I was able to get
> access to both the docs and reference driver sources under NDA.
> However, the division in question was sold off to Broadcom, and I
> couldn't get the rights needed to do a GPL driver nor to get
> redistribution rights on the firmware.  In fact, they couldn't even
> told me who actually *held* the rights for the reference driver code.
>
> At that point, I decided that it just wasn't worth the effort for such
> an obscure design.

Ah right, I meant Broadcom, not Marvell.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ATI TV Wonder 650 PCI development

[Alex Deucher]

On Mon, Feb 15, 2010 at 3:57 PM, Samuel Cantrell
 wrote:
> Hello,
>
> I have an ATI TV Wonder 650 PCI card, and have started to work on the
> wiki page on LinuxTV.org regarding it. I want to *attempt* to write a
> driver for it (more like, take a look at the code and run), and have
> printed off some information on the wiki. I need to get pictures up of
> the card and lspci output, etc.
>
> Is there anyone else more experienced at writing drivers that could
> perhaps help?
>
> http: // www.linuxtv.org / pipermail / linux-dvb / 2007-October /
> 021228.html says that three pieces of documentation are missing. I've
> emailed Samsung regarding the tuner module on the card, as I could not
> find it on their website. I checked some of their affiliates as well,
> but still had no luck. I've emailed AMD/ATI regarding the card and
> technical documentation.
>

Who did you contact?   gpudriverdevsupport AT amd DOT com is the devel
address you probably want.  I looked into documentation for the newer
theatre chips when I started at AMD, but unfortunately, I'm not sure
how much we can release since we sold most of our multimedia IP to
Marvell last year.  I'm not sure what the status of the theatre chips
is now.

Documentation for the older theatre and theatre 200 asics was released
under NDA years ago which resulted in the theatre support in the
opensource radeon Xorg driver and gatos projects.  Now that we a
proper KMS driver for radeon, someone could port the old userspace
theatre code to the kernel for proper v4l support on AIW radeon cards.

Alex

> Is it likely that that the tuner module has an XC3028 in it? In the
> same linux-dvb message thread noted above, someone speculated that
> there is a XC3028. As the v4l tree has XC3028 support, if this is
> true, wouldn't that help at least a little bit?
>
> Thanks.
>
> Sam
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Replace Mercurial with GIT as SCM

[Alex Deucher]

On Tue, Dec 1, 2009 at 9:59 AM, Patrick Boettcher
 wrote:
> Hi all,
>
> I would like to start a discussion which ideally results in either changing
> the SCM of v4l-dvb to git _or_ leaving everything as it is today with
> mercurial.
>
> To start right away: I'm in favour of using GIT because of difficulties I
> have with my "daily" work with v4l-dvb. It is in my nature do to mistakes,
> so I need a tool which assists me in fixing those, I have not found a simple
> way to do my stuff with HG.
>
> I'm helping out myself using a citation from which basically describes why
> GIT fits the/my needs better than HG (*):
>
> "The culture of mercurial is one of immutability. This is quite a good
> thing, and it's one of my favorite aspects of gnu arch. If I commit
> something, I like to know that it's going to be there. Because of this,
> there are no tools to manipulate history by default.
>
> git is all about manipulating history. There's rebase, commit amend,
> reset, filter-branch, and probably other commands I'm not thinking of,
> many of which make it into day-to-day workflows. Then again, there's
> reflog, which adds a big safety net around this mutability."
>
> The first paragraph here describes exactly my problem and the second
> descibes how to solve it.
>
> My suggestion is not to have the full Linux Kernel source as a new base for
> v4l-dvb development, but "only" to replace the current v4l-dvb hg with a GIT
> one. Importing all the history and everything.
>
> Unfortunately it will change nothing for Mauro's job.
>
> I also understand that it does not give a lot to people who haven't used GIT
> until now other than a new SCM to learn. But believe me, once you've done a
> rebase when Mauro has asked you to rebuild your tree before he can merge it,
> you will see what I mean.
>
> I'm waiting for comments.

I prefer git myself, but I'm not really actively working on v4l at the
moment, so, I leave it up to the active devs.  One nice thing about
git is the ability to maintain patch authorship.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ENE CIR driver

[Alex Deucher]

On Sat, Nov 21, 2009 at 1:30 PM, Jarod Wilson  wrote:
> On Nov 21, 2009, at 12:18 PM, Alex Deucher wrote:
>
>> Does anyone know if there is a driver or documentation available for
>> the ENE CIR controller that's incorporated into many of their keyboard
>> controllers?  If there is no driver but documentation, are there
>> drivers for other CIR controllers that could be used as a reference?
>
> Maxim Levitsky authored lirc_ene0100, which is in the lirc tarball and my 
> lirc git tree now, with the intention of submitting it for upstream kernel 
> inclusion once (if?) we get the base lirc bits accepted.
>

Excellent.  thanks for the heads up.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ENE CIR driver

[Alex Deucher]

Does anyone know if there is a driver or documentation available for
the ENE CIR controller that's incorporated into many of their keyboard
controllers?  If there is no driver but documentation, are there
drivers for other CIR controllers that could be used as a reference?

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add support for Compro VideoMate E800 (DVB-T part only)

[Alex Deucher]

On Sun, Sep 6, 2009 at 11:33 AM, geroin22 wrote:
>
>
>
> Nothing new, just adding Compro VideoMate E800 (DVB-T part only).
> Tested with Ubuntu 9.04 kernel 2.6.28 work well.
>

Please add your Signed-off-by.

> diff -Naur a/linux/Documentation/video4linux/CARDLIST.cx23885
> b/linux/Documentation/video4linux/CARDLIST.cx23885
> --- a/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-01
> 16:43:46.0 +0300
> +++ b/linux/Documentation/video4linux/CARDLIST.cx23885  2009-09-06
> 15:37:13.373793025 +0300
> @@ -23,3 +23,4 @@
>  22 -> Mygica X8506 DMB-TH                                 [14f1:8651]
>  23 -> Magic-Pro ProHDTV Extreme 2                         [14f1:8657]
>  24 -> Hauppauge WinTV-HVR1850                             [0070:8541]
> + 25 -> Compro VideoMate E800                               [1858:e800]
> diff -Naur a/linux/drivers/media/video/cx23885/cx23885-cards.c
> b/linux/drivers/media/video/cx23885/cx23885-cards.c
> --- a/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-01
> 16:43:46.0 +0300
> +++ b/linux/drivers/media/video/cx23885/cx23885-cards.c 2009-09-06
> 15:35:23.434293199 +0300
> @@ -211,6 +211,10 @@
>                .portb          = CX23885_MPEG_ENCODER,
>                .portc          = CX23885_MPEG_DVB,
>        },
> +        [CX23885_BOARD_COMPRO_VIDEOMATE_E800] = {
> +               .name           = "Compro VideoMate E800",
> +               .portc          = CX23885_MPEG_DVB,
> +       },
> };
> const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
>
> @@ -342,6 +346,10 @@
>                .subvendor = 0x0070,
>                .subdevice = 0x8541,
>                .card      = CX23885_BOARD_HAUPPAUGE_HVR1850,
> +        }, {
> +               .subvendor = 0x1858,
> +               .subdevice = 0xe800,
> +               .card      = CX23885_BOARD_COMPRO_VIDEOMATE_E800,
>        },
> };
> const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
> @@ -537,6 +545,7 @@
>        case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
>        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
>        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
> +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
>                /* Tuner Reset Command */
>                bitmask = 0x04;
>                break;
> @@ -688,6 +697,7 @@
>                break;
>        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
>        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
> +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
>                /* GPIO-2  xc3028 tuner reset */
>
>                /* The following GPIO's are on the internal AVCore (cx25840)
> */
> @@ -912,6 +922,7 @@
>        case CX23885_BOARD_HAUPPAUGE_HVR1255:
>        case CX23885_BOARD_HAUPPAUGE_HVR1210:
>        case CX23885_BOARD_HAUPPAUGE_HVR1850:
> +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
>        default:
>                ts2->gen_ctrl_val  = 0xc; /* Serial bus + punctured clock */
>                ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
> @@ -928,6 +939,7 @@
>        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
>        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
>        case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
> +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
>                dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
>                                &dev->i2c_bus[2].i2c_adap,
>                                "cx25840", "cx25840", 0x88 >> 1, NULL);
> diff -Naur a/linux/drivers/media/video/cx23885/cx23885-dvb.c
> b/linux/drivers/media/video/cx23885/cx23885-dvb.c
> --- a/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-01
> 16:43:46.0 +0300
> +++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c   2009-09-06
> 16:09:17.154602943 +0300
> @@ -744,6 +744,7 @@
>        }
>        case CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H:
>        case CX23885_BOARD_COMPRO_VIDEOMATE_E650F:
> +        case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
>                i2c_bus = &dev->i2c_bus[0];
>
>                fe0->dvb.frontend = dvb_attach(zl10353_attach,
> diff -Naur a/linux/drivers/media/video/cx23885/cx23885.h
> b/linux/drivers/media/video/cx23885/cx23885.h
> --- a/linux/drivers/media/video/cx23885/cx23885.h       2009-09-01
> 16:43:46.0 +0300
> +++ b/linux/drivers/media/video/cx23885/cx23885.h       2009-09-06
> 15:36:40.229792022 +0300
> @@ -79,6 +79,7 @@
> #define CX23885_BOARD_MYGICA_X8506             22
> #define CX23885_BOARD_MAGICPRO_PROHDTVE2       23
> #define CX23885_BOARD_HAUPPAUGE_HVR1850        24
> +#define CX23885_BOARD_COMPRO_VIDEOMATE_E800    25
>
> #define GPIO_0 0x0001
> #define GPIO_1 0x0002
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  htt

Re: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Alex Deucher]

On Tue, Aug 4, 2009 at 4:19 PM, Michael Krufky wrote:
> On Tue, Aug 4, 2009 at 3:58 PM, Alex Deucher wrote:
>> On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote:
>>> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote:
>>>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote:
>>>>> Mauro,
>>>>>
>>>>> Please pull from:
>>>>>
>>>>> http://kernellabs.com/hg/~mkrufky/cx23885
>>>>>
>>>>> for the following fixes:
>>>>>
>>>>> - cx23885: Enable mplayer pvr:// usage
>>>>
>>>> I'm not too familiar with mplayer's v4l support, but why not fix
>>>> mplayer rather than adding a fake audio interface to the driver.
>>>> Wouldn't that potentially confuse users or other apps?
>>>
>>> Thats a good question, Alex.
>>>
>>> The answer, for now, is conformity amongst the v4l2 drivers.
>>>
>>> Mplayer has been around for a good long time, and any v4l2 mpeg
>>> encoder that doesnt do this is broken in the vraious userspace
>>> applications.
>>>
>>> I agree that we should fix userspace also -- but fix the kernel first,
>>> so that older userspace works as-is.
>>
>> er... yeah, but you are re-enforcing broken behavior, rather than
>> "fixing" more drivers, why not submit a mplayer patch and tell users
>> they need a newer version of mplayer/etc. to work with their card?
>> Otherwise we'll end up with tons of drivers with fake audio interfaces
>> and mplayer will never get fixed and users will complain that the
>> audio interface doesn't work.
>
> You don't really have the full picture here, Alex.  The applications
> expect to see an audio input, and rightfully so.
>
> This particular driver doesn't expose all of the functionality that is
> available from the raw video device onto the encoder device.
>
> Little by little, we are fixing up the cx23885-417 driver to fully
> expose all featuresets, but in the meanwhile, we do what is needed to
> make things work.
>
> The problem is not mplayer, the real problem is incomplete analog
> video (and analog audio) support in the cx23885 driver, itself.  As
> THAT support improves, you will see small hacks like this disappear.

Ah, got it.  Thanks for the clarification.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Alex Deucher]

On Tue, Aug 4, 2009 at 3:50 PM, Michael Krufky wrote:
> On Tue, Aug 4, 2009 at 3:47 PM, Alex Deucher wrote:
>> On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote:
>>> Mauro,
>>>
>>> Please pull from:
>>>
>>> http://kernellabs.com/hg/~mkrufky/cx23885
>>>
>>> for the following fixes:
>>>
>>> - cx23885: Enable mplayer pvr:// usage
>>
>> I'm not too familiar with mplayer's v4l support, but why not fix
>> mplayer rather than adding a fake audio interface to the driver.
>> Wouldn't that potentially confuse users or other apps?
>
> Thats a good question, Alex.
>
> The answer, for now, is conformity amongst the v4l2 drivers.
>
> Mplayer has been around for a good long time, and any v4l2 mpeg
> encoder that doesnt do this is broken in the vraious userspace
> applications.
>
> I agree that we should fix userspace also -- but fix the kernel first,
> so that older userspace works as-is.

er... yeah, but you are re-enforcing broken behavior, rather than
"fixing" more drivers, why not submit a mplayer patch and tell users
they need a newer version of mplayer/etc. to work with their card?
Otherwise we'll end up with tons of drivers with fake audio interfaces
and mplayer will never get fixed and users will complain that the
audio interface doesn't work.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://kernellabs.com/hg/~mkrufky/cx23885

[Alex Deucher]

On Tue, Aug 4, 2009 at 3:33 PM, Michael Krufky wrote:
> Mauro,
>
> Please pull from:
>
> http://kernellabs.com/hg/~mkrufky/cx23885
>
> for the following fixes:
>
> - cx23885: Enable mplayer pvr:// usage

I'm not too familiar with mplayer's v4l support, but why not fix
mplayer rather than adding a fake audio interface to the driver.
Wouldn't that potentially confuse users or other apps?

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix lowband tuning with tda8261

[Alex Deucher]

On Fri, Jul 31, 2009 at 12:40 PM, Julian Scheel wrote:
> Attached is a patch which fixes tuning to low frequency channels with
> stb0899+tda8261 cards like the KNC TV-Station DVB-S2.
> The cause of the issue was a broken if construct, which should have been an
> if/else if, so that the setting for the lowest matching frequency is
> applied.
>
> Without this patch for example tuning to "arte" on Astra 19.2, 10744MHz
> SR22000 failed most times and when it failed the communication between
> driver and tda8261 was completely broken.
> This problem disappears with the attached patch.
>

Please replay with your Signed Off By.

Alex

> diff -r 6477aa1782d5 linux/drivers/media/dvb/frontends/tda8261.c
> --- a/linux/drivers/media/dvb/frontends/tda8261.c       Tue Jul 21 09:17:24
> 2009 -0300
> +++ b/linux/drivers/media/dvb/frontends/tda8261.c       Fri Jul 31 18:36:07
> 2009 +0200
> @@ -136,9 +136,9 @@
>
>                if (frequency < 145)
>                        buf[3] = 0x00;
> -               if (frequency < 200)
> +               else if (frequency < 200)
>                        buf[3] = 0x40;
> -               if (frequency < 215)
> +               else if (frequency < 215)
>                        buf[3] = 0x80;
>
>                /* Set params */
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html